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

So how was your quest ended? Wondering which one you decided. 😀

@kunthar I think we're leaning pretty heavily towards ember at this point :) Again, it seems like a needs thing so I didn't want to mandate a decision here - but angular was quickly eliminated due to 2.0 on the horizon and the impending shift - we don't want to build something that'll become legacy in 2 years. We liked the fact that ember gives you a decent structure to begin with. It's opinionated but we agree with its opinions for the most part. React and backbone were less structured and more DIY, which isn't necessarily bad and gives you more flexibility, but I think ember does what we need and we'd like to focus on other things that are more pressing for us.

@makmanalp I've been working with Ember for sometime and I can not be happier with the direction it is taking. Specially with the introduction of 'ember cli' which brings amazing order to both small and big projects its been an absolute pleasure to work with and would suggest to use it right from the start, make the whole process and also collaboration a lot easier for devs. Good luck!

In Angular the DOM structure is created on pageload. Suppose you have multiple templates in your page and you don’t want to show them at a time. In that case also you have to define those at page load lavel, if you use angular, which will unnecessary create few extra DOM elements. But in Ember you can insert dynamic templates as it uses string based templating method. So in this perspective Ember and Backbone’s string-based templating may go handy, but if you talk about data binding, DOM-based templates provides you better performance. According to the Angular developers’ team, in near future DOM-based templating will be natively supported on browsers and when this happens,
http://www.agileinfoways.com/technical-expertise/front-end-development/angular-js/

Angular apps will run way too faster, so we should best prepare ourselves for the future by adopting it now. AngularJS is from Google, so they are already working on this with Chromium and standards bodies.

Hey, is it a good idea to start a new production project using Angular 1? What are the alternatives?

@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 👍🏻