React vs. Ember – EmberNYC slides
docs.google.com
docs.google.com
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.
(We're writing almost no new Backbone code these days.)
See the example/repo @ https://github.com/caseywebdev/cursors
IMO, pairing global page pub/sub with heavy local modification doesn't seem like a good pattern for effective state management. It seems less problematic at scale than two-way databinding but problematic nonetheless.
This seems to confuse the relationship between a URL and the data displayed on the page.
I've really enjoyed React+Backbone, on the other hand. Very small footprint and gives me flexibility to design and build an application. After spending years with Rails, I've come around to "convention over configuration" is a nice thought, but breaks down at certain sizes. And it seems to break down much more quickly on the client side.
To me, personally, well-written Backbone+Underscore+React runs circles around the newer JavaScript frameworks. It's not to say the debate is over and settled - I just haven't found the complexity and size of frameworks like Ember to pay back more than they cost.
There is usually not enough emphasis on the nature of the app in these X vs Y framework discussions.
I can really see why you would choose Ember say for Discourse and why (once you got it) it is very productive.
But for other apps you might constantly fight the Framework.
Optimal patterns really depend on what you want/need to do. (Thats why TodoMVC doesn't help much).
As for the complaint about tying models to routes: Ember does want you to have a model per route, but the model can be any data structure you want: an array, a hash with multiple models, or a single model.
I'm not sure exactly what issue you hit, but most apps of any complexity have multiple models on the page, and of course that's something we support out of the box. (You can see this if you open any production Ember app in the Ember Inspector browser extension, such as http://vine.co or http://twitch.tv.)
Mostly small projects and stuff. Angular definitely has a larger community, but from what I can gather on the internet Ember is used much more often as the entire basis for large applications.
Edit: Added GM.
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.
I imagine a similar effect can be had with ES6 destructuring assignment, just with more commas and mandatory array brackets.
m(".form-group", [
m("input.form-control[placeholder='Name']")
])Well, you got to like semantically significant whitespace for this.
On the other hand, Mithril offers something like JSX, so the <> and ; crowd should be happy.
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.
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?
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...
for a flux implementation, you might want to checkout delorean. https://github.com/deloreanjs/delorean
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.
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
Honestly I try to use messaging where possible for these types of things. The last app I wrote should, theoretically, be able to be moved from an HTML app to a node-qt app only by swapping the views.
But like I said I haven't had a ton of experience with either so I can't make any good, factual points here only my personal preferences and anecdotes.
wut
edit: JSX accomplishes this goal handily, no other tech i have ever used comes anywhere close to JSX, and I have used nearly all of them. (I'm the engineer who manages the designer and integrates his changes. Interactions with the designer are like, "Go to line 37 of XJZ.js and make it look like foo." In JSX, there usually isn't any integration to do as he can commit directly. Which is why JSX rocks.)
Edit: to address your edit that seems overly complicated to me. Most of the web designers (or designers in general) don't know a lot of JavaScript; asking them to make structural changes inside of JavaScript worries me a little. I'd much rather them change the view in its natural state: html and css. JSX isn't that.
also:
var MyComponent = Reate.createClass({
render: function () {
return require('./template-designers-are-not-scared-to-touch').apply(this);
}
});
Where does the designer's job stop ? Does he not handle animation ? Should he be in charge of CSS too, because that's how you do basic animations ? Why shouldn't he be in charge of slightly heavier animations, just because they're in javascript ?
The point of the authors (which I agree with) is that the whole notion of "view == template" is wrong, and thus "view == html+css files" is wrong. A view is the thing the user interacts with: a button, a list of items, a search bar. All these components should be handled as a whole, and should be handled independently from one another. If a component doesn't need any javascript for it's logic, fine; if another component needs some javascript for whatever reason it's nonsensical to separate this javascript. A design doesn't always stop purely at static appearance.
The fundamental unit is the object you're working on, not the technology you're using.
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.
Here's why:
1. Right next to the logic of how a component is meant to function is the markup it will ultimately render with (or something pretty close to it).
2. I still avoid, for the most part, "magic attributes" like in Ember and especially Angular.
It's not perfect, but it is optional. If you're fine transforming CoffeeScript (a bad example - I can't stand CoffeeScript:) then find an inner peace seeing some XML in your JS documents.
Our components end up looking like this. As a CoffeeScript/Jade fan, I obviously like it:
ReactElementBuilder = require './lib/react-element-builder'
# Example: add react-bootstrap components.
ReactElementBuilder.addMany require('react-bootstrap')
MyComponent = React.createClass
mixins: [ReactElementBuilder.mixin]
render: ->
@e 'div#main', null,
@e 'Navbar.fixed',
onClick: @handleNavbarClick
'Hello my name is Navbar'
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.
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.
I agree that's it super awkward. I have no idea why they don't let the preprocessor be HTML-aware and translates class into className directly. I can't see how something like "class" would clash with the surrounding JS syntax given that it's specific to the local tag syntax. <Foo> isn't valid JS, after all, so why should "class" not be valid JSX?
It creates a maintenance problem, too, because React has to play catch up with every HTML tag and attribute and every CSS property.
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...
I would highly encourage you to try it before you dismiss it.
https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH...