Most of the form factors we use regularly to access HTML5 type applications are in flux. Today we see the latest quad-core Snapdragon that screams across the silicon leaving empty battery cells in its wake. Tomorrow may be a battery friendly OS that sacrifices resources in your hand for a lower point of entry cost-wise for the non-technical user.
If you are using client side JS to build your views, you take a risk not knowing what the end user may be experiencing. Why take the risk at all and let the known variables of your own infrastructure deal with that workload?
But using them has the effect of shifting computational work from the server and network to the client - eg, from an environment you control to one you don't.
Besides the examples you gave, what if someone loads your site on an overworked computer with multiple apps running and 20+ browser tabs open (yours truly, guilty as charged), how will your app perform? The potential performance variance across different platforms, and even similar platforms under different loads, can be large.
It was just a year ago that Twitter announced they were shifting page rendering from the client back to the server specifically to solve that problem [1]:
"When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’ browsers and consumed the Twitter REST API directly, in a similar way to our mobile clients. That architecture broke new ground by offering a number of advantages over a more traditional approach, but it lacked support for various optimizations available only on the server.
To improve the twitter.com experience for everyone, we’ve been working to take back control of our front-end performance by moving the rendering to the server. This has allowed us to drop our initial page load times to 1/5th of what they were previously and reduce differences in performance across browsers."
While both JS performance and Moore's Law march on [2] and may one day negate this issue, my rule of thumb so far remains to favor server-side (and CDN) for computation and performance, unless there's a clear business/technical case for computation-heavy front-end (SPA on a corporate Intranet is good one, for example; or an SPA targeting an audience you know is savvy about local resource usage).
[1]: https://blog.twitter.com/2012/improving-performance-twitterc...
[2]: For desk/laptops at least. Need a Moore's Law for batteries for mobile.
It's faster, less resource intensive (from a revenue standpoint) and more easily targeted to isolated groups of users to implement innovative solutions on the client-side. Through testing and days analysis, those techniques can be vetted, with clear "winners" moving from industry-accepted best practices to finally becoming true open standards (20 years later).
Shortly after the transition to industry accepted best practice, we see the risk takers (businesses) internalizing those features back to the server-side so that their user base as a whole can reap the benefits. All while freeing up resources within their product (your client) to start the process over again on the "next big thing".
There are domains (like web apps) that really suit Angular, and rendering on the server simply isn't an option. There are content sites which should be handled on the server. Then there's the all the stuff in between. Admin for a CMS? You could go either way on that so you need to weigh it up yourself. These days I'd swing for Angular in that case because by the time you've loaded a single grid directive you have 50% of the system running.
The performance overhead swings both ways - it's not great to be dragging truckloads of html over the network to a mobile device either. Of course you need to test for your specific use case. I definitely get your point, and if you're building for mobile you'd want to do proper testing before banking on Angular.
One thing I would say is that I use Angular for my web app which deals with huge (million node) svg documents and performance-wise it actually deals with it really well (once you've optimised the bottlenecks into directives). From a code sanity point of view it's a life-saver.
For example, if you are mimicking a spreadsheet, it is very handy to have the presentation layer modeled in MVC instead of writing all the old-fashioned-jQuery-spaghetti-code way.
That isn't meant as a criticism of backbone per se, rather I think they are actively going for different things - backbone makes it easy to achieve a client-side rendered single page website with MVC separation but lets you control actual rendering and data binding, i.e. maximal control, whereas angular allows you to do the same thing but provides 2-way data binding, code/html reuse via directives [0], local scoping of data on DOM elements [1], dependency injection [2], vastly improved testability [3] and lots more.
My experience of actually developing websites with both is that angular is a better experience and involves a hell of a lot less boilerplate than backbone and even though, when it doesn't work, it can be infuriating it is net a simply amazing framework.
Obviously I'm very biased and by my own admission my understanding of both is limited and I am certainly not the best developer ever blah, so take this with a pinch of salt. I think if you need maximal fine-grained control over the behaviour of your website while getting help with MVP you're better off with backbone, but in any other situation use angular (or possibly batteries-included alternatives like ember.js or knockout.js - I have no experience with them so can't comment there.)
[0]: http://docs.angularjs.org/guide/directive
[1]: http://docs.angularjs.org/api/ng.$rootScope.Scope
I've not had awful problems debugging it, certainly no more than any other js library spitting out "cannot read property 'foo' of null" all over the place with stack traces that give you no help, though I don't deny it can be a bitch.
I'm not sure I understand your point about polluting the HTML namespace - sure you can introduce new HTML tags which can conflict, but if you're careful it's not an issue (and you can choose what directives to make available in a given module.)
I think one key thing I'd say to newcomers to angular is that when it doesn't work it can be an absolute bitch to resolve problems, though you gradually adapt to its patterns over time and such pain reduces significantly.
Like I said in the grandmother* post I do think the positives outweigh the negatives. In fact, I think they MASSIVELY outweigh the negatives, easy 2-way data binding and the code/html reuse of directives alone are enough to make me love it, but hey I get where you're coming from on the painful aspects.
* A sad attempt at reducing sexism in tree analogies.
Angular seemed very nice - until I tried to do something that it did not foresee and... wow... things get complicated really fast when you do that.
Sums up what I wanted to do. I think in this particular instance things have moved on and it may be easy these days, but thinking about what would have happened if I'd had to figure out that code myself, I could envision spending a day or two figuring out how to add something that is a one-liner in jQuery. It made me nervous about "unknown unknowns", too, whereas pjax is pretty easy to reason about.
There is probably some high correlation between a startup's size and age... Older startups are likely to be larger, and are likely to have started their stack using the popular framework of the time (Backbone). Newer startups will be smaller, and were founded at a time when new frameworks (e.g. Angular) are much more mature.
edit: grammar
Backbone is doing a good job thus far establishing itself as a decent and reliable JS framework. Marionette addresses the specific pain points of view and event management in a larger app that Backbone leaves up to you out of the box.
edit: although interestingly, looking at the respective wikipedia entries, AngularJS has an initial release listed in 2009, Backbone.js is listed as October, 2010
You may be right, however, that it's just too early to get an apples/apples comparison between Backbone and Angular.
* Discourse
* Travis CI
* Practice Fusion
* Nitrous.io
* Embedly
* Balanced
* Customer.io
* Addepar
Not sure if you count other places like Square or Zendesk as startups, but they're using it too. We've also seen big companies like McGraw-Hill Education start building out their next generation technology using it.
You can find a longer list of users here:
I'm still on the hunt for a large, open source Angular app to see how their primitives scale up to solve more complicated problems. If anyone knows if such a thing exists, I would appreciate you pointing me in the right direction.
We're pairing it with Breeze (http://www.breezejs.com/) in order to preload all the entities when user logs in - hopefully achieving 0 waiting time when user clicks around. This part hasn't started yet, but I'm planning a series of blog posts once done.
Are no YC startups that you polled using it? Why not?
Are you using a client-side MV* framework? (Angular.js, Backbone.js, Ember.js etc) If so, which one?
So it's possible that Meteor users didn't feel they could answer. However, it was open ended, so people filled in other frameworks, like Derby.js.
The graph itself looks very neat. But as a medium for conveying information it's fucking useless.
I'm an amateur when it comes to JavaScript, but we had to jump through a lot of hoops to get a map based application working in Backbone (which was crawlable)-plus the performance was not as good as ... well,let me say competitors not using Backbone.
The best thing about Ember that I always tell curious newcomers is that Ember is both easy to make small apps with, but it's also trivial to keep expanding into really big apps. You can keep repeating the same pattern infinitely without rewriting old parts of the app, and without feeling like adding bulk to the app. I see our app as a large very flat structure. We can go in and replace every small piece in isolation to everything else.
My impression of something like Angular.js is that often when you want to add new features you have to go back and refactor a lot of stuff (just check out the cage match between Tom Dale and Rob Connery https://vimeo.com/68215606). It feels like a pyramid that will need a lot of maintenance to stay standing.
This is not the case with Ember. Ember was written by some very smart people, who have spent _a lot_ of time refining how an app should be developed in the long run. Features are prepared for the future. Both the future of browsers and JavaScript but also the future of developers' apps.
I am sure that Ember will prevail over all the other frameworks within the next year and stay on top for many years to come.
I have now joined another startup and am using Ember to build a somewhat ambitious web application and so far I am on cloud9 wrt the experience. I think the recent additions of the formalized Components api, the new much more flexible Router, and the prevailing ease of preserving URLs makes Ember a pretty obvious win for a certain class of applications.
As a quick comparison, I built a small embedded application in both backbone (as idiomatic as possible) and Ember and the BB version was 3x the LOC and much more difficult to reason about.
Steve
http://www.bennadel.com/blog/2439-My-Experience-With-Angular...
I've been using AngularJS for more than three months now and feel like I finally reached a tipping point where the months of agony are starting to pay off. Before switching to AngularJS I used Backbone.js extensively and tried out Ember.js.
The biggest thing to realize with AngularJS, I think, is that your entire front-end "stack" needs to be re-evaluated. Having been using CoffeeScript for a long time, I actually ended up taking it out of all my environments so that it would be easier to debug and understand my JS code as it is "interpreted" by AngularJS. I also had to force myself to stop thinking in jQuery and learn to live with jqLite (which naturally pressures you to exercise restraint with by-hand DOM manipulation, angular.element, etc.,.). While it felt unnatural to me at first, writing directives became second nature after I understood how to properly use them and how powerful they really are. When evaluating JS libraries to include in my code, I now find myself asking whether they can be easily integrated in the "AngularJS" way (making D3.js work with AngularJS was great practice).
Secondly, we all need to face and accept that the current AngularJS documentation is crap and it doesn't look like it's going to get better anytime soon. In addition to that, I sometimes stumble upon a lot of poorly written (or outdated) AngularJS example code on blogs, videos and SO. I only began to understand what really goes on under the hood when I started stepped into AngularJS's function calls while debugging my code. I also found that much of the functionality is not yet documented or is documented poorly and lot of insights can be found in the code comments left by the Google folks.
Was it painful to learn and to use for a long time? Oh yes. Does it still sometimes cause me to tear my hair out? Absolutely. Do I think that it is worth it? Without a doubt.
Angular is interesting, but it's kind of staked out a position on the client side that is rather spectacularly orthogonal to my needs.
