Elm [1] is also worth looking into. I've been using it of late and having fun with it, despite some quirks. It's quite performant in practice too. Though I haven't done comparisons myself, Elm benchmarks claim it to be the fastest only next to Mercury [2].
Not sure yet. I'm exploring. It is a compile-to-js language and not just a framework though. So far, the static typing has been addictive. The time travel debugger is also intriguing. So far, I don't see any particular reason to not use it for big apps ... except maybe the compiled size, which you can expect to be minimum 100k compressed as a thumb rule.
It's pretty nice, but you don't get two-way binding for free and it's not really baked in. In your example you'd have to use an input or content-editable element and then call ractive.observe and write your own code for binding user-input to your model data.
Compare to something like Knockout.js where you don't write any special code to get the two-way binding (other than creating each data field as an 'observable' field.)
Much like Javascript's "==" operator gives you type conversion for "free", it's not clear to me that getting two-way binding for "free" is a good thing. One-way binding is significantly easier to reason about.
Most of the time, data binding IS one-way when using Knockout.
Input field? That's one-way from display => a variable in your viewmodel.
P tag? That's one-way from variable in viewmodel => display.
But when do you really need two-way data binding? Form validation and formatting. Man, this stuff is hard even with two-way data binding. You have to be able to accept, parse, format, and validate all in the same element. It's very helpful to be able to use knockout for a task like this.
> In your example you'd have to use an input or content-editable element and then call ractive.observe and write your own code for binding user-input to your model data.
I thought about moving to a system that uses React or something like it and I looked at a bunch of them, but I'm sticking with Knockout for now because it lets me keep my markup in the HTML document where I personally think it belongs.
I'll probably end up moving to Aurelia (or something like it) because it's so pluggable and you can use it with React or not. There are so many choices right now, it's hard to decide!! Sticking with whatever I pick is also sometimes difficult, but I've been using Knockout for about a year now.
I'd go with Facebook and the consequent support, testing and community over a framework that does it's own thing. Performance is simply not a concern for most applications (i.e. React itself is more than good enough) and having learned React to a good standard, I'm super excited about building something in React Native.
I recently came across Arch, a compelling functional style approach to React using LiveScript with a central immutable state architecture inspired by Om.
With Omniscient there is a syntactic sugar on top of React class factories, which encourages to think of components as pure and smaller/more focused functions. This tries to lead more to simpler and composable components.
>Essentially any event where the user would expect feedback means you need write the conditional structure in the output. So if the user types a character in an input box then you need to write the value of the input box to be the characters the user has typed so far
Anyone able to provide a quick description of what this means?
The link you referred is about Functional Reactive Programming. Reactive programming by itself is more of a pattern than paradigm. I would call React a reactive framework. How reactive a framework/library is varies from framework to framework. Every framework has its own flavour of Reactivity. Mostly it's some kind of implementation of Observer pattern.
Two famous Reactive approaches are FRP and Meteor's reactive computations.
I have no idea what "reactive framework" might mean, but by most definitions of "reactive" that I know... React actually isn't even close. It's not "not reactive", just tangential entirely.
Nice comparison. Didn't anybody think of implementing a react-like framework in CoffeeScript? There is a coffee-react library tool, but I feel like the ideas of react implemented natively for CoffeeScript would be a match made in heaven...
If you don't insist on JSX, which you don't need, then just use react itself directly in coffeescript, and you won't be able to tell the difference without looking really close. The "canonical" description of this is at [0], but that page is kind of "old". I haven't found value in wrapping everything in parentheses like he recommends. Also that code is using renderComponent() which nowadays should be replaced by some combination of createClass(), createFactory(), and render().
Thanks, interesting. At a first glance, compared to react, this isn't self-contained as it requires (or simply suggests?) RxJS, but I'll give it a deeper look as soon as I can.
React actually doesn't address that concern. With that being said, React is often used with Flux, which does seek to separate business logic from presentation logic.
