I'm a big fan of React. I soured on Ember but, to be fair, haven't looked at it in quite a while. Curious, though, is the statement in the slide deck that Ember "dominates" big apps true or verifiable? Perhaps if you exclude toolkits/libraries like Backbone, and compare only to Angular, I could buy it.
Every time there is any post on Ember, it starts a flame war. As @tomdale would say it, it was ember vs backbone, then ember vs angular and now ember vs react. In today's age of minimalism and extreme flexibility, Ember is very complex and huge - but that is actually it's strength. Build a massive app with just 2 people on the team and you will know why ember users swear by it.
I really enjoy React's concepts. I have but one nit to pick with it and it's meta: mixing grammars in a single buffer really hoses syntax highlighting & indentation in emacs.
I'd much prefer to be able to "require" the JSX where I need it and have the right context passed to it. That way all the editor-specific nonsense can just be avoided.
You could look into Mithril (a smaller React-like framework). It mixes JS and CSS syntax to achieve terseness, and it does so within the rules of valid javascript:
The problem with this is that whatever you require() won't close over other variables/imports unless your preprocessor is straight up compiling JSX into JS and inserting into another JS file, which is kinda gross and eval-y.
I realized some time ago that the run loop inside Ember (aka Backburner) is really similar to Flux.
In Flux, everything is powered by the dispatcher. Changes to the store goes through dispatcher. All the stores changes that react to another store change needs to settle before re-rendering. This is almost exactly how to run loop works. The run loop is the dispatcher.
So in theory, we can just use Backburner to power a Flux app.
React does a similar batching of updates to avoid unnecessary rerenders, but a critical piece of the Flux dispatcher is helping organize inter-store dependencies which (unless I'm missing something) neither Backburner nor React itself does:
I'm just starting with React, but IMO referring to the models in the component and calling methods on them is like the equivalent of calling actions through the dispatcher?
1. Stores can contain more than one "model", they cover a certain "domain"
2. Stores contain immutable data. This allows for reference equality checking which will yield performance gains
3. Stores do not contain asynchronous code. From the view of stores, it doesn't matter if user manipulates the state directly or triggered a fetch from a server.
Using Backbone models is a valid strategy in my opinion though...
There are heuristics to prevent recursing into obviously-removed/added elements (using component type and keys), but aside from that, there's always going to be a tradeoff between frameworks/libs that choose to track this granular information to know exactly where a change originated and what needs to be updated, vs libraries like React that don't set up any sort of observers or have any sort of knowledge about where the change originated from, and React has demonstrated that their approach is pretty fast due to the fact that live mutable DOM manipulation is the bottleneck and not purely JavaScript traversals.
Awesome slides, even having very little experience with EmberJS and React it explained very well what Reach does and is, and why I would want to use it, better than most tutorials out there (at least the ones I have come across).
"If you're going to hate on React for some reason, make it something other than JSX"
But what if I hate JSX? It's such a tight coupling to the DOM which is just the opposite direction I want to go where the DOM doesn't even matter. But that's just my opinion I haven't done enough research or investigation to try and prove one over the other.
I slightly disagree with @machty. I agree that most of the reasons people give for hating on JSX are somewhat off the mark.
HOWEVER: the fact that JSX is XML and not HTML syntax is a real issue. `<label for="foo">` doesn't work; you have to know that it's `<label htmlFor="foo">`. Same with `class` and `className` and multi-word (`maxwidth` vs. `maxWidth`).
Early on, before React had fully made the decision to stick with raw property names, they understood the value of making JSX "just HTML" (see @petehunt at https://github.com/facebook/react/pull/269#issuecomment-2291..., for example). The decision that they made is totally reasonable, but having to learn an XML dialect of HTML (not XHTML, but a dialect that uses property names for attributes, and disallows normal attribute usage) is not free.
That said, I'm sure it's something you get used to quickly, and isn't something that slows you down much once you understand it.
Because it's such a thin layer over JavaScript, you don't have to port/reimplment all the stuff that JavaScript has already solved to your templating language / abstraction of choice. I still prefer Handlebars, but JSX elegantly sidesteps lots of issues at the expense of not actually being real HTML and handling flow control stuff somewhat awkwardly, but you really gotta try it out to get a feel for the tradeoffs.
Then you didn't understand what JSX is. JSX is just optional syntactical sugar for declaring (virtual) DOM elements. You can use all of React with JSX and your code will be only slightly more verbose.
Your objection is to the very tight coupling of the DOM to React's component abstraction. That's a very valid objection, but unrelated to JSX.
Given the extremely tight coupling between the template and it's context (a controller/component), the concerns are the same, and splitting the DOM into a template is an arbitrary separation of technologies rather than a legit separation of concerns
Every thread on React has your comment- JSX sucks or it looks like PHP (which sucks). Half of the thread is then devoted to refuting the comment. At the end everyone's opinion has calcified.
I would highly encourage you to try it before you dismiss it.
"It's such a tight coupling to the DOM which is just the opposite direction I want to go"
That's what I liked about ExtJS4.
They had their own "virtual" component model, which then was rendered as DOM later. But the DOM could change in different versions, because of performance reasons.
There was/is probably much wrong with ExtJS, but I liked this approach.
[+] [-] mrcwinn|11 years ago|reply
[+] [-] sehr|11 years ago|reply
Ember:
* Vine
* Twitch
* Square
* Heroku (dashboard)
* NBC News
* Discourse
* Huboard
* Travis CI
Backbone:
* Rdio
* Hulu
* Disqus
* Khan Academy (also uses loads of React)
* Stripe
* AirBnB
* Pandora
* Trello
etc etc..
Backbone has been around a lot longer, but Ember's apps seems to be built more recently.
[+] [-] lelelele|11 years ago|reply
[+] [-] kaushikb9|11 years ago|reply
[+] [-] mattdeboard|11 years ago|reply
I'd much prefer to be able to "require" the JSX where I need it and have the right context passed to it. That way all the editor-specific nonsense can just be avoided.
[+] [-] lhorie|11 years ago|reply
[+] [-] machty|11 years ago|reply
[+] [-] arnemart|11 years ago|reply
[+] [-] kaonashi|11 years ago|reply
[+] [-] kansface|11 years ago|reply
[+] [-] lightblade|11 years ago|reply
In Flux, everything is powered by the dispatcher. Changes to the store goes through dispatcher. All the stores changes that react to another store change needs to settle before re-rendering. This is almost exactly how to run loop works. The run loop is the dispatcher.
So in theory, we can just use Backburner to power a Flux app.
[+] [-] spicyj|11 years ago|reply
https://news.ycombinator.com/item?id=8248536
[+] [-] nchuhoai|11 years ago|reply
What is the advantage of using Stores over the approach of using Backbone Models as stores and rerender on 'change' events?
https://github.com/clayallsopp/react.backbone
I'm just starting with React, but IMO referring to the models in the component and calling methods on them is like the equivalent of calling actions through the dispatcher?
[+] [-] Retozi|11 years ago|reply
2. Stores contain immutable data. This allows for reference equality checking which will yield performance gains
3. Stores do not contain asynchronous code. From the view of stores, it doesn't matter if user manipulates the state directly or triggered a fetch from a server.
Using Backbone models is a valid strategy in my opinion though...
[+] [-] rustc|11 years ago|reply
[+] [-] machty|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] machty|11 years ago|reply
[+] [-] larrybolt|11 years ago|reply
[+] [-] squidmccactus|11 years ago|reply
[+] [-] tosh|11 years ago|reply
[+] [-] TheSmoke|11 years ago|reply
for a flux implementation, you might want to checkout delorean. https://github.com/deloreanjs/delorean
[+] [-] BinaryIdiot|11 years ago|reply
But what if I hate JSX? It's such a tight coupling to the DOM which is just the opposite direction I want to go where the DOM doesn't even matter. But that's just my opinion I haven't done enough research or investigation to try and prove one over the other.
[+] [-] wycats|11 years ago|reply
HOWEVER: the fact that JSX is XML and not HTML syntax is a real issue. `<label for="foo">` doesn't work; you have to know that it's `<label htmlFor="foo">`. Same with `class` and `className` and multi-word (`maxwidth` vs. `maxWidth`).
Early on, before React had fully made the decision to stick with raw property names, they understood the value of making JSX "just HTML" (see @petehunt at https://github.com/facebook/react/pull/269#issuecomment-2291..., for example). The decision that they made is totally reasonable, but having to learn an XML dialect of HTML (not XHTML, but a dialect that uses property names for attributes, and disallows normal attribute usage) is not free.
That said, I'm sure it's something you get used to quickly, and isn't something that slows you down much once you understand it.
[+] [-] machty|11 years ago|reply
[+] [-] skrebbel|11 years ago|reply
Your objection is to the very tight coupling of the DOM to React's component abstraction. That's a very valid objection, but unrelated to JSX.
[+] [-] sehr|11 years ago|reply
Given the extremely tight coupling between the template and it's context (a controller/component), the concerns are the same, and splitting the DOM into a template is an arbitrary separation of technologies rather than a legit separation of concerns
[+] [-] hcarvalhoalves|11 years ago|reply
It has nothing to do with DOM in principle.
It's just a convenient XML-like declarative syntax to describe a component tree. Think XUL [1] or Gtk+ Glade [2].
The <a>, <p>, etc. are components on the React.DOM namespace that output DOM nodes of the same name.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tu...
[2] https://glade.gnome.org/
[+] [-] kansface|11 years ago|reply
I would highly encourage you to try it before you dismiss it.
[+] [-] rakoo|11 years ago|reply
[+] [-] k__|11 years ago|reply
That's what I liked about ExtJS4.
They had their own "virtual" component model, which then was rendered as DOM later. But the DOM could change in different versions, because of performance reasons.
There was/is probably much wrong with ExtJS, but I liked this approach.
[+] [-] jessaustin|11 years ago|reply
https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH...