
React vs. Ember – EmberNYC slides - dustingetz
https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBHCZkLbR1TEsRnd3yyxuSQ5YY
======
mrcwinn
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.

~~~
sehr
Ember definitely smashes Angular in terms of 'big apps', it seems it's
somewhat behind Backbone.

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.

~~~
mrcwinn
Interesting. Thanks for the list. My biggest issue with Ember, other than the
management of release schedule and API early on, is the concept of tying
routes to models explicitly. It seems to assume that given a route context,
you'll be dealing with a particular model - and only one particular model. If
you want to have an additional data context, you need to establish route and
then tie the routes together within one template.

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.

~~~
tomdale
Ember has now got one of the best (IMO) release cycles in the business. We
borrow heavily from Chrome, and have a very polished release infrastructure,
with release, beta and canary channels you can subscribe to. Additionally, we
have a strict commitment to SemVer and most Ember apps are on the latest
release.

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](http://vine.co) or
[http://twitch.tv.](http://twitch.tv.))

------
kaushikb9
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.

------
mattdeboard
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.

~~~
lhorie
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:

    
    
        m(".form-group", [
          m("input.form-control[placeholder='Name']")
        ])

~~~
k__
I think using m() with CoffeeScript or LiveScript results in much more concise
code than React.DOM. with JSX.

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.

------
lightblade
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.

~~~
spicyj
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:

[https://news.ycombinator.com/item?id=8248536](https://news.ycombinator.com/item?id=8248536)

------
nchuhoai
One question:

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](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
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...

~~~
nchuhoai
Not to sound too defensive, but couldn't you do all these things with Backbone
Models as well?

------
rustc
Is the video of this talk available anywhere?

~~~
machty
It will be in 1-2 weeks at
[https://www.youtube.com/user/EmberNYC](https://www.youtube.com/user/EmberNYC)

~~~
johne20
Thanks for slides. In this slide [http://goo.gl/XDk0J0](http://goo.gl/XDk0J0)
you mentioned you would talk about alternatives to passing down callbacks
later? Did I miss that in the deck or was that just spoken to?

~~~
machty
Flux is that alternative.

------
larrybolt
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).

------
squidmccactus
I like how this is showcasing real-world JS. Which libraries is it using
again?

------
tosh
These slides are hilarious. Love the kool-aid stream analogy. I'd love to see
the talk if it is up somewhere.

------
TheSmoke
as a recent react convert from ember, this is a great presentation. _to
convert more ember users._ :)

for a flux implementation, you might want to checkout delorean.
[https://github.com/deloreanjs/delorean](https://github.com/deloreanjs/delorean)

------
BinaryIdiot
"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.

~~~
wycats
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...](https://github.com/facebook/react/pull/269#issuecomment-22912842),
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.

~~~
lobster_johnson
It's not even XML — it's JavaScript. The problems with for/class/etc. problems
aren't because of XML, but exist because the preprocessor just translates
everything to React.DOM element declarations, and of course "class" et al are
reserved words in JS.

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.

------
jessaustin
Jumping in at this point cuts out all the evocative pictorial motivation for
unidirectionality. If you'd rather start at the beginning:

[https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH...](https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBHCZkLbR1TEsRnd3yyxuSQ5YY/)

