Hacker News Reader

Comment by jessep | Hacker News Reader

I attempted to use Ember in side projects for quite a while, really dove in. Sadly, I never got productive with it. My conclusion was that Ember works for super smart people with a background in traditional MVC UI architecture (different than MVC server architecture), but that mortals like myself probably aren't up to the task.

I moved from Ember to React, and it has been a joy. It does what I actually want: makes interfaces easier to develop, lets you build your interface by composing parts together, lets you write view functions that are as smart as you are (no crippled templates like Ember/Ng). It is basically a simple low level building block that makes a lot of other stuff easier.

Anyway, as a non-genius developer who nonetheless has written a lot of javascript, React is my strong preference. Their approach is beautiful and simple.

View on HN

It might not be so much a genius vs non-genius thing so much as your particular app not needing the heavyweight app-state management that Ember provides.

It's worth pointing out that the Ember core team has been approached by the React core team with the intent of unifying React's view layer with Ember's application state management, which is a major component of what Ember offers relative to other frameworks. If you haven't had to solve major problems with navigation, routing, complex nested async logic, etc., for the particular app you're trying to build, then it sounds like React would get you most of the way there, but even the React team themselves realize that for medium-large scale apps, React's only going to take you so far.

Where did those discussions lead? "EmberJS merges with ReactJS" seems like a pretty exciting headline.

Ember's approach to watching for changes is pretty different. Also, the Ember view layer refactor codenamed HTMLbars has yielded some extremely promising (though admittedly early/premature) performance improvements that often outperform the React equivalent. So we're open to the idea and we have much we can learn from each other but we're not going to merge in React if we can do a better job :)

For me, and I think most people who get excited about it, performance isn't what attracts me to React. It is the semantics (is that even the right word?). The nice way it lets me think about things.

It looks to me like htmlbars is handlebars emitting DOM rather than string. In that case, I think it will be missing the benefits of React. Again, though, I obviously don't understand Ember well.

Yeah, that's a good point. The things I've been building with both have been small and relatively simple.

What do you use for routing and models with react?

I haven't handled routing yet, a lot of people seem to use https://github.com/flatiron/director, which I would probably do. This is the one area where I missed something from Ember.

For models, I've just rolled my own so far. I've experimented in one small project with having a global state object that cotnains all application state data, and then just having domain fns that operate on that data. Inspired by the react people's descriptions of "flux" architecture. It felt really nice.

When using Ember, I got really confused by Ember's Ember Data vs. Ember Model vs. whatever conversation. Again, I just didn't really know what to do here, and I attribute it to my own shortcomings.

Reply on news.ycombinator.com