Comparing Ember and Angular

http://www.benlesh.com/2014/04/embular-part-1-comparing-ember-and.html?spref=tw

by nreece • 12 years ago

116 84 12 years ago

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.

brbcoding• 12 years ago

We are having the same discussions, and a lot of the developers seem to lean towards angular, simply because of that momentum that you mentioned.

"The project I'm working on at Netflix is extremely ambitious, ... solving pretty interesting problems in Ember, that are actually a lot more complicated than problems I solved in previous Angular projects"

This is a key point that I keep running into. It seems that more complicated applications can benefit from Ember's very opinionated nature and more backbone-like structure...

I could be totally off base, as I've not created a large-scale app in either of these frameworks (yet).

Tyrannosaurs3• 12 years ago

We have a very complex Ember app, the discussion we have is largely around whether we've made the right choice.

My personal view is that we could get rid of every single problem we have with Ember if we replaced it with Angular... And instead have a whole new set of Angular problems.

nailer4• 12 years ago

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.

Tyrannosaurs3• 12 years ago

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.

awinder• 12 years ago

I didn't get the impression that Angular was unpopular inside of Google from the talks from Google employees at Ng-Conf earlier this year. It's in use by the doubleclick team, they mentioned a ton of internal app usage, and they pointed to it being "the future" for current apps implemented against GWT. Also mentioned a lot of dart & angular dart usage as well.

spankalee• 12 years ago

Angular _was_ created at Google, by Misko Hevery and Brad Green.

joshuacc• 12 years ago

"A lot of people think Google, rather than Getangular LLC, created Angular"

1. The Angular website itself states that Angular is "by Google"

2. On many occasions, Misko Hevery has described how he created Angular while working at Google.

3. This page itself is the only real reference to Getangular LLC that shows up in Google search results.

Consequently, I'm inclined to think that you're mixing up your story.

rhgraysonii• 12 years ago

At the company I work for we recently did a massive migration from Backbone to Ember. The reasoning behind this was simple: prior to the funding round we had recently received that led to an influx of new developers, we had one senior FE guy who was customizing and building this all himself. It became a decision of convention the senior's way vs convention in the standard means of how it is defined in a framework. This is why Ember was so attractive: it is both powerful and maintains a rails-like standard on how you build an application up and out. On a personal project, I would totally use Angular or Backbone, but when maintainability is a question the convention of Ember is a clear winner in my eyes.

TeamMCS• 12 years ago

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

camus25• 12 years ago

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.

protonfish5• 12 years ago

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

camus25• 12 years ago

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

minznerjosh• 12 years ago

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/)!

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.

sehr3• 12 years ago

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

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

[3] https://github.com/guardian/guardian.github.com/blob/master/...

[4] http://www.huffingtonpost.com/john-pavley/huffpost-content-m...

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

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

will_work4tears• 12 years ago

Couple more for Angular:

* MSNBC

* Plunker

nahname2• 12 years ago

TravisCI used to use backbone. Didn't know they switched away.

hkarthik• 12 years ago

You can add Salesforce Desk.com to the list as well.

Bahamut• 12 years ago

I have heard Microsoft uses Angular as well, and I know VMware does.

nathanhammond2• 12 years ago

Here is a pretty complete list of significant Ember applications:

https://docs.google.com/document/d/1ZWYq3gwkPTzUiyqr4x_asSj8...

rdtsc2• 12 years ago

I theorize that Ember's lack of a single corporate backer is what has enabled its incredible community to flourish.

I can see that point, I think that strengthens Ember's position in my view.

camus25• 12 years ago

Ember strength comes from their vocal core developpers and the Ember marketing.

pascalo4• 12 years ago

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.

lhorie7• 12 years ago

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 ) 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 ), which actually surprised me.

ben3362• 12 years ago

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.

lhorie7• 12 years ago

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.

dllthomas• 12 years ago

Sure. Size is a con, functionality is a pro. The point is to correctly weight each. I don't really have strong opinion on what "correct" is, in the general case - I could formulate opinions confronted with specifics.

jcampbell12• 12 years ago

Your jsperf test is not measuring the same thing as the other frameworks.

You need to insert m.redraw() in the loop to make the comparison apples-to-apples. My test shows it is as 3x faster, not 100x which is completely implausible.

lhorie7• 12 years ago

It's not my test, but m.endComputation() - which is in the loop - does call m.redraw() internally.

With that being said, if there's something there that is wrong that I'm not seeing, I'd be happy to hear it, as I am skeptical about the number as well.

nathanhammond2• 12 years ago

In general:

    how much code the browser needs to parse and execute on every page load

The caveat being that that code only needs to be parsed and executed once in a single page application.

    weight of execution payloads across operations in your app

Presumably this cost is providing value to the developer in terms of reduced development time, reduced complexity, or improved correctness. You shouldn't typically incur significant wasted cost in execution, just a selection of tradeoff. Besides, rendering to DOM is still the longest tentpole by far compared to microseconds for JS execution.

EDIT: With regards to the "independent test," that is in no way a realistic use case. You would never add items to the DOM individually when you're in that tight of a loop. You would instead build up a cache and write once. The only thing of consequence that is being measured in that benchmark is each framework's DOM insertion speed.

lhorie7• 12 years ago

> The caveat being that that code only needs to be parsed and executed once in a single page application.

Sure, if you don't consider users that open lots of tabs, or users that close their browsers periodically (e.g. mobile).

> Presumably this cost is providing value to the developer in terms of reduced development time, reduced complexity, or improved correctness. You shouldn't typically incur significant wasted cost in execution

Ideally that would be the case, but from my Angular experience, it's unfortunately not always so clear cut (e.g. filter caching is a good example of time wasted in refactoring for performance reasons)

> You would never add items to the DOM individually

I was under the impression that this is more or less what everyone was criticizing about Backbone rendering a few months ago when that Om article came out.

itsbits• 12 years ago

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.

nikon3• 12 years ago

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!

nahname2• 12 years ago

It's just style. I currently prefer mustache, but used to prefer something much more similar to angular (PURE templates). One is not any better than the other, just takes some getting used to.

nikon3• 12 years ago

Sorry by style I meant the whole {{ bind-attr }} stuff. I think I read too much into it, you can do simple binding just like Angular e.g. {{ user.firstName }} it's just for HTML elements.

protonfish5• 12 years ago

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

nikon3• 12 years ago

I knew all three way before using Angular. Don't get it.

adamors2• 12 years ago

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

cellis• 12 years ago

You can use emblemjs for HAML/JADE style templates.

http://www.emblemjs.com

mrweasel2• 12 years ago

I haven't really used neither frameworks for anything but a few test project for myself, but I don't get the comment on "HTML mustache style".

The {{}} is in both frameworks. I hate it, because it doesn't go well with the template rendering in a lot of server side template languages.

blueskin_2• 12 years ago

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.

pascalo4• 12 years ago

Well, roudtripping to the server and reloading a whole chunk of html to get a sorted view of a table you already have downloaded isn't super smart either?

camus25• 12 years ago

that's exactly what microsoft is doing with its excel app online,and it's one of the fastest app i've ever seen.

protonfish5• 12 years ago

That sounds great, but does it have a framework with corporate backers?

blueskin_2• 12 years ago

It's called HTML.

jaegerpicker• 12 years ago

That's a pretty horrible idea and a large step backwards. Sure the web started out as a system for reading and sharing text but that being the extent of the web's UI pattern has long since passed. For good reason. The web is our best shot at create an open and non controlled application framework. Rendering text on a server and not using JS isn't even close to a solution for that.

IgorPartola3• 12 years ago

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_• 12 years ago

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.

mrweasel2• 12 years ago

I think one of my main issue with client side apps is "Great, now I have to implement the same validation logic twice, and in two different languages". The frontend needs to validate the data, for the "instant feedback" and the backend needs to validate for security.

Just because something can be done as a client-side app doesn't mean that you need to. It might be old fashion, but most of the websites out there would be just fine with forms and links. Javascript can be added later if you think it adds value.

Of cause it doesn't help that I really dislike JavaScript, with it's stupid callbacks and could we just collectively decided to drop the anonymous functions? It's not going to hurt anyone if we agreed to define a function and name it before using it and it would be so much easier to read.

ashmud• 12 years ago

Would this be anything like Atom/RSS?

I like as much separation as possible for letting the UI do the formatting and the backend just be an API. I'm not sure how this (not rendering in JS) would handle more complex scenarios such as SPAs.

williamcotton2• 12 years ago

Use React and you get the best of both worlds. React supports server-side rendering.

Apps built with Angular or Ember have major issues with SEO. They'll have to resort to using something like PhantomJS to prerender their HTML. This is not a trivial bit of engineering.

pascalo4• 12 years ago

Interesting ... By "supports server side rendering", do you mean react can bind to a chunk of preexisting HTML in the page to enhance it? Or running react on node and build a page? Got an example at hand?

lightblade• 12 years ago

I think you're talking about XSLT

nateabele• 12 years ago

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.

Keats2• 12 years ago

I didn't get that part either. ui-router works well for me and doesn't have equivalent issues to rendering nested routes in the same outlet I had in Ember.

IgorPartola3• 12 years ago

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.

Keats2• 12 years ago

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.

cloverich• 12 years ago

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• 12 years ago

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• 12 years ago

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• 12 years ago

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.

badman_ting• 12 years ago

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.

Comparing Ember and Angular

Related Stories