Angular vs Backbone vs React vs Ember notes

comparison.md

Note: these are pretty rough notes I made for my team on the fly as I was reading through some pages. Some could be mildly inaccurate but hopefully not terribly so. I might resort to convenient fiction & simplification sometimes.

My top contenders, mostly based on popularity / community etc:

• Angular
• Backbone
• React
• Ember

Mostly about MVC (or derivatives, MVP / MVVM).

• A way of cleanly separating data, presenting data, and business logic (e.g. “To get the total exports of a country, you must sum its exports with every individual country”). Following definitions differ slightly depending on which interpretation you’re using, but the gist is similar.
  • Model: Provider of data - could be an API. Could be a javascript object. Could be anything. It’s the “state” of the application, anything from the data in your viz to which buttons are current clicked and whether we’re showing exports or imports.
  • Controller: Sits between everything and decides how to process the user input, where to gather data from, what to do with it, etc.
  • View: e.g. templating - how the application actually looks to the user and where the user interacts with the application.
• Why? e.g.
  • You can change the data source for a viz without changing any visualization code
  • You can change the design of a viz to, say, use a different CSS library without changing UI logic
  • Basically much less entanglement in general. http://programmers.stackexchange.com/questions/105352/why-should-i-use-an-mvc-pattern

Some terminology:

• Two way data binding
  • I change something in the view (UI), the model (state data) changes automatically. I change the model, the view changes automatically. See: http://n12v.com/2-way-data-binding/ especially the angular example is pretty concise. Saves a lot of time and reduces bullshit boilerplate code.
• Dependency injection
  • A technique where the framework loads modules automatically for you. So let’s say your app needs a NetworkGraphVisualization and that one requires a D3Visualization and a SliderWidget, which in turn requires JQuery, a dependency injection framework will initialize all that junk for you. This also encourages separation of concerns.
• Routing: Being able to index a specific view in the app with a specific URL and having the URL change with the app state.
• Templates: You define the structure of HTML and provide slots, then you can plug in any data you want. Can be generated from a string with templating code in it or by writing html-like DOM stuff - handlebars is the former and Angular directives is the latter.

My impressions:

• Angular:

  • Create custom DOM elements: e.g.<slider start=-5 end=5 />
  • Two way binding
  • “Views do the UI, Controllers work out the logic behind the UI, Services take care of communication with the backend and hold together pieces of common and related functionality, while Directives make it easy to create reusable components and extending HTML by defining new elements, attributes and behaviors.”
  • Invents its own concepts sometimes: scopes, directives, transclusion
  • Some concern with performance over many DOM elements
  • Angular 2.0 is coming out, but isn’t there yet, but will be the future. And it will break API. How wise it to start an angular 1.x app today?

• Ember:

  • Two way binding
  • Very low boilerplate - I like
  • Performance focus
  • Templating engine / handlebars
  • Routing & data layer
  • Server rendering is a bit easier - pure JS
  • Ember API was changing a lot but is now stable
  • Litters the dom with placeholder script tags - technically this is invisible but a bit gross. But they’re fixing this with a new component called HTMLBars. UPDATE: This isn’t an issue anymore, changes merged in.
  • Docs and API seems a tad more friendly than angular in general

• Backbone:

  • Light & fast
  • 3rd party templating, usually underscore
  • No two way binding
  • Views manipulate DOM directly - kinda icky in my POV, makes code harder to test and allows things to get tangled
  • Unopinionated and barebones - sometimes a good thing but doesn’t provide structure, many competing plugins / frameworks to choose from
  • Probably will have to use with marionette at least

• React:

  • Pretty much just a glorified view layer: Has no routing
  • Uni-directional data flow: These guys say “no no no 2-way binding is evil” and eschew it in favour of explicit updates. But then
  • Virtual dom: Your changes get reflected to a virtual DOM. Then you diff that with the actual dom, and only update what changed. This makes updates faster.
  • Probably will need to be used with flux: an architecture template that facebook made that includes a dispatcher.
  • React router: http://github.com/rackt/react-router
  • Flux: https://scotch.io/tutorials/getting-to-know-flux-the-react-js-architecture
  • JSX looks like templates mixed with code to me, a bit gross IMHO - react devs disagree, and their disagreement is cogent but didn't really convince me. You can use raw JS but it's not idiomatic.

• https://www.airpair.com/js/javascript-framework-comparison

• http://www.quora.com/Client-side-MVC/Is-Angular-js-or-Ember-js-the-better-choice-for-JavaScript-frameworks

• http://www.funnyant.com/choosing-javascript-mvc-framework/

• http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html

• React vs ember https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBHCZkLbR1TEsRnd3yyxuSQ5YY/edit#slide=id.p

• More react vs ember, examples: http://instructure.github.io/blog/2013/12/17/facebook-react-vs-ember/

• Angular vs ember https://docs.google.com/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview?slide=id.p

• Why react is awesome (more about the ideas than react itself): https://news.ycombinator.com/item?id=7738194

@MohamadAtieh Maybe it's a bit late to answer, but I advise you a lighter framework for apps containing a lot of elements client-side. In fact, the nested loops consume a lot of resources, and the two way data binding, if used in a bad way (too much calls or updates, useless watches, ...) can also hardly slow your front-end performances. I'm currently doing a fat-app with Angular 1.x and I start to wondering if it was a good choice. If I could re-start from scratch, I would maybe pick up Backbone or Ember. Even if I'm not well-informed about the differences, it's my current feeling of the thing.

Thanks for sharing

👍

thanks for this, really useful as junior dev just getting into frameworks a little

I know that such comparisons should be concise, but I think it is not such simple. For example you wrote that Backbone hasn't two way data binding. It would be HUGE disadvantage - if it would be true ;) You can reach 2-ways data binding in Backbone in the best in opinion way: http://n12v.com/2-way-data-binding/

Anyone opinions on newcomer, vue.js (http://vuejs.org/)?
I personally haven't used it but saw some fuzz about it recently.

Interesting what would anyone say about this framework (https://github.com/BBGONE/jRIAppTS)?
I made it for myself but shared with anyone who chooses to use it and i use it at my work to create LOB applications.
This framework is MVVM which i liked using Microsoft Silverlight and WPF.
I don't specially advertise it, but simply want to know why do so many choose to create or use MVC pattern instead of MVVM and databinding? I feel MVC pattern very clumsy

Thanks for sharing your research, immensely helpful.

What is currently your favourite ?

Mali what did you end up using most often in 2016? :)

reviewing JS framework comparisons in 2019 - still 👍🏻