Developing Backbone.js Applications – a Creative Commons book | Hacker News Reader

Developing Backbone.js Applications – a Creative Commons book

addyosmani.github.io

54 pointsgetcontext21 comments

While I wouldn't want to use just Backbone anymore, I've found Backbone + Marionette to be quite nice.

About a year ago, I was beginning a new (personal) project, and thought maybe I'd learn Angular... went through a few online tutorials, seemed fairly pleasant to work with. Then I ran across the news regarding Angular 2.0, that it would be more or less a completely new framework. Not sure if that's true or not, but there was enough confusion in the blogosphere around that time that I decided not to sink the time into learning a new framework whose creators had already declared obsolescent.

Backbone is the old reliable, I'll stick with it for the time being.

P.S. I don't consider myself a frontend/js developer -- I only ever do front-end work on my own personal projects, because there's nobody else to do it :)

Not trying to be cynical, but i am kinda glad that backbone is "over" for me. Been with it for about 5 years or more and i have seen big projects fall apart. You don't see the tree behind all the leafs after a year of coding.

With flux/react/angular around development is a lot more fun again. I can't imagine going back.

In my personal experience, backbone has held up better than angular 1 has. Completely different projects and teams so it's hard to draw conclusions.

React + flux implementation du jour looks really promising, though.

What is interesting to me is that the top comment at the time I write this provides the opposite anecdote, that they have seen huge projects using Backbone go really well.

Makes me wonder if there's some sort of objective comparison and analysis of frameworks, or if everything is based on anecdote and personal experiences.

Success mostly depends on the size of the team and their culture. Do they do code reviews? Refactor early and often? Is there a architecture plan that is enforced and trained to new hires?

Frameworks do give you a corset to work within. I do not claim backbone wasn't a success. Just providing that was big.

While I have largely moved away from Backbone, what makes Backbone really great, still, is its adaptability. While I wouldn't endeavor to write a brand new application with it so much anymore, it's extremely hackable and especially great for abstracting away ugly legacy web service APIs. It's definitely saved my sanity on that front on more than one occasion.

If we're just going to be Slashdot style anecdotal and start slinging... I've seen huge projects go really well in Backbone. I can't imagine going back to Angular. Since when is 'fun' the bar for frameworks?

> Since when is 'fun' the bar for frameworks?

Since Ruby on Rails

Interesting issue with discussion regarding ES6: https://github.com/jashkenas/backbone/issues/3560

no offense, but I am the only one who thinks this MVC style isn't an option anymore after things like react?

Er, adding an option doesn't delete all the other options.

MVC is a decades old, tried and tested pattern for building user interfaces. Whatever its merits, I suspect it will survive react.

This is not a critique of MVC, but rather the particular implementation that Backbone provides. With React you still have your models (and controllers).

And adding a new option may make an existing one obsolete. Remember ES3? I do, but I wouldn't want to write new code in it. Once new options were added (ES5, and then ES6), they made the old one obsolete. It desn't mean you can't use the old options, but why would you if the new ones are superior?

I missed the word 'this' in the GP, so this is fair enough.

Even if we're just talking about Backbone, however, it's a little off: I mean, people use react with the non-view parts of Backbone. Often you're going to need some way to talk to APIs (say), and Backbone gives you a cheap and well-known solution for that. I'm no Backbone fanboy, but significant things have been achieved with it, and they are not now suddenly impossible because there's a new view layer on the scene.

Is the ES3 vs. ES5/ES6 comparison valid? The latter were subsequent versions of the former, kind of like Angular 2 vs Angular 1. Whereas Backbone, Ember, React, etc. are all different, each with its own "way" of doing things.

I used ES5/6 because those are (I hope) in the eyes of the HN community clear improvements over ES3. I personally wouldn't use ES5/6 nowadays, and instead use TypeScript or PureScript. Both of which are IMO even bigger improvements. Backwards compatibility does not matter in this comparison, what matters is the relative ordering: Backbone.View < React, ES3 < ES5 < ES6, and IMO: ESx < TypeScript/PureScript.

Well, "things like react" are not more than the V in your MVC ;)

Sure, but it suggests a component hierarchy which blurs the already ambiguous line between view and controller. Which is why there's flux and all of its variants, and things like falcor in the works - the missing model in data-component architecture.

On the ambiguous line between view and controller: a piece of code belongs to the controller when it touch the model, and to the view when it touch the DOM, the corollary being "don't write code that touch both the controller and the model". Put that way it doesn't seems that ambiguous.

The fact that react suggests you organize the views in a component's hierarchy has nothing to do, imho, with people calling the models from those components. It's just bad practices, whatever is the view library being used.

But I get your point nonetheless: flux & all do try to make it clearer that react should only get called from events and update the DOM as a consequence.

For the record, there's also good things being done in that field by the clojurescript community (Om/Reagent for example).

this book is old. It was written before React. I even do not understand why it is so high voted here. But many thanks for Addy writing it and making it open!!!

You're not alone. Use Vieux architecture instead: Vieux.io :)

We've developed (and keep developing) a rather big application in Backbone.js - it holds up and works perfectly.

We are setting a move from it since it lacks in some areas (no POJOs, no nested, manual binding, lots of extra backbone-mini-libs required), but it does hold well at any scale.

I wouldn't direct new comers to backbone.js anymore, new trends with 10x more contributors wins over anything. I wrote about it being the C++ of JS MVC frameworks (http://berzniz.com/post/66372634868/backbonejs-is-the-c-of-j...)

Reply on news.ycombinator.com