
Comparing Ember and Angular - nreece
http://www.benlesh.com/2014/04/embular-part-1-comparing-ember-and.html?spref=tw
======
lhorie
People claiming that framework size doesn't matter is a bit of a pet peeve for
me: download size may not matter once the files are cached, but the
uncompressed size still translates directly to how much code the browser needs
to parse and execute on every page load, and may also negatively affect the
weight of execution payloads across operations in your app.

These costs are not as small as you might expect. The performance tests I put
on the Mithril (
[http://lhorie.github.io/mithril](http://lhorie.github.io/mithril) ) site
illustrate this problem. I don't have Ember there, but if anyone more familiar
with it would like to contribute (the rendering test is really simple), that
would be most welcome.

There's another independent test here ( [http://jsperf.com/angular-vs-
knockout-vs-ember/292](http://jsperf.com/angular-vs-knockout-vs-ember/292) ),
which actually surprised me.

~~~
ben336
I think its important to note with the perf test and download size stuff that
the frameworks that are bigger/slower to render provide more functionality and
more templating options respectively. Thats not to say they're better, but
just trying to clarify the tradeoffs under discussion.

~~~
lhorie
That's not necessarily true. I can't speak for the jsperf test since it's not
mine, but for the Mithril site tests, I exclude "optional-but-not-really"
things like Marionette and ngRoute/ngResource/friends from the tests (whereas
I include the entirety of Mithril - templating engine, router, etc) to try and
tilt the tests in other frameworks' favor.

Sure one could argue that Angular has filters or whatever, but hey with
Mithril you can express templating things that you can't with Angular (e.g.
tables with nested loops, or w/ for-else constructs), so it's not really a
apples to apple trucks comparison. With an order of magnitude more code, one
has to wonder how much of that extra code is more functionality and how much
is just bloat.

~~~
hajile
A big factor here is that Mithril describes templates programmatically rather
than strings of data. It's the difference between:

    
    
      function render() { eval("(function () {}());"); }
    

and

    
    
      function render() { (function () {}()); }
    

These are going to run at much different speeds because one involves parsing
multiple times while the other only needs to be parsed once. The tradeoff is
some complexity (though there's also more flexibility too).

    
    
      <ul class="foo">  
        <li data-ng-repeat="item in items">
          {{item.x}}
        </li>  
      </ul>
    
      m("ul.foo", [  
        items.map(function (item) { 
          m("li", item.x);  
        });  
      ]);

~~~
lhorie
Yep. I'd argue that Angular is far more complex though, with its `track by
$index` and `ng-repeat-start`/`ng-repeat-end` and the scoping implications of
caching filtered expressions in the view and the `ng-init` watcher trap and
all that. But I digress.

------
minznerjosh
As somebody who has built actual applications with both Ember and Angular, I
think this article totally hits the nail right on the head.

Though, in regards to the "Angular is backed by Google" comment, while they
don't actually "back Ember" in the same way Google "backs Angular", it seems
that a ton of large companies are also invested in Ember
([http://emberjs.com/ember-users/](http://emberjs.com/ember-users/))!

And, I know the Ember folks are really proud of the community they've built as
well. I theorize that Ember's lack of a single corporate backer is what has
enabled its incredible community to flourish.

~~~
sehr
Ember:

    
    
      * Yahoo
      * Square
      * Vine
      * NBC News (front page)
      * Netflix (real time tools)[1]
      * Zendesk
      * Groupon
      * Twitch
      * CodeSchool
      * Urbanspoon
      * Discourse
      * TravisCI
      * Ghost
    

Angular:

    
    
      * DoubleClick
      * MSNBC (front page)
      * BBC [2]
      * The Guardian [3]
      * Huffington Post [4]
      * Udacity [5]
      * Desk.com [6]
      * Plunker
    

Please reply if you know more, would love to build out a real census of who's
using what

[1] -
[https://twitter.com/ebryn/status/433402427979493377](https://twitter.com/ebryn/status/433402427979493377)

[2] - [http://www.bbc.co.uk/blogs/internet/posts/Building-BBC-
Live](http://www.bbc.co.uk/blogs/internet/posts/Building-BBC-Live)

[3] -
[https://github.com/guardian/guardian.github.com/blob/master/...](https://github.com/guardian/guardian.github.com/blob/master/developers/about.md)

[4] - [http://www.huffingtonpost.com/john-pavley/huffpost-
content-m...](http://www.huffingtonpost.com/john-pavley/huffpost-content-
management-system_b_3739572.html)

[5] - [http://www.quora.com/Udacity/What-is-Udacitys-technology-
sta...](http://www.quora.com/Udacity/What-is-Udacitys-technology-stack)

[6] - [http://www.desk.com/careers/angular-
engineer](http://www.desk.com/careers/angular-engineer)

~~~
will_work4tears
Couple more for Angular:

* MSNBC

* Plunker

~~~
ville
Looks like also SpaceX is using Angular:
[https://www.angularjobs.com/posts/752-angularjs-developer-
at...](https://www.angularjobs.com/posts/752-angularjs-developer-at-spacex-in-
hawthorne-ca)

------
badman_ting
I kind of can't believe he called Angular easy to learn. One of the most
common things you hear about it is the steep learning curve, which is not
helped by the docs (the skimpiness of which is another frequent lament). In my
experience Angular is learned by Googling problems you have, which are then
explained in Stack Overflow posts.

As an aside - this is something I've hardped on before, but I just really
think it is not helpful to anyone to use examples whose names are so abstract:

    
    
        ng-click="foo = 'bar'; blah(foo + bar + '!!!); shazbot = nanoo && nanoo"
    

This is meant as an example of something you should not do. But it's nonsense
- it's quotes and semicolons separated by meaningless names. Of course that is
the point, but in turn that is my point - give a better example, one that
models something one may do in the real world but should not, so that the
person reading the example actually understands what not to do. Instead of
that, something like this:

    
    
        ng-click="shoppingCartId = 52; initCart(52); var myShop = new Shop();"
    

People know what shopping carts are. "shazbot" and "nanoo nanoo" are whimsical
references to an old sitcom. Entertaining to the author, perhaps, but not
helpful.

------
nateabele
Re:

> _Ember 's routing is just flat out better than anything else I've seen out
> there._

I'm the lead developer of ui-router. I've read everything I can about Ember's
router, and I just don't get it. Barring some boilerplate-saving conventions
(we don't offer any, but we do offer APIs that let you roll your own pretty
easily), could someone explain to me what the big deal is?

Also, re: the score-keeping thread, I know Angular is used extensively within
the BBC.

~~~
IgorPartola
I just recently started using Angular, but ui-router definitely gave me a bit
of trouble. I had to dig through StackOverflow to find answers to questions
like how to enforce that certain views must only be accessed when the user is
logged in. Another bit of trouble I had was doing things like logging the user
out, then immediately redirecting them to the login page. Had to redirect then
to the home page so that the state change hijacking code fired and redirected
a second time.

I can definitely see that ui-router is a valuable component and it's very
powerful, but perhaps I have not achieved the zen of it yet.

------
Keats
I've used both and I much prefer Angular, more flexible and I find the simple
object approach way easier to understand than the getters/setters.

If you worry that much about difficulty of maintenance because someone is
calling their controller SomethingCtrl and another one SomethingController,
you can choose one and enforce it during code reviews.

I guess it's down to whether you prefer doing things your own way or having to
follow their structure.

Also not having some random divs popping up in your html is nice.

------
itsbits
I have worked for both Ember and Angular...i prefer Angular for personal
projects and Ember in my company. Reason is simple. With Angular , you can
write code in many ways. If code goes to maintainance, it gonna get messed up.
With Ember, unless you use lot of jquery, that issue not gonna rise. I am
waiting for HTMLbars too.

------
nikon
Been using Angular for 10+ months now, it's been a great ride and has saved
1000's of hours.

Feel like I should try out Ember over the weekend.

The HTML mustache style puts me off though I have to admit!

~~~
protonfish
Maybe, but were those 1000's of hours saved the ones where you should have
been learning how to use JS, HTML and CSS?

~~~
adamors
How can anyone do 10+ months of front-end web development without knowing all
three (well)?

~~~
protonfish
I've seen it a lot. If they knew what they were doing it'd have been done in
3.

~~~
adamors
What would have been done in 3? What are you talking about?

------
Tyrannosaurs
This is a discussion playing out in our development team at the moment.

The one thing we've observed that he touches on in mentioning that Angular is
backed by Google but doesn't really go into as much as he might, is that it
feels like Angular has more momentum generally in the developer community -
more posts on StackOverflow and more Git activity, plus more job ads.

If you're in it for the long haul that may be a significant factor.

~~~
nailer
> The one thing we've observed that he touches on in mentioning that Angular
> is backed by Google but doesn't really go into as much as he might, is that
> it feels like Angular has more momentum generally in the developer community
> - more posts on StackOverflow and more Git activity, plus more job ads.

This is true, however:

\- Angular is considered by both it's supporters and detractors to be very
complex and it's documentation a little difficult. I've used Angular for some
older production projects, and used ractive.js about 5x more newer projects,
and I've searched/asked more questions for Angular.

\- A lot of people think Google, rather than Getangular LLC, created Angular.
I've also met a lot of people who think Angular is popular inside Google, or
that Angular is used for Google+, both of which are incorrect.

The fact Ember is so popular despite the 'by Google' misconception around
Angular actually makes me quite confident about Ember.

My Ember knowledge, BTW is limited, I went angular -> ractive.js, so there may
be ember downsides I'm not aware of. Ember's new htmlbars templating looks
really clean though, so I'm pretty excited to try ember once it's the default.

~~~
Tyrannosaurs
My personal view is the supported by Google isn't as robust a defence as some
would like to believe - after all, it's not as if they don't have a history of
dropping things with little or no warning.

~~~
rdtsc
It seems kind of a weak point it me, in way. The fact that Ember is around
kinds speaks that it is quite good -- it didn't need a full time corporate
backer to rise up.

------
pascalo
I have worked a bit with angular lately, and am now knee deep into my first
ember project (with ember-cli).

I agree with a lot of the points made in this Series, a really good write up.

In Ember I feel I have to write a bit more boilerplate around dealing with
collections, (i.e. sorting).

Can't wait for HTMLBars, the script tags littered around the dom are just not
very nice, and I find myself using :last-of-type CSS selectors and the likes a
lot.

I also think that the directives in angular just work nicer than the
components in ember, because there is more control over what's bound into
their scope.

Ember's approach to structure is great though, and the router is really nice
to work with, much much nicer than ui-router.

Both are great frameworks though, and I really appreciate the work of both
teams to give me great tools like this to work with.

------
camus2
Choice is good , monoculture is not. The more frameworks we have to choose
from,the better it is.

I personally prefer the configuration over conventions thing,because I dont
like magics,but I understand that kind of pragmatism.

~~~
protonfish
If that were true, two poor frameworks would be better than one good one.
Luckily we have 50 poor ones.

~~~
camus2
the black or white argument is of course a logical fallacy.

------
cloverich
Was hoping in his comparison of download size that he'd mention the total size
of all included libraries. I've not used either yet (only watched some talks,
etc), but have noticed a few times Yehuda argue that Ember is bigger because
it includes a lot of functionality you would use 3rd party libraries for in
Angular. E.g., if you add up all the libraries _most_ people use with Angular,
that are included out of the box in Ember, they'd be similar.

Does that hold any water?

~~~
tragic
It really depends what you need. I just launched a pretty trivial Angular app,
which required ngRoute and a local storage interface. Total size of the three:
112.7k. All the standard-issue angular modules put together amount to 129k.

For non-trivial stuff, I'm sure people need a bunch more extras, third party
libraries and so on. But it's a pretty major bonus for Angular that you can
use it productively either for a full SPA, or for the kind of trivialities
that one typically duct-tapes together with jquery. The small-ish size (I
know, not THAT small) is part of that, but so is the flexible and modular
design.

Not that I dislike Ember - it's very nice. And I am in the fortunate position
at the moment where page-load size is not a huge concern (or rather, a battle
that has already been lost before I clock in).

------
notastartup
I don't know if it's just me but I've found that when I just use regular
javascript or jQuery or specific javascript libraries that I only need, I am
able to produce something faster and with far less frustration of having to
learn MVC on the client side which I feel is enough for server side but not
the client side.

I used backbone.js for days where as something I could've done within hours in
jQuery and ajax with Python flask running in the background.

Not only that you need build automation, dependency manager, phantomjs static
html renderer...it's really more than I can deal with and feel that this extra
overhead doesn't really bring much to the table more like work for work itself
is created to boost the credibility of such work.

~~~
iends
For small projects, you can certainly get stuff done more quickly with native
JS and/or jQuery.

Once you get past a certain number of developers, or project size, are
framework really shines.

------
TeamMCS
Damn just as I was reading that our corp firewall blocked the domain for
hosting malicious content (it's usually over zealous)...

------
blueskin_
How's this for a revolutionary idea: The server sends text hat can be rendered
on any device with minimal resource usage, can be cached, can be parsed by
robots, and even formatted by the user.

Rendering pages in javascript just wastes the user's computing resources (and
opens them up to nice vulns) and prevents search engines from indexing your
content.

~~~
IgorPartola
Cool. How do you provide instantaneous feedback with this system? As in, if
the user has a list of items with delete buttons, and you want to remove the
item from the list as soon as the user clicks the X? Think about using your
browser and having it reload every toolbar and menu every time you clicked on
something.

All sarcasm aside, plain HTML has plenty of great uses, but just because you
don't see a reason for client-side apps does not mean that they don't exist.

~~~
_nate_
Can you not use AJAX through jQuery to gain this instant feedback? Do I really
need to load an additional library to send and receive data to the server and
update the UI, when I can already do that through jQuery?

This is an aspect of the HTML vs JS rendered page debate I’m still trying to
wrap my head around. I understand really large and complex applications need
libraries like Angular, Ember, React, and the like to render their pages with
JS.

But what is so backwards and old-school about rendering HTML server side and
then manipulating the HTML client side with a thin layer of JS and AJAX?

It feels as if the debate is between plain vanilla HTML pages and highly
complex JS rendering, without any middle ground and integrating the benefits
of both.

EDIT: Thank you for the responses. I’m genuinely trying to understand the pro
and cons – of not just each framework – but of the methodologies in general,
and your answers help.

~~~
ben336
Sure. And if you display a count of the number of items in the list, you can
update that with jQuery too. Are there other dependencies? Maybe if the list
gets too small there's supposed to be a warning message or something shown? I
can check the list size each time with jQuery and display/hide the message if
necessary.

Eventually as these side effects pile up, jQuery by itself becomes a mess. You
have a ton of checks and complex behaviors after each user event.

Or I can provide some structure on the front end so that I can model my data
in a reasonable way and have the DOM respond based on changes to that model.
Obviously for stuff thats mostly static, server-side rendering is better. But
when you're displaying stuff that includes complex relationships and
behaviors, modeling it on the client side becomes an important part of
maintainability. This doesn't have to be complicated. Backbone is certainly
not complicated. But it is the best option if you want to have complex UI
behavior tied to an underlying model and need responsive UI feedback.

