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.
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.
>> 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.
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.
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.
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).
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.
> 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.
Sorry but that is almost the archetypal FUD sentence of the 'micro framework'. And the more you analyse the 'lots of code must = bloat' sentiment, the more ludicrous it becomes.
Look at the docs. If you see functionality in Angular that you think is unnecessary then file an issue, or write a blog post explaining the alternative approach. Please don't spread lazy FUD like this, it helps nobody.
I did write a little bit about this in the comparisons page on the Mithril site ( http://lhorie.github.io/mithril/comparison.html ) and I am actually writing an article about this topic (specifically, about lessons I learned from using Angular that apply to Mithril) that I'm planning on publishing this weekend over at the blog ( http://lhorie.github.io/mithril-blog ). There's a feed you can subscribe to if you're interested.
There's also a reasonable amount of docs on the main site about the approaches that I do propose for various aspects of the MVC stack (e.g. see templating, components, etc).
I'm not saying more code is always necessarily bloat, but the correlation between code size and bloatedness does exist, whether you like it or not. I think what is ludicrous is to assume that all of the organically grown code over the years is somehow made up of only useful harmonious features.
Off the top of my head, I could immediately think of angular's directive system, and $scope as things that are probably far more complex than they should be, but these aren't exactly things you can "file an issue" for. So I did the next best thing and scratched my own itch.
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.
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.
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.
Yeah sorry, you're right. Just as I went out for lunch, it occurred to me that I was looking at a bleeding edge version (which has a refactor of this code) and not the version being used in the test.
I had a feeling there was something fishy about the number but I couldn't quite put my finger on it. Thanks! :)
PS: and thanks for catching that post redraw hook issue; I'll add a fix for it.
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.
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:
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
1. Angular is maintained by Google, but it was not created there.
2. Getangular was an online JSON storage service where Misko worked. AngularJS was announced on getangular.com (which was a product, not a project), and copyrighted Angular / BRAT Tech. LLC.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
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.
Your code is always one new feature request away from needing "just a little more" from your front end. Before you know it, your nice and simple JS has to keep a lot more state than you anticipated. jQuery helps, but I eventually realized that it just helps write apps which do aspect-oriented programming on the DOM — and that is completely unsustainable for any but the most trivial app.
Angular has been a breath of fresh air in comparison. It significantly reduces complexity. It's also easy to add to an existing project, even one with server-side templates. At this point, however, I consider the use of jQuery and server templates an antipattern at worst, and a necessary evil for some types of performance optimizations at best.
I agree except for "large complex applications need libraries like Angular" That is nonsense. There were plenty of large complex web apps before Angular and they worked fine. This sudden belief that web apps need a front-end framework is insane.
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.
Validation in two different languages is solved by defining your models using a framework that supports proper validation. Moreover, you should do that for all application. Don't make me wait for your server to respond to know that I mistyped a credit card number. Validation on the client side and on the server side is a solved problem and if your application has any significant amount of validation code compared to all of your code, your application is way too simple.
It is old fashioned. It's also backwards when it comes to mobile apps. Phones and tablets have lots of horsepower, but bandwidth is low and more importantly latency is high. I can almost buy that when you expand a menu the whole page reloads if it happens over Google Fiber and your server adds no latency, but when the roundtrip to the server takes 2-3 seconds, I am not using your app.
I will repeat: if you are running a mostly static website, HTML + HTTP is the way to go. There are still plenty of web apps that work just fine that way (basic CRUD mostly). However, there is a category of apps that are much better served by running client side with a well-defined API to the server. This provides you with a true MVC setup and makes for much cleaner code. Trying to put together a JavaScript driven app where you reload pages is something I have experienced quite a bit over the past decade. It's such a pain that it should not be attempted. Angular and friends make single page apps viable and much easier than the jQuery + HTML + Ajax apps.
I don't blame you for disliking JavaScript: it's an odd little language with some really bad parts. Perhaps try one of the other languages that compiles down to JS? I hear CoffeeScript is very nice.
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.
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?
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.
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?
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.
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.