Angular or Backbone: what are startups using? | Hacker News Reader

Angular or Backbone: what are startups using?

blog.backlift.com

64 pointscolevscode73 comments

If anyone's around the Boston area, we're actually doing the second BackboneConf tomorrow and Thursday in Cambridge, close to MIT. Last year there was a bunch of really lovely discussion about different approaches, different frameworks and libraries, and favorite tips and tricks for doing sophisticated applications in JavaScript. Looking forward to seeing some of y'all there.

I have used both in my startup job and vastly prefer angular to backbone, however I think it's not quite an apples to apples comparison as angular provides a lot more than backbone.

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

[2]: http://docs.angularjs.org/guide/di

[3]: http://docs.angularjs.org/guide/dev_guide.unit-testing

After spending two or three months with Angular, I’m running away screaming. I really owe people a blog post about it, but basically, it’s hard to debug, weird for weird’s sake, and polluting of the HTML namespace. Death by a thousand cuts — and by disregard for best practice.

I'd be interested to read about your issues with it. It is definitely weird, but I don't think it's for its own sake, rather it's adding a new layer of abstraction which will always come off as a bit strange until you get used to it, e.g. lisp.

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.

I do love having easy two-way data binding, too, certainly.

To clarify: When you use a directive with an "isolate scope", you have to pass it parameters in your template, which means using arbitrary "HTML attributes" in ways that do not, in fact, have anything to do with HTML attributes. E.g.:

<my-directive model="myModel.foo" compact="true"></my-directive>

Is it plausible that HTML eventually defines a meaning for `model` and/or `compact` attributes? Did you just write illegal HTML? Yes. Is there already a way to do this in HTML? Yes, the `data-*` attribute namespace is free to use.

The whole dirty-checking thing requires an insane amount of CPU work, sometimes. Once you’re doing 15 or 20 AJAX requests, your browser may use 100% CPU for minutes (and that’s on desktop)! Why? We aren’t exactly sure. But I have bumped into other people at local JS meetups who have experienced the same thing. (Their solution? Give up and use Backbone. Ours? Load fewer things. I think it may also be viable to do all your network requests out of the Angular context to avoid a full dirty-check cycle on each `readyStateChange` event, but that’s not entirely straightforward, either, since we used Angular services to create our models, which know how to load their own dependencies… ack… it’s a mess.)

FYI, you can prefix all of Angular's HTML additions with data-ng-* attribute.

    <my-directive data-ng-model="myModel.foo" compact="true"></my-directive>

That’s true for `ng-model` but is it true for parameters passed in to directives?

When you write directives you can define the attributes into which you pass parameters however you want, including making them HTML spec compliant.

Angular supports data-attributes as well.

Batarang[0] is chrome plugin that vastly helps with debugging angular. I also highly recommend approaching it from a TDD standpoint. The seed[1] project comes with a baked-in testrunner. This also helps you move away from direct dom manipulation unless absolutely necessary: treat it like the definition of an html DSL specific to your app.

0. https://chrome.google.com/webstore/detail/angularjs-batarang...

1. https://github.com/angular/angular-seed

I have to agree that it's hard to debug: AngularJS has this bad habit of complaining about an error without telling where it is. However, things really clear up once you dive in the source code. Now, I couldn't live without it :)

Polluting the HTML namespace? Have you looked at the emberjs (actually handlebars) generated html recently? View the generated output for everything that is bound and tell me you don't want to run away screaming.

Not sure about the methodology here. In addition to having my own startup using Ember.js, I'm constantly meeting with other startups building their business on it:

* 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:

http://emberjs.com/ember-users/

I should also call out that many of the above (Travis, Discourse, and Balanced) are all completely open source. They serve as a great learning resource for other companies building seriously ambitious apps.

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.

If you want to meet these folks in person, come by our meetups. Both the SF and NYC meetups routinely have attendance of 120+ people; it's like a mini-conference every month.

We're using EmberJS at Pertino too. edit: I see we are already on the ember-users link :)

Am I the only one whose brain was unable to parse the graphs as the article went on? By the time I hit the blue-orange switching diagram (for that's what it most closely resembled), I was fairly sure that I was being put on by the authors.

An object lesson in presentation vs. utility. UX/UI designers take note.

The graph itself looks very neat. But as a medium for conveying information it's fucking useless.

The bar graphs are easy for me to read. That last diagram looks like something from Tufte's worst nightmare though.

On a recent project I used pjax, because it was way simpler to figure out what the heck was going on, and it did not have a bunch of extra stuff that was difficult.

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.

I've found that when Angular starts to fight back, you need to rethink your assumptions. It's very opinionated.

What were you trying to do?

http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date...

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.

Funny to see my own blog post as a reference here, thank you.

On topic, it actually took me a while to figure out how it works. But now I understood it and similar problems later were solved in no time.

That said I think you need a while to really learn AngularJS before you should use it in your product. If you don't have the time then you might have a problem. You don't need to learn about the internals, which is good, but you definitely need to learn the core concepts.

Ahh. Gluing a jquery plugin into an angular app will always be hairy.

You may have been able to pick apart angular-ui to include only their datepicker directive.

Mixing jQuery and Angular just seems like a bad idea, to me...

Did you consider turbolinks as well as pjax? Not together, of course, I mean in addition to while evaluating what to use.

We're currently undergoing a complete frontend re-write (after we have proved with prototype we can make money) using Angular and I must say it's been an emotional rollercoaster with plenty of love and hate, but at the end of the day, love wins hands down. I haven't used much Backbone, so you could say I'm biased, but the truth is that Angular really teaches HTML new tricks (directives) which can save you days (or weeks) of development.

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.

This library looks awesome. I made an angular service that does the same thing but it took a lot of effort. What's your blog url? I'll add it to my rss and keep a look out for when you add this in.

You caught me off guard :) Our blog is currently being moved to another URL and redesigned to match our new brand, feel free to send me an email tomaz [at] codeable [dot] io - and I'll reply once it's back up.

I would be interested in reading a blog post about your experience with Breeze. How are you going to handle pagination as the database becomes larger?

We are using Ember.js for our upcoming release of billysbilling.com. It's a huge app. We already have 60 different routes and several hundred .js files.

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've played with both and I honestly still don't feel comfortable with computing the view on the client side instead of in my code on the server.

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?

Completely agree. I love these new frontend JS frameworks - particularly Angular, Facebook's React, and the Guardian's Ractive - technically they're fun to learn, mind-expanding, and really impressive work.

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.

That's how thus industry had operated throughout its, albeit short, history and will continue to do so. If Twitter/Facebook survive another 10 years, they'll do the server-/client-side tango another two iterations at least.

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".

Couldn't this same argument be made against native apps?

I'm not a native dev so I can only speculate, but based on my personal experience with Android the past few years, I don't think so simply b/c there's no better alternative yet, performance-wise at least.

On mobile, native still offers better performance and integration than html5/javascript apps, the network latency is more variable and less manageable than with wired broadband, and Android and iOS are tuned more to manage resource usage and even hibernate all but the currently active app if necessary.

And I'm not sure how much flexibility native SDK's provide developers to decide where things like rendering get done anyway. There's definitely some subset of stuff that can be done serverside, hence the existence of Parse and Stackmob, but I don't know the details. There may not be much choice in the matter.

I would argue that if that's even a choice for you than maybe Angular isn't the best solution.

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.

I've been wondering about client side vs server side view rendering as well. I am used to working with server side MVC frameworks so rendering the view client side is a bit odd to me. Is the ability for the end user to see some of the view markup (conditional statements, loops, etc) an issue?

Think of it like this: you still have model+controller at the server side (REST interface), the whole HTML+Javascript thing is the view layer. This view layer happens to be modeled using the MVC pattern, which is a pretty smart move if you are writing complex user interfaces.

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.

I wouldn't draw a strong conclusion about 'larger' startups using Backbone instead of Angular based on this data.

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

You may well be right but just to add a small data point in the other direction: I'm solo founding a new start up right now and chose to go with Marionette (which is essentially Backbone + some very handy batteries). Its been bliss (and this is coming from a backend guy who normally loathes frontend programming in JS).

Same. FWIW, I have used Backbone for a bunch of past projects (personal as well as large-scale apps for work). In my latest projects in both, I'm using Marionette on top of Backbone and I've been pleasantly surprised at how well it's working out when managing a complex SPA. I really appreciate Angular and what it's doing but every time I've tried to use it, it hasn't been the right fit. I'm hopeful for it though. Maybe eventually I can find a useful application for it!

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.

I've recently really come to appreciate marionette's application and module containers too, and I have really come to rely on all the event bus stuff that comes from backbone.wreqr.

Basically, marionette gets better.

Derek Bailey is a boss. His lost techies blog is great even if you aren't using marionette.

I'm not saying people aren't still choosing Backbone/variants today, just that 2 years ago, Angular was (1) not a nearly as viable an option and (2) not nearly as well known; so any time /company-size correlation will push the results in one direction.

edit: although interestingly, looking at the respective wikipedia entries, AngularJS has an initial release listed in 2009, Backbone.js is listed as October, 2010

There didn't appear to be a clear relationship between startup size and age in the responses. Many brand new startups had 3 or 4 developers, and several older startups were plugging away with just 2 devs.

You may be right, however, that it's just too early to get an apples/apples comparison between Backbone and Angular.

I think the obvious reason for Backbone and larger teams is that larger teams are more likely to be working on projects that have been around "a while" (being defined as say, more than a year). A year ago, Backbone was clearly a more popular choice. I didn't see anything in the article that corrected for that.

Please see my response to this issue here: https://news.ycombinator.com/item?id=6128668

I ran a start-up for several months and we moved from backbone to Ember in December after concluding that Ember was positioning themselves to provide a much more powerful suite of primitives for the type of apps we were targeting.

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

Of the two choices, I would definitely continue to use Ember.js. Backbone is disqualified due to obvious, reknowned scalability issues; most apps need a plethora of plugins and framework enhancers that jell dubiously and weigh your app down as much as a heavier framework like Angular or Ember, so why bother? Between Angular and Ember, I would take Ember's API over Angular's directive fanaticism any day.

We are using Backbone.js and loving it: https://wakati.me

I spent several years building backbone applications, and recently have been doing a lot of work with Ember and Angular. For most of the applications I work on, I find Angular to be a really excellent choice. It fits in very well as part of a larger app with "islands of richness". It's really quick to learn and become productive with. The ecosystem of existing components (directives in angular parlance) is huge. The choice of plain old html for templates means I can take screens of html/css produced with our design team and iteratively turn them into an angular app. And last but NOT LEAST everything is very easy to test thanks to DI.

Whenever someone asks me about learning and using AngularJS I link them to this helpful diagram:

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.

At https://starthq.com we use Angular. Here's a talk I gave that's both an introduction to Angular and a summary of our experiences: http://video.yandex.by/users/fdconf/view/4/ (slides here: http://www.slideshare.net/olegp/oleg-podsechinfrontendconf)

If I want to build a rich js app, with no hash tag URLs (meaning - Google can crawl everything), would you still use Backbone/angular.

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.

Probably not. If you tried to build something like StackOverflow where the interface is Google, then you will never be competitive using either Angular or Backbone. I say this as a person that likes Angular (but hates Backbone).

We're using backbone and marionette, because we re-use a lot of code on the front-end and the backend, including the ability to render the initial page on the server.

Angular is interesting, but it's kind of staked out a position on the client side that is rather spectacularly orthogonal to my needs.

Is it even fair to do a straight comparison? Each has their own plusses and minuses I'm assuming - I'm actually quite ignorant on the topic. Can anyone provide a brief breakdown of pros/cons over each.

How does Meteor fit in to all of this?

Are no YC startups that you polled using it? Why not?

Currently using Meteor for my startup, I foresee scalability issues down the line (which the meteor devs are currently working on) but for cranking out a MVP its a pretty nice framework.

Are you doing any unit testing? I found Meteor to be a unit testing nightmare.

The question about frameworks in the original poll was worded like this:

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.

Mehhh I still don't know what either of these frameworks do that can't be done server side.

Change the dom without requiring a round-trip to the server and a full-page refresh :)

The sample size ("over 30") is really too small to draw many conclusions. Then again, it's a larger sample size than the typical ranting blogger (sample size of 1) who likes/dislikes a given stack.

Neither :)

Joose js to create classes!! The best!

Pop culture at it's finest.

Do enlighten us, won't you?

he is a javascript god after all.

Solving problems is part of writing software.

Which is only partly true.

Better way of putting this; why don't startups write their web apps in x86 assembly?

Because not having problems in the first place is the sign of a 'good' programmer.

Which is also only partly true.

Good teams know when something needs less abstraction, to be sure. The same can also be said about the known knowns of what you are dealing with, and minimizing the risk involved with being ahead of the curve.

If using Backbone and/or Angular is not directly beneficial to the end user, I wouldn't recommend it on the projects I've worked on. That's not to say I would be against it; I just have found that in cases where I could have recommended it, it was for the benefit of the team instead.

Reply on news.ycombinator.com