Hacker News Reader

Comment by hliyan | Hacker News Reader

Oh dear:

   EMBER 2.0 BETA

   Model-View-Controller is replaced by Model-Route-Component-Service.
   Two-way bindings are replaced by data down, actions up (DDAU).

I haven't delved into the details, but it looks like things are starting to move in the direction of React. I'm not entirely surprised. We recently built a full scale app with Ember and Ember Data. Now looking back, React with Backbone feels it could have been an equally good (if not better) choice.

View on HN

> React with Backbone feels it could have been an equally good (if not better) choice.

Superficially it might "feel" like a better choice, but objectively it would have been worse if you're doing anything non-trivial.

The backbone router is severely lacking compared to the Ember Router. Same thing with having a lot of models with relationships between them. Sure there might be Backbone-related projects that try to tackle it — they are all way worse than the Ember equivalents. In my opinion they either lack tests, functionality or have terrible architecture.

I think it's a huge merit of the Ember community that they're moving in this direction. They saw something that worked better and weren't ashamed to say "Well that's better than what we have. We're going to do that instead".

Going by track-record and where they are today, Ember would in my mind be a great choice for any company that wants to start building web applications. Ember-CLI is a huge productivity boost, and I bet any company doing more than a few SPAs has had to build something similar; and it probably ended up way worse than Ember CLI.

I find it very unfortunate that web developers have all put their eggs in the Angular basket. From my point of view the rationale for choosing Angular today seem to be the network effect of readily available developers, and not so much the merits of the framework itself.

The Angular team realised they could do things better, and rewrote their entire framework. The Ember team realised they could do things better, and is incrementally moving towards that while letting you migrate your app with it.

Most React devs use react-router which is heavily inspired by ember's router but the JSX-syntax makes it easier to work with IMHO.

That said, I think Ember's an excellent choice and basically on par with React (it's up to your development style).

It's been a while since I used react-router, but I think this is one place where the Flux flow is better.

Navigation is state, so we built a store to track it. It mediates between a UI model (which abstracts the window location and pushstate stack) and an internal state. Routing involves dispatching an action to request a specific URL, and changing the view to the navigation state is handled by the app's root "application" component, which then sends parameters onward to its current "view" component. There's a simple mapping of route names to views.

We built a very similar component for React, hooked into Flummox. The nice part is that async "just worked", and having the entire router available as a Flux store with actions that you can fire to change the page made integration powerful.

We also added some extra little code to make it run on the server: the <Link> component renders down to an <a> tag, and the router runs correctly, so everything works isomorphically, and as a neat bonus the bulk of the site works without Javascript enabled.

You make some good points. Yes, I totally forgot how good the Ember router is. As for CLI, we actually did build something similar (because CLI wasn't mature enough at the time I evaluated Ember) and it's holding its own against CLI quite well.

I evaluated Angular (as well as React) before settling on Ember last year. I disliked that it tried to own the DOM and that the concepts and terminology (e.g. transclusions) make it difficult to onboard new developers who weren't already experienced in Angular. Plus (and this is a personal opinion), both Ember and React application code looked more elegant than Angular apps.

Every JS framework is moving in the direction of React, because React is (in my experience) the best and most logical we have right now.

And they acknlowedge it : "We would like to thank React for showing that full re-renders can be made efficient. While we did not their precise Virtual DOM approach, their work with Virtual DOM was extremely influential to our approach in Glimmer." Fair play !

Yup, i really like how the js community doesn't hate on other frameworks/libraries, but instead they use each other's ideas to better their own.

Are people always using React with another framework or can you build out full applications with just React? Im looking to start another project and want to try React but not sure if it has everything I'm looking for.

React + Flux in the form of Flummox (along with react-router for routing) is enough for a 10kloc application I recently wrote for Expedia. If you don't want to make architectural decisions or composing smaller libraries then I think Ember is a better choice, but for us React is perfect.

You don't need another framework to build apps with React. But you will need several libraries as React isn't "kitchen sink" type framework like Ember and Angular.

In my React-based apps, I typically include react-router for routing and request or superagent for ajax calls. You can also include a Flux-inspired library if you're into that sort of thing.

The only thing you need is Ajax and you have it right here in the browser without the need of a third party library. All the rest can be handled by React and its plugins.

That's how I do things, React + raw Xml Http requests. Since JSX is already a layer on its own no need to add yet another layer of complexity.

React is the "View", so you need something like Backbone to fuel it. Roll your own, use Backbone, Flux (made by FB especially for React) or Reflux (third party. Flux re-imagined).

I would advise against using Backbone with React/Flux. First, because you don't need it, and secondly, because Backbone is mutable by default, which can cause all sorts of data flow bugs.

Once you buy into the Flux methodology (not necessarily Flux as described by Facebook), a lot of the concerns that Backbone handles melt away. You don't need observable collections and models because all state changes are explicit and data moves in just one direction. Given that Backbone's core is just a thin layer on top of XMLHTTPRequest, you're better off just doing XHR yourself, with POD objects for data.

Just pure react is great for tiny things, but for large applications you should use React with Flux architecture with alt or flummox or reflux or whatever you like, it simplifies things in the long run.

Of course you would need to do things like ajax or routing, for which there are endless libraries, or you can just go pure XHR. React-Router is terrific for routing.

> things are starting to move in the direction of React.

Not just interface wise, but internally: the new Glimmer engine is similar to React as well, but takes advantage of what Handlebars knows about how templates can change to do less diffing. (I think React is gaining something similar soon too)

Also it's more of a

Model-Route-View-Controller-Component-Service

Model-Route-Component-Service

switch.

These things were all present before and many people started to merge the view-controller implementations into a component one.

We almost have all the letters necessary to call Ember the SCROTUM framework. "O" opinionated, "U" __, "T" ___

Reply on news.ycombinator.com