Rant: Backbone, Angular, Meteor, Derby

I have a rant coming about these things too.<p>* 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.<p>* 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: <a href="http://www.grobmeier.de/angular-js-binding-to-jquery-ui-datepicker-example-07092012.html" rel="nofollow">http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date...</a> - 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.<p>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 <i>very</i> nicely put together.<p>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: <a href="http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui" rel="nofollow">http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...</a>

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

[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 <a href="http://roadmap.meteor.com/" rel="nofollow">http://roadmap.meteor.com/</a>.<p>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 (<a href="http://meteor.com/authcast" rel="nofollow">http://meteor.com/authcast</a>); synchronous APIs that are more comfortable for a lot of developers; dirt-simple reactive templates; hot code push.<p>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.

"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)<p>Here's a long list of examples why <i>maybe</i> it should be:<p><a href="http://backbonejs.org/#examples" rel="nofollow">http://backbonejs.org/#examples</a><p>In comparison, here's the public list of interesting apps built with Angular and Derby:<p><a href="http://builtwith.angularjs.org" rel="nofollow">http://builtwith.angularjs.org</a><p><a href="https://github.com/codeparty/derby/wiki/Community-Projects" rel="nofollow">https://github.com/codeparty/derby/wiki/Community-Projects</a><p>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.<p>Backbone tries to provide the barest useful essentials -- the main business of building your app is up to you.

Try knockout. I wrote a quick intro to it a few days ago:<p><a href="http://returnbooleantrue.blogspot.com/2012/12/architecting-knockoutjs-applications.html" rel="nofollow">http://returnbooleantrue.blogspot.com/2012/12/architecting-k...</a><p>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.

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.*<p>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.<p>Maybe the Ember docs have improved in the last couple of months but at the time it was just a non-starter for me.<p>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.

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.

&#62; 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.<p>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.

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

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: <a href="http://news.ycombinator.com/item?id=3842525" rel="nofollow">http://news.ycombinator.com/item?id=3842525</a>. Also, Meteor now has a REST package built-in <a href="https://github.com/crazytoad/meteor-collectionapi" rel="nofollow">https://github.com/crazytoad/meteor-collectionapi</a> and additional modules that you can install, like <a href="https://github.com/tmeasday/meteor-router" rel="nofollow">https://github.com/tmeasday/meteor-router</a>

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 (<a href="http://emberjs.com/guides/" rel="nofollow">http://emberjs.com/guides/</a>) 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.<p>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.<p>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.<p>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.

I can only speak for myself, but the reason I use Meteor (<a href="http://telesc.pe" rel="nofollow">http://telesc.pe</a>) is because I believe that while it's not perfect right now, it has a bright future ahead of it.<p>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.

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: <a href="http://trek.github.com/" rel="nofollow">http://trek.github.com/</a>

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

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.

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

I've been using angular.js for a while now and there are a few reasons why I've really liked it:<p>- 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.<p>- 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.<p>- 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.<p>- 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.

Same post, easier on the eyes (particularly on mobile): <a href="http://gist.io/4454814" rel="nofollow">http://gist.io/4454814</a>

How did this get so many upvotes? It's a short rant that basically boils down to "Fuck Backbone, use Angular instead"<p>In fact, here is a verbatim quote: "Angular is awesome. That is all."<p>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*"<p>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.

As a <i>mediocre</i> 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.<p>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.<p>I don't even use routes or forms yet but I had no problem integrating it into a "classic" web app.<p>The docs need some work though, maybe with more example on certain part. But you can find great code snippet and videos elsewhere.

Apache Derby? <a href="http://en.wikipedia.org/wiki/Apache_Derby" rel="nofollow">http://en.wikipedia.org/wiki/Apache_Derby</a><p>Am I missing something here? Maybe next time put some links into your rants. Apache Derby was the only one I found on Wikipedia.

Cached at <a href="https://gist.github.com/4454814" rel="nofollow">https://gist.github.com/4454814</a> if down (my Drupal server has been miserable lately and I'm currently migrating to DocPad)

Discusses Derby: <a href="http://derbyjs.com/" rel="nofollow">http://derbyjs.com/</a><p>Not Apache Derby: <a href="http://db.apache.org/derby/" rel="nofollow">http://db.apache.org/derby/</a>

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.

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.

It doesn't make sense to compare Backbone to any of these. Backbone is a low level library for getting you started.<p>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.

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?

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

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.

angular code is a joy to write and read!

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