
Angular or Backbone: what are startups using? - colevscode
https://blog.backlift.com/entry/front-end-frameworks
======
jashkenas
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.

------
singular
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](http://docs.angularjs.org/guide/directive)

[1]:
[http://docs.angularjs.org/api/ng.$rootScope.Scope](http://docs.angularjs.org/api/ng.$rootScope.Scope)

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

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

~~~
alanh
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.

~~~
singular
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.

~~~
alanh
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.)

~~~
evilduck
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>

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

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

------
tomdale
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/](http://emberjs.com/ember-users/)

~~~
tomdale
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.

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

~~~
na85
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.

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

~~~
lucidrains
What were you trying to do?

~~~
davidw
[http://www.grobmeier.de/angular-js-binding-to-jquery-ui-
date...](http://www.grobmeier.de/angular-js-binding-to-jquery-ui-datepicker-
example-07092012.html#.UfgP0cX2UgQ)

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.

~~~
grobmeier
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.

------
tzaman
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/](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.

~~~
Justen
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.

~~~
tzaman
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.

------
seilund
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](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.

------
ChikkaChiChi
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?

~~~
SkyMarshal
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...](https://blog.twitter.com/2012/improving-performance-twittercom)

[2]: For desk/laptops at least. Need a Moore's Law for batteries for mobile.

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

~~~
SkyMarshal
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.

------
psgibbs
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

~~~
corford
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).

~~~
kcent
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.

~~~
AdrianRossouw
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.

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

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

~~~
colevscode
Please see my response to this issue here:
[https://news.ycombinator.com/item?id=6128668](https://news.ycombinator.com/item?id=6128668)

------
stevekane
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

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

------
welder
We are using Backbone.js and loving it: [https://wakati.me](https://wakati.me)

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

------
zkirill
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...](http://www.bennadel.com/blog/2439-My-Experience-With-AngularJS-
The-Super-heroic-JavaScript-MVW-Framework.htm)

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.

------
olegp
At [https://starthq.com](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/](http://video.yandex.by/users/fdconf/view/4/)
(slides here: [http://www.slideshare.net/olegp/oleg-
podsechinfrontendconf](http://www.slideshare.net/olegp/oleg-
podsechinfrontendconf))

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

~~~
jcampbell1
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).

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

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

------
bravura
How does Meteor fit in to all of this?

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

~~~
wc-
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.

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

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

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

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

------
basicallydan
Neither :)

------
hernan604
Joose js to create classes!! The best!

------
javascriptgod
Pop culture at it's finest.

~~~
jbail
Do enlighten us, won't you?

~~~
wnevets
he is a javascript god after all.

