20 ms·

Angular or Backbone: what are startups using?

64 points by colevscode 13y ago

psgibbs 13y ago
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
- colevscode 13y ago
  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.
- corford 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        Derek Bailey is a boss. His lost techies blog is great even if you aren't using marionette.
  - psgibbs 13y ago
    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
javascriptgod 13y ago
Pop culture at it's finest.
- jbail 13y ago
  Do enlighten us, won't you?
  - wnevets 13y ago
    he is a javascript god after all.
- grinich 13y ago
  Solving problems is part of writing software.
  - bigdubs 13y ago
    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.
    - ChikkaChiChi 13y ago
      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.
davidw 13y ago
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.
- warfangle 13y ago
  I've found that when Angular starts to fight back, you need to rethink your assumptions. It's very opinionated.
- lucidrains 13y ago
  What were you trying to do?
  - davidw 13y ago
    http://www.grobmeier.de/angular-js-binding-to-jquery-ui-datepicker-example-07092012.html#.UfgP0cX2UgQ 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.
    - grobmeier 13y ago
      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.
    - warfangle 13y ago
ismyrnow 13y ago
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.
Zaheer 13y ago
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.
jasallen 13y ago
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 13y ago
  Please see my response to this issue here: https://news.ycombinator.com/item?id=6128668 https://news.ycombinator.com/item?id=6128668
ChikkaChiChi 13y ago
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?
- hadem 13y ago
  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?
  - scardine 13y ago
    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.
- SkyMarshal 13y ago
  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-twittercom https://blog.twitter.com/2012/improving-performance-twitterc... [2]: For desk/laptops at least. Need a Moore's Law for batteries for mobile.
tzaman 13y ago
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 13y ago
  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 13y ago
    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.
- atomical 13y ago
  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?
bravura 13y ago
How does Meteor fit in to all of this? Are no YC startups that you polled using it? Why not?
- colevscode 13y ago
  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.
- wc- 13y ago
  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 13y ago
    Are you doing any unit testing? I found Meteor to be a unit testing nightmare.
singular 13y ago
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 13y ago
  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 13y ago
    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.
hernan604 13y ago
Joose js to create classes!! The best!
olegp 13y ago
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)
angersock 13y ago
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 13y ago
  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.
- j_baker 13y ago
  The bar graphs are easy for me to read. That last diagram looks like something from Tufte's worst nightmare though.
moneyrich 13y ago
Google trends says angular is the recent winner by a huge margin.
welder 13y ago
We are using Backbone.js and loving it: https://wakati.me https://wakati.me
snake_plissken 13y ago
Mehhh I still don't know what either of these frameworks do that can't be done server side.
- tonyarkles 13y ago
  Change the dom without requiring a round-trip to the server and a full-page refresh :)
jashkenas 13y ago
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.
basicallydan 13y ago
Neither :)
zkirill 13y ago
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-AngularJS-The-Super-heroic-JavaScript-MVW-Framework.htm 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.
AdrianRossouw 13y ago
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.
sandGorgon 13y ago
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.
- deleted 13y ago
  [deleted]
- jcampbell1 13y ago
  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).
tomdale 13y ago
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 13y ago
  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.
- tomdale 13y ago
  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.
- chriscareycode 13y ago
  We're using EmberJS at Pertino too. edit: I see we are already on the ember-users link :)
stevekane 13y ago
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 13y ago
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.
seilund 13y ago
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.
superchris 13y ago
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.

64 points by colevscode 13y ago

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

colevscode 13y ago
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.
corford 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      Derek Bailey is a boss. His lost techies blog is great even if you aren't using marionette.
- psgibbs 13y ago
  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

javascriptgod 13y ago

Pop culture at it's finest.

jbail 13y ago
Do enlighten us, won't you?
- wnevets 13y ago
  he is a javascript god after all.
grinich 13y ago
Solving problems is part of writing software.
- bigdubs 13y ago
  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.
  - ChikkaChiChi 13y ago
    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.

davidw 13y ago

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.

warfangle 13y ago
I've found that when Angular starts to fight back, you need to rethink your assumptions. It's very opinionated.
lucidrains 13y ago
What were you trying to do?
- davidw 13y ago
  http://www.grobmeier.de/angular-js-binding-to-jquery-ui-datepicker-example-07092012.html#.UfgP0cX2UgQ 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.
  - grobmeier 13y ago
    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.
  - warfangle 13y ago

ismyrnow 13y ago

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.

Zaheer 13y ago

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.

jasallen 13y ago

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 13y ago
Please see my response to this issue here: https://news.ycombinator.com/item?id=6128668 https://news.ycombinator.com/item?id=6128668

ChikkaChiChi 13y ago

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?

hadem 13y ago
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?
- scardine 13y ago
  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.
SkyMarshal 13y ago
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-twittercom https://blog.twitter.com/2012/improving-performance-twitterc... [2]: For desk/laptops at least. Need a Moore's Law for batteries for mobile.

tzaman 13y ago

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 13y ago
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 13y ago
  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.
atomical 13y ago
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?

bravura 13y ago

How does Meteor fit in to all of this? Are no YC startups that you polled using it? Why not?

colevscode 13y ago
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.
wc- 13y ago
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 13y ago
  Are you doing any unit testing? I found Meteor to be a unit testing nightmare.

singular 13y ago

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 13y ago
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 13y ago
  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.

hernan604 13y ago

Joose js to create classes!! The best!

olegp 13y ago

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)

angersock 13y ago

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 13y ago
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.
j_baker 13y ago
The bar graphs are easy for me to read. That last diagram looks like something from Tufte's worst nightmare though.

moneyrich 13y ago

Google trends says angular is the recent winner by a huge margin.

welder 13y ago

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

snake_plissken 13y ago

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

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

jashkenas 13y ago

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.

basicallydan 13y ago

Neither :)

zkirill 13y ago

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-AngularJS-The-Super-heroic-JavaScript-MVW-Framework.htm 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.

AdrianRossouw 13y ago

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.

sandGorgon 13y ago

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.

deleted 13y ago
[deleted]
jcampbell1 13y ago
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).

tomdale 13y ago

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 13y ago
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.
tomdale 13y ago
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.
chriscareycode 13y ago
We're using EmberJS at Pertino too. edit: I see we are already on the ember-users link :)

stevekane 13y ago

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 13y ago

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.

seilund 13y ago

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.

superchris 13y ago

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.