12 ms·

Rant: Backbone, Angular, Meteor, Derby

157 points by lefnire 14y ago

lefnire 14y ago
Cached at https://gist.github.com/4454814 https://gist.github.com/4454814 if down (my Drupal server has been miserable lately and I'm currently migrating to DocPad)
- deleted 14y ago
  [deleted]
- dustingetz 14y ago
  please provide more context about what type of app you're building. searching for "ember sucks site:news.ycombinator.com" and "backbone sucks site:news.ycombinator.com" is evidence enough that this isn't a simple comparison.
  - lefnire 14y ago
    I think it often is a simple comparison. Meteor & Derby, for example, are the exact same use-case - and I think in the end, one will survive the battle and the other lose steam. People say Backbone & Angular are different use-cases, but I find so many people "graduating" Backbone and wishing they'd chosen a more robust framework. They say they want to start minimal, so they pick Backbone. You can be minimal with Angular. It's like saying "ms paint or photoshop? Well what are you trying to do?" There's only 1 or 2 people really trying to draw something in Paint, the rest "think" they want minimal, non-bloated software. The answer to the question is Photoshop. Now, Rails v Node v Java, something like that - there are tons of questions to ask before making such a decision, there's no one-size-fits all. But I think there is a one-size in this particular case.
    - dustingetz 14y ago
      let me put it this way - right now, this month, im evaluating stacks for an enterprise-y amazon-y feeling thing. Say $XX million dollar budget, ~100k LOC with ~10 engineers (mostly cranky and old) for 7 months. i'm not sure if you're freelancing an app as a sole developer, or if you're an early stage startup, or if you work on amazon.com store. and where your project is, in this spectrum, is incredibly relevant context when you're dissing a framework.
      - lefnire 14y ago
        That's a very good point.
aioprisan 14y ago
actually, Meteor is not like Derby. For one, you don't need to deal with callbacks when data is changed. Meteor can automatically figure out what data sources are bound to certain containers in the template being rendered and when you make a change in the database, the data is pushed to all the clients. Here are some good details on the differences: http://news.ycombinator.com/item?id=3842525 http://news.ycombinator.com/item?id=3842525. Also, Meteor now has a REST package built-in https://github.com/crazytoad/meteor-collectionapi https://github.com/crazytoad/meteor-collectionapi and additional modules that you can install, like https://github.com/tmeasday/meteor-router https://github.com/tmeasday/meteor-router
- lefnire 14y ago
  !! Those REST packes enable server-side routes? I remember the last time I checked, when Meteor had it's new "server pages" it was Phantom generated snapshots of client renders, which blew my mind. I'll explore those packages, that was my biggest gripe and may motivate me to take down my post.
  - debergalis 14y ago
    [meteor dev] The `spiderable` package is just our hack to let search engines index our own website. It works surprisingly well for that, but it's certainly not the long-term solution. There's a fuller explanation of our routing / REST plan here: https://trello.com/card/page-model-server-side-rendering-rest-endpoints/508721606e02bb9d570016ae/7 https://trello.com/card/page-model-server-side-rendering-res...
  - sawyer 14y ago
    The meteor-router package does enable server side routing, yes. Take a look at the bottom of the README on github.
bejar37 14y ago
Recently decided to use Backbone as a JSMVC Framework on my team. Although I looked at Ember and Angular, which obviously both have many more features than backbone out of the box, We chose to use Backbone because it seems to have such a large and vibrant community behind it - seems like angular and ember are both lacking in this respect. However, as our Backbone application grew in complexity, we noticed that Backbone is so bare in terms of functionalities that we had to build our own half-baked framework on top of it to make up for the gaps. I think the Backbone project needs to make Backbone's intentional feature sparseness clear. I've come to realize that backbone is more of a library which provides a basis to make a client-side framework rather than a something that can be used standalone by app developers. If I could go back and change our original choice, I definitely would have gone with one of the Backbone-derived frameworks (chaplin, marionette) or just gone with something more fully-featured like angular. While backbone is beautiful and elegant for small projects, it just doesn't provide much convenience as a stand-alone library for larger applications.
- drewda 14y ago
  I've had a very similar experience and am also figuring that on my next "greenfield" project I'll try Marionette.
- blissofbeing 14y ago
  I have found the Angularjs community to be thriving and most helpful. Check out their google group (1), g+ page (2), g+ community (3), irc room (4) and youtube channel (5) for an excellent place to get help. I usually get help as soon as I need it, amazing. Also I have been impressed with the active community projects AngularStrap (6) and AngularUI (7) 1) https://groups.google.com/forum/?fromgroups#!forum/angular https://groups.google.com/forum/?fromgroups#!forum/angular 2) https://plus.google.com/110323587230527980117/ https://plus.google.com/110323587230527980117/ 3) https://plus.google.com/communities/115368820700870330756 https://plus.google.com/communities/115368820700870330756 4) http://webchat.freenode.net/?channels=angularjs&uio=d4 http://webchat.freenode.net/?channels=angularjs&uio=d4 5) http://www.youtube.com/user/angularjs http://www.youtube.com/user/angularjs 6) http://mgcrea.github.com/angular-strap/ http://mgcrea.github.com/angular-strap/ 7) http://angular-ui.github.com/ http://angular-ui.github.com/
idan 14y ago
Same post, easier on the eyes (particularly on mobile): http://gist.io/4454814 http://gist.io/4454814
dotborg 14y ago
all of them will become obsolete once ecmascript.next kicks in
- lefnire 14y ago
  Do tell
  - dotborg 14y ago
    I'm just reading HN and in discussions between one of news about ES.next, the conclusion was that it will happen... complete rewrite of everything and it's not like it will happen immediately, we need some time to discover best practices with new language features
jtchang 14y ago
Try knockout. I wrote a quick intro to it a few days ago: http://returnbooleantrue.blogspot.com/2012/12/architecting-knockoutjs-applications.html http://returnbooleantrue.blogspot.com/2012/12/architecting-k... I personally don't like backbone that much. I don't know why so many people love the damn thing. It is hard to understand and not even that great.
- johnnymonster 14y ago
  I personally use knockout all the time. Can't stand backbone or angular after using knockout.
  - hnwh 14y ago
    Backbone I understand, but why not angular? It seems quite similar to knockout to me? Whats your backend platform?
    - CapnCrooked 14y ago
      I just finished evaluating frameworks for a project and chose Knockout over angular for a couple of reasons: Extensibility & hooks: Extending built in behavior in Knockout was much easier than in Angular. Without getting into too much detail, one of the things I tried to do was create a list of items on the page with a simple animation for item removal. In Knockout, it was trivial. In angular it would have required a copy-pasta style rewrite of the repeat directive. Some weird missing features: Angular has no conditional add/remove element directive (that I could find). This just seems like a weird oversight. There's a show/hide element directive, but trying to substitute that for add/remove will break CSS first/last/nth child selectors. Angular has a lot of potential, but it felt to me like it needs a few more iterations before I'd want to try to build a rich UI on top of it.
      - ganarajpr 14y ago
        You are right about the first situation. Currently doing animations with Angular is not a trivial task. This is mostly because of its "No DOM manipulation in Controllers clause". If you break that clause, having a repeat with animations is possible ( not trivial - but possible! ). Angular does have a conditional add/remove element. You can use ng-switch for that. If you are using CSS selectors in an angular app I sense a smell. Something is not right.
sergiotapia 14y ago
We use Backbone at my place of work but Angular.js looks sooooo clean, it makes me wish it would have come out sooner so I could have pushed for Angular.js.
jacquesc 14y ago
Agreed on Backbone. It's awesome, but have had transition to Ember as I take on more complex UI frontend work. Trek summed it the best I could hope for: http://trek.github.com/ http://trek.github.com/
freshhawk 14y ago
> It’s like Gentoo users proselytizing Gentoo to the masses, perpetuating it as most common Distro; where all this time, Ubuntu would have saved everyone countless hours. I find this a pretty good metaphor for the backbone/angular/ember distinction, highlights that this complaint is the old "I can't imagine anyone needing more flexibility than I do, so those other people are obviously wasting their time". Nice parallels to PG's famous blub paradox essay as well.
joshontheweb 14y ago
Ok, you like angular. I don't. It has too much magic and forces you to pollute your html with ng attributes. Blanket statements about frameworks like this grow old. So much of the decision comes down to individual preference and the needs of the project. No need to rant about it. I can't really speak on derby vs meteor but I imagine it's the same.
- lefnire 14y ago
  It's not like that. I'm saying use Angular, Ember, Knockout, whatever - just not Backbone. Unless you know Backbone is what's needed for your project, or you yourself really love Backbone. What I'm discouraging here is its popularity as the de-facto client MV*. I'm under the impression that most people today, when thinking about their next JS project, will use Backbone because it's the most popularly-touted framework where It shouldn't be. It's a great framework, and die-hards & specific projects should indeed use it. But the majority should use one of the other frameworks.
  - ricardobeat 14y ago
    Ember, Knockout, Angular, Batman, all have data-binding in their core. Backbone doesn't. If you like writing client code where you have control over rendering and DOM manipulation, Backbone is the best choice short of building your own framework.
    - joshontheweb 14y ago
      Agreed. Also backbone gives you the flexibility to use it on the backend or as the data models behind a canvas app or other kinds of non-html rendering.
  - joshontheweb 14y ago
    Probably should have said that in your article if thats what you meant. It came off as a pretty insular point of view with 'rant' in the title.
    - 14y ago
heyitsnick 14y ago
I wanted to use Ember, and I started going down that road, but I just didn't click with it. I didn't progress past the tutorial! I can't remember what exactly I didn't get working, but I just felt very lost and overwhelmed, and that was spending a couple of days reading around online, looking at the code and examples.* I switched to Backbone and got going right away, in half a day of reading the docs and watching a couple of peepcode videos and I was off and didn't look back. Maybe the Ember docs have improved in the last couple of months but at the time it was just a non-starter for me. edit: I believe the issue was around Ember Data/REST. Out of the box it didn't support polling data on a REST interface, which seemed absolutely critical/fundamental to a JS framework. I found a plugin I believe called Ember Data, but documentation was very sparse and I couldn't even get a simple example going. This is going on memory so this could be slightly wrong or different today.
- atomical 14y ago
  I experienced the same thing with Ember Data/REST.
- MattRogish 14y ago
  We use Ember + Rails at work and if we didn't start with an Ember expert contractor we'd have been sunk. Ember is definitely a winding maze of stuff and until there's a "Agile Web Development with Ember 1.0" book, it's still very difficult to just jump in from scratch. Still, once we've learned Ember we're very happy with it. Backbone is just too small to start any medium/large app, and Ember has a decent community behind it and lots of integrations with Rails.
  - typicalrunt 14y ago
    What function is the Rails component serving? Is it just a REST interface or is it also acting as a separate HTML interface?
    - steveklabnik 14y ago
      We're working on https://github.com/rails-api https://github.com/rails-api to make Rails a great backend for APIs, and specifically Ember. Team is mostly Rails Core members and Ember team members. The hope is to make it awesome for other JS frameworks too, but we mostly build Ember apps ourself, so you start with what you know...
debergalis 14y ago
[meteor dev] Please come help us with this! We have six engineers at Meteor and dozens more contributors in the community working on the platform every day. The plan to 1.0, including REST, is at http://roadmap.meteor.com/ http://roadmap.meteor.com/. Here's the guiding principle behind Meteor. There should be a dramatically faster, more accessible way to write applications. Improving that developer experience means rethinking some things: autopublish and minimongo, so you can jump right into a new app's UX in the first five minutes; one-line authentication (http://meteor.com/authcast http://meteor.com/authcast); synchronous APIs that are more comfortable for a lot of developers; dirt-simple reactive templates; hot code push. Focusing on that kernel of development experience means some other things -- REST, routing, form building -- need more time to fully bake, with hacks like __meteor_bootstrap__ and phantom for apps that need them now. We think that's a good tradeoff pre 1.0.
- eranation 14y ago
  Meteor is one of the most exciting things I've seen recently. Will gladly help, what things you need most and how one get started? and do you accept people that like TypeScript, Java, Scala and come from the enterprise world? :)
  - debergalis 14y ago
    Yeah, absolutely. See http://roadmap.meteor.com/ http://roadmap.meteor.com/ for the high-level view and http://github.com/meteor/meteor/issues http://github.com/meteor/meteor/issues for some starting points on building out code. Another good option is building Atmosphere packages at http://atmosphere.meteor.com/ http://atmosphere.meteor.com/.
- d0m 14y ago
  I was excited using meteor but was sadly disappointing after a couple days of "banging my head on every simple things I tried". As far as I'm concerned, Meteor is a big "Screw everything that exist, it sucks. We're better and we've got the time and money to re-build all the life from scratch". So, in a way, that's great! An mental orgasm for any nerds out there. But in the real life when shit needs to get done, I'm still using everything else that sucks. Now, before people start saying I don't know what I'm talking about, here are a few examples: - It does NOT use npm (!) -> Basically, you can't use anything without first converting it to Meteor. - It does NOT use Express (Or connect) as its base -> Basically, the standard in the Node community. That means I can't just plug-in the 20 or so awesome plugins built explicitly to be used by any kinds of node application that support connect.js - The current Asynchronous (following node's philosophy) wasn't good enough for them; so the re-created a whole new Mongo version acting synchronously. But most importantly, it's just extremely annoying to hack with it. It's like a big black box.. you're not very sure what it does and you hope it works. But when it's not working, you can't just hack it your way or read the source. It's a little bit like Django or Rails (but in worst) as you can use SQLAlchemy in Django, or you can use different template engines, but then no project from the django community will work with your app. The good news is, the meteor team is working hard. Maybe in a couple years it will be stable enough and iterated fast enough to provide a platform where it will be fun hacking and building web apps. But for now, I sadly prefer to stay in the "Everything else sucks" world and hack my way in the node jungle. (For those interested, I have also tried Derby. As said in the article, it's not yet fully stable and the documentation is really Meh. But I think it's going to be big really soon and I'll be more than happy to give it another fair try. So far, I'm sticking to a basic express (Or locomotive.js which is nice.) I'm also using Angular.js on the front-end. It's something amazing as I feel very productive and it saves a tremendous amount of time.. but at other moment, I just bang my head against the table as I want to do something simple and it's just impossible so I need to use all kind of hacks to do what I'd have done in a couple lines in Vanilla Javascript. Oh well. Hard to be a hipster web developer trying all new technologies :-))
hhuio 14y ago
angular code is a joy to write and read!
cookingrobot 14y ago
Derby looks interesting, but their sample apps (chat and todo) crash and hang safari on my iPhone. Are folks sure its acceptable for mobile focused web apps? Is this a known problem or something unique to me?
- lefnire 14y ago
  That's that public-face failure bit I pointed out in my post. My own Derby app https://habitrpg.com https://habitrpg.com is smooth-sailing, but people's first impression Derby's home-page examples. For a lot of people, the buck stops there - unbeknownst to them, it's quite stable at HEAD
davidw 14y ago
I have a rant coming about these things too. * I started out with Backbone. It seems ok as far as it goes, but a bit annoying in that there's enough "magic" and stuff going on that I don't quite understand it completely, but without enough magic to really make things simple and easy. * Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-datepicker-example-07092012.html http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being. Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance. I found that very irritating about the Angular tutorial, which is otherwise very nicely put together. Now I'm testing out jquery-pjax, and... so far I'm happier. It behaves more like a web application that I'm used to, sending around HTML, and staying out of my way. And, seeing as how all of these things require that the server do its job in any case, it has more of a "don't repeat yourself" feel to it: click on the button, and the server gives us some new data, without repeating the whole MVC cycle on both the client and server. I got the idea from this post: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...
- Angelo7 14y ago
  "Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance." Couldn't have said it better myself. I can't count the number of times I had been excited about learning some new framework, only to discover that their documentation is non-existent, poor, or written for rocket scientists.
- robomartin 14y ago
  > jquery-pjax What happens to SEO?
hellopat 14y ago
I'm working on an app which uses Ember 1.0.0pre-2. Over the past few weeks I've been lazy / busy doing other things so the project was set aside for a bit. I came back to it yesterday, opened the guide page (http://emberjs.com/guides/ http://emberjs.com/guides/) and noticed it had been updated. I was excited and immediately checked the Router section. The guide reflects a brand new router API, which from what I've read makes it much easier to control the state of your application. The problem with Ember right now is the documentation doesn't align with the most recent public version, which will confuse the heck out of newcomers and frustrate people who are still learning Ember. You can however, check out master to get the new router implementation. I'm personally making the jump to the bleeding edge for two reasons: 1. The old router API is very hard to grasp. A lot of unknowns as far as where domain code fits when building your application using the router. 2. I don't want to be stuck struggling to find documentation for an already difficult API to work with. With all that said, Ember is worth taking a look at as far as an 'improved' MV* experience, but you have to be careful as it is in a state of flux.
- rxcfc 14y ago
  Sorry about this, we're going to be cutting a new release soon so that should resolve this discrepancy.
coenhyde 14y ago
Marionette (a framework built on backbone) offers a nice solution. It still keeps things pretty light but does a lot of the groundwork you would normally have to do with backbone for you. Eg cleaning up event bindings, provides a region/view manager and an application wide event bus.
- krebby 14y ago
  I'd also recommend looking into Chaplin for stronger routing / app design. It's got a great CollectionView, which is one of the most common use cases for Backbone (also seems to solve a lot of the gripes with plain Backbone
  - drivebyacct2 14y ago
    Chaplin is a mess. I need node, npm, build a bunch of stuff from scratch? I've already lost interest (I looked at Chaplin a few months ago and honest to God couldn't even figure out what the hell it did besides download various crap to a /lib/ dir. Aren't there six dozen tools that do that?)
stesch 14y ago
Apache Derby? http://en.wikipedia.org/wiki/Apache_Derby http://en.wikipedia.org/wiki/Apache_Derby Am I missing something here? Maybe next time put some links into your rants. Apache Derby was the only one I found on Wikipedia.
- callmevlad 14y ago
  http://derbyjs.com/ http://derbyjs.com/
- lefnire 14y ago
  woops, I added links into the rant.
sgdesign 14y ago
I can only speak for myself, but the reason I use Meteor (http://telesc.pe http://telesc.pe) is because I believe that while it's not perfect right now, it has a bright future ahead of it. The Meteor devs themselves will acknowledge that some features are lacking (I imagine that's why it's not 1.0 yet), but the roadmap looks very promising and I believe Meteor also has the right team to make all this come true.
- lefnire 14y ago
  Good to have you here, telesc.pe has been an awesome showcase for Meteor.
- doctorpangloss 14y ago
  The reason I used Meteor (http://redacted.meteor.com http://redacted.meteor.com / https://github.com/doctorpangloss/redacted https://github.com/doctorpangloss/redacted) is because it is fast, exceedingly simple, and gets you a working program in five minutes.
taylorbuley 14y ago
Backbone is a thoughtfully minimalistic approach to prototypical binding. There's no magic. If you need more than that -- automagic binding using HTML data attributes via Angular -- it's OK to use another library.
adolph 14y ago
Discusses Derby: http://derbyjs.com/ http://derbyjs.com/ Not Apache Derby: http://db.apache.org/derby/ http://db.apache.org/derby/
deleted 14y ago
[deleted]
dignifiedquire 14y ago
I switched from backbone to angular about half a year ago. It was the best thing that ever happened to the project I was working on. I've rebuilt the complete interface using angular in 2 days. The original backbone version took me weeks (I learned both frameworks from the ground up while writing the interface) It was just a joy to see how databinding and promises where working hand in hand to make my life as a developer so much easier.
- EdwardMSmith 14y ago
  As a person that switched from Backbone to Angular, can you explain models in Angular (from a Backbone standpoint)? I've looked over the docs, and as far as I can tell there really isn't a model in Angular - not anything concrete anyway. The docs seem to explain that any JS object is a model as long as you make some reference to it. Or, is an angular Controller (+ some JS data structure) really a model. Its quite confusing to me.
  - pebb 14y ago
    Angular model is just any normal js object you want, then via two way binding it gets displayed without you doing any work. Freakin awesome.
  - lopatin 14y ago
    I can't explain in terms of Backbone but I'll do my best to clear things up for you anyway. In Angular, you have a magic $scope variable that is available both in your controller function, and in the section of HTML that the controller is bound to. Now I can set any attributes I want to the $scope variable and they will act like models for that controller. For example. Within my controller, I set $scope.username to "alex" and this will update any HTML bound to the value "username", within the scope, to "alex". Similarly, I can set, say, $scope.settings = {user: {username: "alex"}} and this will update any HTML elements (within the scope) bound to settings.user.username to "alex". These are very simple examples, but they show the beauty of having plain JS objects as your "models".
lefnire 14y ago
@KaoruAoiShiho where did you go?? That was a great response, put that back up
marknutter 14y ago
I've been using angular.js for a while now and there are a few reasons why I've really liked it: - dependency injection: because everything is injected, it makes writing isolated unit tests very easy. It also makes it very easy to swap functionality in and out without affecting other parts of the app. - two-way data-binding: most of the pain of being a javascript developer comes from managing and manipulating the DOM. After using angular, there is no way I will ever use a framework that doesn't automate this tedium by providing two-way live data-binding (knockout, meteor, and ember all do this). The best part about having less DOM manipulation code is that it makes writing automated tests easier and makes those test much less brittle. - extending HTML: this is often a main complaint of angular. People say that directives "pollute the DOM" which I find to be a strange complaint, given that HTML is a declarative (sometimes) semantic language to begin with. HTML5 added a ton of new attributes and features yet nobody complained that these new tags were "polluting HTML". Angular simply allows you to extend HTML's functionality even further, and in doing so it makes it very easy to understand what an HTML template is trying to do without having to dig through any JS code. - testing: the angular team made testability a priority, which I was something I always really appreciated about the Rails team. If you're not writing tests for your javascript code, you need to start. Having full test coverage in both end-to-end tests and unit tests has been a major source of stability for me and my team.
- wilmoore 14y ago
  because everything is injected, it makes writing isolated unit tests very easy I agree with that statement regarding DI; however, have you evaluated whether you NEED a DI container or just DI? Angular forces you into a container even if you don't need it. Is that what you really wanted? If so, fine, just be sure :)
shuzchen 14y ago
Straight from the backbone faq: "Backbone.js aims to provide the common foundation that data-rich web applications with ambitious interfaces require — while very deliberately avoiding painting you into a corner by making any decisions that you're better equipped to make yourself." I think the problem is people come into Backbone.js thinking it's a full fledged MVC framework for in-browser apps, instead you should think of it as a minimalistic set of tools with which to create your own framework (and in fact, a few actual frameworks have been released that are built on top of backbone.js). One way to taxonomize frameworks is on how opinionated it is - Backbone.js is on the far end of the unopinionated side. If that's what you like, then Backbone.js is for you. If you want something more out-of-the-box, you should be considering the other options.
sunwukung 14y ago
similar growing disenchantment with Backbone. Minor gripe re: Angular - if you're working with a server side templating language (i.e. Flask/Jinja) you have to configure it to use alternative tags, which could cause problems if working with any 3rd party libs.
- ganarajpr 14y ago
  Regarding Angular : You can use the data-ng-* way of adding the ng- attributes. Since data-ng- is HTML5 compliant most major server side templating systems should let it pass through. If you are using custom elements, then you have to figure out a way for your templating system to let it through. In grails for example, you can override it in the taglib's to do that.
sontek 14y ago
It doesn't make sense to compare Backbone to any of these. Backbone is a low level library for getting you started. If you are looking for something easy to use to get you going you just use one of the frameworks built on top of Backbone, I suggest Marionette.
jashkenas 14y ago
"It seems that most people today, when thinking about their next JS project, will use Backbone because it's the most popularl framework when it shouldn't be." (sic) Here's a long list of examples why maybe it should be: http://backbonejs.org/#examples http://backbonejs.org/#examples In comparison, here's the public list of interesting apps built with Angular and Derby: http://builtwith.angularjs.org http://builtwith.angularjs.org https://github.com/codeparty/derby/wiki/Community-Projects https://github.com/codeparty/derby/wiki/Community-Projects What you want to look for in a library goes beyond feature checklists and magic datepickers. Lots of client side developers have been burned in the past by JavaScript frameworks that promise the world and end up getting in the way more than they help. Backbone tries to provide the barest useful essentials -- the main business of building your app is up to you.
- dmvaldman 14y ago
  You use this argument a lot, but the ranter suggests that the reason many turn to Backbone is because of a self-selecting bias of it being the most popular.
  - jashkenas 14y ago
    It's certainly my favorite argument. Folks sometimes forget that pre-Backbone, there was a cornucopia of rich JavaScript framework options: YUI, SproutCore, Dojo, EXTjs, UkiJS, JavaScriptMVC, Cappuccino, and so on. If Backbone has become a bit popular over the last couple years, perhaps it's because it tries to do less than the excellent pre-existing alternatives.
  - tjholowaychuk 14y ago
    there is something to be said about flocking to a framework purely based on popularity, Rails is a great example of that too, you sure as hell don't need it for most projects but there are a lot of developers familiar with it, whether it's good or not is another thing
- skb_ 14y ago
  Backbone tries to provide the barest useful essentials -- the main business of building your app is up to you. I personally prefer minimal frameworks because they don't assume what your finished product will look like. You can grow the application organically rather than trying to fit it into some prototypical mold. Full-fledged frameworks have their uses - they are perfect for getting up and running on known problems. But if you are trying to bake things into an already mature code base or trying a totally different style of architecture, they are not worth the work.
conradfr 14y ago
As a mediocre Javascript dev, AngularJS was the first library that clicked for me and helped me avoid the jQuery soup code I was doing more and more as a result of less code on the server and more on the client. It can be a bit daunting when you are not a JS rockstar : directives and services code architecture, designing views without straight conditional logic, understanding the full power of filters and expressions (I still don't), using jQuery plugins with it etc. I don't even use routes or forms yet but I had no problem integrating it into a "classic" web app. The docs need some work though, maybe with more example on certain part. But you can find great code snippet and videos elsewhere.
danso 14y ago
How did this get so many upvotes? It's a short rant that basically boils down to "Fuck Backbone, use Angular instead" In fact, here is a verbatim quote: "Angular is awesome. That is all." And here's the technical basis of why Angular is better than Backbone: "Now, I'm not suggestion people don't use Backbone. Use it if it's what's needed for your project, or you yourself are a Backbone ninja. What I'm discouraging here is its popularity as the de-facto client MV*" I've played around with Backbone and appreciate its structure. I've never used Angular but have seen many compelling posts on HN arguing why it is a better choice in certain use cases. This rant offers no evidence or elaboration. Is it now cool just to hate the popular thing just because it's popular? Even rants against Facebook and Apple have more substance than the OP.
- lefnire 14y ago
  It got upvotes (1) because nobody's talking about Meteor v Derby, (2) because people agree. I'm not the only one wondering why Backbone is de-facto - look at all these responses, 80% of them are agreement. That surprised me, I thought this thread would be buried. Many (like you) think this as insular and inane. I left out detailed explanations of Backbone cons and Angular pros just to get the conversation rolling, and indeed the comments took care of that entirely.
danenania 14y ago
I'll chime in with the requisite "90% of the time, don't use an mvc framework in the browser." Don't build up a mountain of state for no reason. Use functions and composable, lightweight, short-lived classes. If I had to choose the 'best' javascript development framework, I'd choose clojurescript, not because it's such a great tool in itself (it is a great tool, though still a bit immature), but because it forces the developer to write javascript in the best possible way: functionally, only holding onto state when it's absolutely necessary. It's good that there are solid mvc frameworks out there for when they are truly needed, but when the average developer picks one up for a routine web app just because it's the hot new thing, he/she's walking into a minefield for no good reason. Javascript is at its best when it's just a dumb, fast bridge between your server and your ui.

157 points by lefnire 14y ago

Cached at https://gist.github.com/4454814 https://gist.github.com/4454814 if down (my Drupal server has been miserable lately and I'm currently migrating to DocPad)

deleted 14y ago
[deleted]
dustingetz 14y ago
please provide more context about what type of app you're building. searching for "ember sucks site:news.ycombinator.com" and "backbone sucks site:news.ycombinator.com" is evidence enough that this isn't a simple comparison.
- lefnire 14y ago
  I think it often is a simple comparison. Meteor & Derby, for example, are the exact same use-case - and I think in the end, one will survive the battle and the other lose steam. People say Backbone & Angular are different use-cases, but I find so many people "graduating" Backbone and wishing they'd chosen a more robust framework. They say they want to start minimal, so they pick Backbone. You can be minimal with Angular. It's like saying "ms paint or photoshop? Well what are you trying to do?" There's only 1 or 2 people really trying to draw something in Paint, the rest "think" they want minimal, non-bloated software. The answer to the question is Photoshop. Now, Rails v Node v Java, something like that - there are tons of questions to ask before making such a decision, there's no one-size-fits all. But I think there is a one-size in this particular case.
  - dustingetz 14y ago
    let me put it this way - right now, this month, im evaluating stacks for an enterprise-y amazon-y feeling thing. Say $XX million dollar budget, ~100k LOC with ~10 engineers (mostly cranky and old) for 7 months. i'm not sure if you're freelancing an app as a sole developer, or if you're an early stage startup, or if you work on amazon.com store. and where your project is, in this spectrum, is incredibly relevant context when you're dissing a framework.
    - lefnire 14y ago
      That's a very good point.

aioprisan 14y ago

actually, Meteor is not like Derby. For one, you don't need to deal with callbacks when data is changed. Meteor can automatically figure out what data sources are bound to certain containers in the template being rendered and when you make a change in the database, the data is pushed to all the clients. Here are some good details on the differences: http://news.ycombinator.com/item?id=3842525 http://news.ycombinator.com/item?id=3842525. Also, Meteor now has a REST package built-in https://github.com/crazytoad/meteor-collectionapi https://github.com/crazytoad/meteor-collectionapi and additional modules that you can install, like https://github.com/tmeasday/meteor-router https://github.com/tmeasday/meteor-router

lefnire 14y ago
!! Those REST packes enable server-side routes? I remember the last time I checked, when Meteor had it's new "server pages" it was Phantom generated snapshots of client renders, which blew my mind. I'll explore those packages, that was my biggest gripe and may motivate me to take down my post.
- debergalis 14y ago
  [meteor dev] The `spiderable` package is just our hack to let search engines index our own website. It works surprisingly well for that, but it's certainly not the long-term solution. There's a fuller explanation of our routing / REST plan here: https://trello.com/card/page-model-server-side-rendering-rest-endpoints/508721606e02bb9d570016ae/7 https://trello.com/card/page-model-server-side-rendering-res...
- sawyer 14y ago
  The meteor-router package does enable server side routing, yes. Take a look at the bottom of the README on github.

bejar37 14y ago

Recently decided to use Backbone as a JSMVC Framework on my team. Although I looked at Ember and Angular, which obviously both have many more features than backbone out of the box, We chose to use Backbone because it seems to have such a large and vibrant community behind it - seems like angular and ember are both lacking in this respect. However, as our Backbone application grew in complexity, we noticed that Backbone is so bare in terms of functionalities that we had to build our own half-baked framework on top of it to make up for the gaps. I think the Backbone project needs to make Backbone's intentional feature sparseness clear. I've come to realize that backbone is more of a library which provides a basis to make a client-side framework rather than a something that can be used standalone by app developers. If I could go back and change our original choice, I definitely would have gone with one of the Backbone-derived frameworks (chaplin, marionette) or just gone with something more fully-featured like angular. While backbone is beautiful and elegant for small projects, it just doesn't provide much convenience as a stand-alone library for larger applications.

drewda 14y ago
I've had a very similar experience and am also figuring that on my next "greenfield" project I'll try Marionette.
blissofbeing 14y ago
I have found the Angularjs community to be thriving and most helpful. Check out their google group (1), g+ page (2), g+ community (3), irc room (4) and youtube channel (5) for an excellent place to get help. I usually get help as soon as I need it, amazing. Also I have been impressed with the active community projects AngularStrap (6) and AngularUI (7) 1) https://groups.google.com/forum/?fromgroups#!forum/angular https://groups.google.com/forum/?fromgroups#!forum/angular 2) https://plus.google.com/110323587230527980117/ https://plus.google.com/110323587230527980117/ 3) https://plus.google.com/communities/115368820700870330756 https://plus.google.com/communities/115368820700870330756 4) http://webchat.freenode.net/?channels=angularjs&uio=d4 http://webchat.freenode.net/?channels=angularjs&uio=d4 5) http://www.youtube.com/user/angularjs http://www.youtube.com/user/angularjs 6) http://mgcrea.github.com/angular-strap/ http://mgcrea.github.com/angular-strap/ 7) http://angular-ui.github.com/ http://angular-ui.github.com/

idan 14y ago

Same post, easier on the eyes (particularly on mobile): http://gist.io/4454814 http://gist.io/4454814

dotborg 14y ago

all of them will become obsolete once ecmascript.next kicks in

lefnire 14y ago
Do tell
- dotborg 14y ago
  I'm just reading HN and in discussions between one of news about ES.next, the conclusion was that it will happen... complete rewrite of everything and it's not like it will happen immediately, we need some time to discover best practices with new language features

jtchang 14y ago

Try knockout. I wrote a quick intro to it a few days ago: http://returnbooleantrue.blogspot.com/2012/12/architecting-knockoutjs-applications.html http://returnbooleantrue.blogspot.com/2012/12/architecting-k... I personally don't like backbone that much. I don't know why so many people love the damn thing. It is hard to understand and not even that great.

johnnymonster 14y ago
I personally use knockout all the time. Can't stand backbone or angular after using knockout.
- hnwh 14y ago
  Backbone I understand, but why not angular? It seems quite similar to knockout to me? Whats your backend platform?
  - CapnCrooked 14y ago
    I just finished evaluating frameworks for a project and chose Knockout over angular for a couple of reasons: Extensibility & hooks: Extending built in behavior in Knockout was much easier than in Angular. Without getting into too much detail, one of the things I tried to do was create a list of items on the page with a simple animation for item removal. In Knockout, it was trivial. In angular it would have required a copy-pasta style rewrite of the repeat directive. Some weird missing features: Angular has no conditional add/remove element directive (that I could find). This just seems like a weird oversight. There's a show/hide element directive, but trying to substitute that for add/remove will break CSS first/last/nth child selectors. Angular has a lot of potential, but it felt to me like it needs a few more iterations before I'd want to try to build a rich UI on top of it.
    - ganarajpr 14y ago
      You are right about the first situation. Currently doing animations with Angular is not a trivial task. This is mostly because of its "No DOM manipulation in Controllers clause". If you break that clause, having a repeat with animations is possible ( not trivial - but possible! ). Angular does have a conditional add/remove element. You can use ng-switch for that. If you are using CSS selectors in an angular app I sense a smell. Something is not right.

sergiotapia 14y ago

We use Backbone at my place of work but Angular.js looks sooooo clean, it makes me wish it would have come out sooner so I could have pushed for Angular.js.

jacquesc 14y ago

Agreed on Backbone. It's awesome, but have had transition to Ember as I take on more complex UI frontend work. Trek summed it the best I could hope for: http://trek.github.com/ http://trek.github.com/

freshhawk 14y ago

> It’s like Gentoo users proselytizing Gentoo to the masses, perpetuating it as most common Distro; where all this time, Ubuntu would have saved everyone countless hours. I find this a pretty good metaphor for the backbone/angular/ember distinction, highlights that this complaint is the old "I can't imagine anyone needing more flexibility than I do, so those other people are obviously wasting their time". Nice parallels to PG's famous blub paradox essay as well.

joshontheweb 14y ago

Ok, you like angular. I don't. It has too much magic and forces you to pollute your html with ng attributes. Blanket statements about frameworks like this grow old. So much of the decision comes down to individual preference and the needs of the project. No need to rant about it. I can't really speak on derby vs meteor but I imagine it's the same.

lefnire 14y ago
It's not like that. I'm saying use Angular, Ember, Knockout, whatever - just not Backbone. Unless you know Backbone is what's needed for your project, or you yourself really love Backbone. What I'm discouraging here is its popularity as the de-facto client MV*. I'm under the impression that most people today, when thinking about their next JS project, will use Backbone because it's the most popularly-touted framework where It shouldn't be. It's a great framework, and die-hards & specific projects should indeed use it. But the majority should use one of the other frameworks.
- ricardobeat 14y ago
  Ember, Knockout, Angular, Batman, all have data-binding in their core. Backbone doesn't. If you like writing client code where you have control over rendering and DOM manipulation, Backbone is the best choice short of building your own framework.
  - joshontheweb 14y ago
    Agreed. Also backbone gives you the flexibility to use it on the backend or as the data models behind a canvas app or other kinds of non-html rendering.
- joshontheweb 14y ago
  Probably should have said that in your article if thats what you meant. It came off as a pretty insular point of view with 'rant' in the title.
  - 14y ago

heyitsnick 14y ago

I wanted to use Ember, and I started going down that road, but I just didn't click with it. I didn't progress past the tutorial! I can't remember what exactly I didn't get working, but I just felt very lost and overwhelmed, and that was spending a couple of days reading around online, looking at the code and examples.* I switched to Backbone and got going right away, in half a day of reading the docs and watching a couple of peepcode videos and I was off and didn't look back. Maybe the Ember docs have improved in the last couple of months but at the time it was just a non-starter for me. edit: I believe the issue was around Ember Data/REST. Out of the box it didn't support polling data on a REST interface, which seemed absolutely critical/fundamental to a JS framework. I found a plugin I believe called Ember Data, but documentation was very sparse and I couldn't even get a simple example going. This is going on memory so this could be slightly wrong or different today.

atomical 14y ago
I experienced the same thing with Ember Data/REST.
MattRogish 14y ago
We use Ember + Rails at work and if we didn't start with an Ember expert contractor we'd have been sunk. Ember is definitely a winding maze of stuff and until there's a "Agile Web Development with Ember 1.0" book, it's still very difficult to just jump in from scratch. Still, once we've learned Ember we're very happy with it. Backbone is just too small to start any medium/large app, and Ember has a decent community behind it and lots of integrations with Rails.
- typicalrunt 14y ago
  What function is the Rails component serving? Is it just a REST interface or is it also acting as a separate HTML interface?
  - steveklabnik 14y ago
    We're working on https://github.com/rails-api https://github.com/rails-api to make Rails a great backend for APIs, and specifically Ember. Team is mostly Rails Core members and Ember team members. The hope is to make it awesome for other JS frameworks too, but we mostly build Ember apps ourself, so you start with what you know...

debergalis 14y ago

[meteor dev] Please come help us with this! We have six engineers at Meteor and dozens more contributors in the community working on the platform every day. The plan to 1.0, including REST, is at http://roadmap.meteor.com/ http://roadmap.meteor.com/. Here's the guiding principle behind Meteor. There should be a dramatically faster, more accessible way to write applications. Improving that developer experience means rethinking some things: autopublish and minimongo, so you can jump right into a new app's UX in the first five minutes; one-line authentication (http://meteor.com/authcast http://meteor.com/authcast); synchronous APIs that are more comfortable for a lot of developers; dirt-simple reactive templates; hot code push. Focusing on that kernel of development experience means some other things -- REST, routing, form building -- need more time to fully bake, with hacks like __meteor_bootstrap__ and phantom for apps that need them now. We think that's a good tradeoff pre 1.0.

eranation 14y ago
Meteor is one of the most exciting things I've seen recently. Will gladly help, what things you need most and how one get started? and do you accept people that like TypeScript, Java, Scala and come from the enterprise world? :)
- debergalis 14y ago
  Yeah, absolutely. See http://roadmap.meteor.com/ http://roadmap.meteor.com/ for the high-level view and http://github.com/meteor/meteor/issues http://github.com/meteor/meteor/issues for some starting points on building out code. Another good option is building Atmosphere packages at http://atmosphere.meteor.com/ http://atmosphere.meteor.com/.
d0m 14y ago
I was excited using meteor but was sadly disappointing after a couple days of "banging my head on every simple things I tried". As far as I'm concerned, Meteor is a big "Screw everything that exist, it sucks. We're better and we've got the time and money to re-build all the life from scratch". So, in a way, that's great! An mental orgasm for any nerds out there. But in the real life when shit needs to get done, I'm still using everything else that sucks. Now, before people start saying I don't know what I'm talking about, here are a few examples: - It does NOT use npm (!) -> Basically, you can't use anything without first converting it to Meteor. - It does NOT use Express (Or connect) as its base -> Basically, the standard in the Node community. That means I can't just plug-in the 20 or so awesome plugins built explicitly to be used by any kinds of node application that support connect.js - The current Asynchronous (following node's philosophy) wasn't good enough for them; so the re-created a whole new Mongo version acting synchronously. But most importantly, it's just extremely annoying to hack with it. It's like a big black box.. you're not very sure what it does and you hope it works. But when it's not working, you can't just hack it your way or read the source. It's a little bit like Django or Rails (but in worst) as you can use SQLAlchemy in Django, or you can use different template engines, but then no project from the django community will work with your app. The good news is, the meteor team is working hard. Maybe in a couple years it will be stable enough and iterated fast enough to provide a platform where it will be fun hacking and building web apps. But for now, I sadly prefer to stay in the "Everything else sucks" world and hack my way in the node jungle. (For those interested, I have also tried Derby. As said in the article, it's not yet fully stable and the documentation is really Meh. But I think it's going to be big really soon and I'll be more than happy to give it another fair try. So far, I'm sticking to a basic express (Or locomotive.js which is nice.) I'm also using Angular.js on the front-end. It's something amazing as I feel very productive and it saves a tremendous amount of time.. but at other moment, I just bang my head against the table as I want to do something simple and it's just impossible so I need to use all kind of hacks to do what I'd have done in a couple lines in Vanilla Javascript. Oh well. Hard to be a hipster web developer trying all new technologies :-))

hhuio 14y ago

angular code is a joy to write and read!

cookingrobot 14y ago

Derby looks interesting, but their sample apps (chat and todo) crash and hang safari on my iPhone. Are folks sure its acceptable for mobile focused web apps? Is this a known problem or something unique to me?

lefnire 14y ago
That's that public-face failure bit I pointed out in my post. My own Derby app https://habitrpg.com https://habitrpg.com is smooth-sailing, but people's first impression Derby's home-page examples. For a lot of people, the buck stops there - unbeknownst to them, it's quite stable at HEAD

davidw 14y ago

I have a rant coming about these things too. * I started out with Backbone. It seems ok as far as it goes, but a bit annoying in that there's enough "magic" and stuff going on that I don't quite understand it completely, but without enough magic to really make things simple and easy. * Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-datepicker-example-07092012.html http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being. Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance. I found that very irritating about the Angular tutorial, which is otherwise very nicely put together. Now I'm testing out jquery-pjax, and... so far I'm happier. It behaves more like a web application that I'm used to, sending around HTML, and staying out of my way. And, seeing as how all of these things require that the server do its job in any case, it has more of a "don't repeat yourself" feel to it: click on the button, and the server gives us some new data, without repeating the whole MVC cycle on both the client and server. I got the idea from this post: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...

Angelo7 14y ago
"Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance." Couldn't have said it better myself. I can't count the number of times I had been excited about learning some new framework, only to discover that their documentation is non-existent, poor, or written for rocket scientists.
robomartin 14y ago
> jquery-pjax What happens to SEO?

hellopat 14y ago

I'm working on an app which uses Ember 1.0.0pre-2. Over the past few weeks I've been lazy / busy doing other things so the project was set aside for a bit. I came back to it yesterday, opened the guide page (http://emberjs.com/guides/ http://emberjs.com/guides/) and noticed it had been updated. I was excited and immediately checked the Router section. The guide reflects a brand new router API, which from what I've read makes it much easier to control the state of your application. The problem with Ember right now is the documentation doesn't align with the most recent public version, which will confuse the heck out of newcomers and frustrate people who are still learning Ember. You can however, check out master to get the new router implementation. I'm personally making the jump to the bleeding edge for two reasons: 1. The old router API is very hard to grasp. A lot of unknowns as far as where domain code fits when building your application using the router. 2. I don't want to be stuck struggling to find documentation for an already difficult API to work with. With all that said, Ember is worth taking a look at as far as an 'improved' MV* experience, but you have to be careful as it is in a state of flux.

rxcfc 14y ago
Sorry about this, we're going to be cutting a new release soon so that should resolve this discrepancy.

coenhyde 14y ago

Marionette (a framework built on backbone) offers a nice solution. It still keeps things pretty light but does a lot of the groundwork you would normally have to do with backbone for you. Eg cleaning up event bindings, provides a region/view manager and an application wide event bus.

krebby 14y ago
I'd also recommend looking into Chaplin for stronger routing / app design. It's got a great CollectionView, which is one of the most common use cases for Backbone (also seems to solve a lot of the gripes with plain Backbone
- drivebyacct2 14y ago
  Chaplin is a mess. I need node, npm, build a bunch of stuff from scratch? I've already lost interest (I looked at Chaplin a few months ago and honest to God couldn't even figure out what the hell it did besides download various crap to a /lib/ dir. Aren't there six dozen tools that do that?)

stesch 14y ago

Apache Derby? http://en.wikipedia.org/wiki/Apache_Derby http://en.wikipedia.org/wiki/Apache_Derby Am I missing something here? Maybe next time put some links into your rants. Apache Derby was the only one I found on Wikipedia.

callmevlad 14y ago
http://derbyjs.com/ http://derbyjs.com/
lefnire 14y ago
woops, I added links into the rant.

sgdesign 14y ago

I can only speak for myself, but the reason I use Meteor (http://telesc.pe http://telesc.pe) is because I believe that while it's not perfect right now, it has a bright future ahead of it. The Meteor devs themselves will acknowledge that some features are lacking (I imagine that's why it's not 1.0 yet), but the roadmap looks very promising and I believe Meteor also has the right team to make all this come true.

lefnire 14y ago
Good to have you here, telesc.pe has been an awesome showcase for Meteor.
doctorpangloss 14y ago
The reason I used Meteor (http://redacted.meteor.com http://redacted.meteor.com / https://github.com/doctorpangloss/redacted https://github.com/doctorpangloss/redacted) is because it is fast, exceedingly simple, and gets you a working program in five minutes.

taylorbuley 14y ago

Backbone is a thoughtfully minimalistic approach to prototypical binding. There's no magic. If you need more than that -- automagic binding using HTML data attributes via Angular -- it's OK to use another library.

adolph 14y ago

Discusses Derby: http://derbyjs.com/ http://derbyjs.com/ Not Apache Derby: http://db.apache.org/derby/ http://db.apache.org/derby/

deleted 14y ago

[deleted]

dignifiedquire 14y ago

I switched from backbone to angular about half a year ago. It was the best thing that ever happened to the project I was working on. I've rebuilt the complete interface using angular in 2 days. The original backbone version took me weeks (I learned both frameworks from the ground up while writing the interface) It was just a joy to see how databinding and promises where working hand in hand to make my life as a developer so much easier.

EdwardMSmith 14y ago
As a person that switched from Backbone to Angular, can you explain models in Angular (from a Backbone standpoint)? I've looked over the docs, and as far as I can tell there really isn't a model in Angular - not anything concrete anyway. The docs seem to explain that any JS object is a model as long as you make some reference to it. Or, is an angular Controller (+ some JS data structure) really a model. Its quite confusing to me.
- pebb 14y ago
  Angular model is just any normal js object you want, then via two way binding it gets displayed without you doing any work. Freakin awesome.
- lopatin 14y ago
  I can't explain in terms of Backbone but I'll do my best to clear things up for you anyway. In Angular, you have a magic $scope variable that is available both in your controller function, and in the section of HTML that the controller is bound to. Now I can set any attributes I want to the $scope variable and they will act like models for that controller. For example. Within my controller, I set $scope.username to "alex" and this will update any HTML bound to the value "username", within the scope, to "alex". Similarly, I can set, say, $scope.settings = {user: {username: "alex"}} and this will update any HTML elements (within the scope) bound to settings.user.username to "alex". These are very simple examples, but they show the beauty of having plain JS objects as your "models".

lefnire 14y ago

@KaoruAoiShiho where did you go?? That was a great response, put that back up

marknutter 14y ago

I've been using angular.js for a while now and there are a few reasons why I've really liked it: - dependency injection: because everything is injected, it makes writing isolated unit tests very easy. It also makes it very easy to swap functionality in and out without affecting other parts of the app. - two-way data-binding: most of the pain of being a javascript developer comes from managing and manipulating the DOM. After using angular, there is no way I will ever use a framework that doesn't automate this tedium by providing two-way live data-binding (knockout, meteor, and ember all do this). The best part about having less DOM manipulation code is that it makes writing automated tests easier and makes those test much less brittle. - extending HTML: this is often a main complaint of angular. People say that directives "pollute the DOM" which I find to be a strange complaint, given that HTML is a declarative (sometimes) semantic language to begin with. HTML5 added a ton of new attributes and features yet nobody complained that these new tags were "polluting HTML". Angular simply allows you to extend HTML's functionality even further, and in doing so it makes it very easy to understand what an HTML template is trying to do without having to dig through any JS code. - testing: the angular team made testability a priority, which I was something I always really appreciated about the Rails team. If you're not writing tests for your javascript code, you need to start. Having full test coverage in both end-to-end tests and unit tests has been a major source of stability for me and my team.

wilmoore 14y ago
because everything is injected, it makes writing isolated unit tests very easy I agree with that statement regarding DI; however, have you evaluated whether you NEED a DI container or just DI? Angular forces you into a container even if you don't need it. Is that what you really wanted? If so, fine, just be sure :)

shuzchen 14y ago

Straight from the backbone faq: "Backbone.js aims to provide the common foundation that data-rich web applications with ambitious interfaces require — while very deliberately avoiding painting you into a corner by making any decisions that you're better equipped to make yourself." I think the problem is people come into Backbone.js thinking it's a full fledged MVC framework for in-browser apps, instead you should think of it as a minimalistic set of tools with which to create your own framework (and in fact, a few actual frameworks have been released that are built on top of backbone.js). One way to taxonomize frameworks is on how opinionated it is - Backbone.js is on the far end of the unopinionated side. If that's what you like, then Backbone.js is for you. If you want something more out-of-the-box, you should be considering the other options.

sunwukung 14y ago

similar growing disenchantment with Backbone. Minor gripe re: Angular - if you're working with a server side templating language (i.e. Flask/Jinja) you have to configure it to use alternative tags, which could cause problems if working with any 3rd party libs.

ganarajpr 14y ago
Regarding Angular : You can use the data-ng-* way of adding the ng- attributes. Since data-ng- is HTML5 compliant most major server side templating systems should let it pass through. If you are using custom elements, then you have to figure out a way for your templating system to let it through. In grails for example, you can override it in the taglib's to do that.

sontek 14y ago

It doesn't make sense to compare Backbone to any of these. Backbone is a low level library for getting you started. If you are looking for something easy to use to get you going you just use one of the frameworks built on top of Backbone, I suggest Marionette.

jashkenas 14y ago

"It seems that most people today, when thinking about their next JS project, will use Backbone because it's the most popularl framework when it shouldn't be." (sic) Here's a long list of examples why maybe it should be: http://backbonejs.org/#examples http://backbonejs.org/#examples In comparison, here's the public list of interesting apps built with Angular and Derby: http://builtwith.angularjs.org http://builtwith.angularjs.org https://github.com/codeparty/derby/wiki/Community-Projects https://github.com/codeparty/derby/wiki/Community-Projects What you want to look for in a library goes beyond feature checklists and magic datepickers. Lots of client side developers have been burned in the past by JavaScript frameworks that promise the world and end up getting in the way more than they help. Backbone tries to provide the barest useful essentials -- the main business of building your app is up to you.

dmvaldman 14y ago
You use this argument a lot, but the ranter suggests that the reason many turn to Backbone is because of a self-selecting bias of it being the most popular.
- jashkenas 14y ago
  It's certainly my favorite argument. Folks sometimes forget that pre-Backbone, there was a cornucopia of rich JavaScript framework options: YUI, SproutCore, Dojo, EXTjs, UkiJS, JavaScriptMVC, Cappuccino, and so on. If Backbone has become a bit popular over the last couple years, perhaps it's because it tries to do less than the excellent pre-existing alternatives.
- tjholowaychuk 14y ago
  there is something to be said about flocking to a framework purely based on popularity, Rails is a great example of that too, you sure as hell don't need it for most projects but there are a lot of developers familiar with it, whether it's good or not is another thing
skb_ 14y ago
Backbone tries to provide the barest useful essentials -- the main business of building your app is up to you. I personally prefer minimal frameworks because they don't assume what your finished product will look like. You can grow the application organically rather than trying to fit it into some prototypical mold. Full-fledged frameworks have their uses - they are perfect for getting up and running on known problems. But if you are trying to bake things into an already mature code base or trying a totally different style of architecture, they are not worth the work.

conradfr 14y ago

As a mediocre Javascript dev, AngularJS was the first library that clicked for me and helped me avoid the jQuery soup code I was doing more and more as a result of less code on the server and more on the client. It can be a bit daunting when you are not a JS rockstar : directives and services code architecture, designing views without straight conditional logic, understanding the full power of filters and expressions (I still don't), using jQuery plugins with it etc. I don't even use routes or forms yet but I had no problem integrating it into a "classic" web app. The docs need some work though, maybe with more example on certain part. But you can find great code snippet and videos elsewhere.

danso 14y ago

How did this get so many upvotes? It's a short rant that basically boils down to "Fuck Backbone, use Angular instead" In fact, here is a verbatim quote: "Angular is awesome. That is all." And here's the technical basis of why Angular is better than Backbone: "Now, I'm not suggestion people don't use Backbone. Use it if it's what's needed for your project, or you yourself are a Backbone ninja. What I'm discouraging here is its popularity as the de-facto client MV*" I've played around with Backbone and appreciate its structure. I've never used Angular but have seen many compelling posts on HN arguing why it is a better choice in certain use cases. This rant offers no evidence or elaboration. Is it now cool just to hate the popular thing just because it's popular? Even rants against Facebook and Apple have more substance than the OP.

lefnire 14y ago
It got upvotes (1) because nobody's talking about Meteor v Derby, (2) because people agree. I'm not the only one wondering why Backbone is de-facto - look at all these responses, 80% of them are agreement. That surprised me, I thought this thread would be buried. Many (like you) think this as insular and inane. I left out detailed explanations of Backbone cons and Angular pros just to get the conversation rolling, and indeed the comments took care of that entirely.

danenania 14y ago

I'll chime in with the requisite "90% of the time, don't use an mvc framework in the browser." Don't build up a mountain of state for no reason. Use functions and composable, lightweight, short-lived classes. If I had to choose the 'best' javascript development framework, I'd choose clojurescript, not because it's such a great tool in itself (it is a great tool, though still a bit immature), but because it forces the developer to write javascript in the best possible way: functionally, only holding onto state when it's absolutely necessary. It's good that there are solid mvc frameworks out there for when they are truly needed, but when the average developer picks one up for a routine web app just because it's the hot new thing, he/she's walking into a minefield for no good reason. Javascript is at its best when it's just a dumb, fast bridge between your server and your ui.