Migrating a large JavaScript project from DOM spaghetti to Backbone.js

http://www.ofbrooklyn.com/2012/11/13/backbonification-migrating-javascript-to-backbone/

by conesus • 14 years ago

224 113 14 years ago

mcs• 14 years ago

Awesome.

I would suggest using something like https://github.com/afeld/backbone-nested to enable a.get('foo.bar.foo') so you don't have to a.get('foo').bar.foo and suffer undefined errors.

romain_dardour• 14 years ago

Or use coffeescript and write a.get('foo')?.bar?.foo

codewright2• 14 years ago

http://en.wikipedia.org/wiki/Monad_(functional_programming)#...

It shouldn't have to be a library with custom handling of the edge cases like that :|

oinksoft• 14 years ago

It is pretty common to use a function like this when digging into objects in general JS code:

  function get(p, o) {
    var parts = p.split('.');
  
    for (var i = 0, l = parts.length; i < l; i++)
      if (o.hasOwnProperty(parts[i]))
        o = o[parts[i]];
      else return undefined;
  
    return o;
  }
  
  var o = { a: { b: { c: 1 } } };
  
  console.log(get('a.b.c', o));  // 1
  console.log(get('no.way', o)); // undefined

I'd be more likely to reuse something like that because it's already useful in the codebase than bringing on another library.

However, I am speaking out of ignorance, as it appears that the library you cite does a lot more than this simple thing: https://github.com/afeld/backbone-nested/blob/master/backbon...

In any case safe lookup methods are very useful!

bryanh• 14 years ago

This is wonderful! I especially like the detailed coverage of Backbone views. They tend to be the most perplexing part of Backbone (do I nest? how much? how do I track them? etc...) and you outlined your use case nicely.

owenjones• 14 years ago

Agreed. Even as someone who feels pretty comfortable in Backbone this was a good exploration.

modarts3• 14 years ago

As someone about to embark on a large-scale project re factoring to backbone:

Thank you!

typicalrunt• 14 years ago

Seeing the slide about one file that had 8500 lines in it surprised me. Maybe it's a JS thing (I'm not one of those guys) but I've been pushed to make smaller files instead of one large god file. It's hard to traverse a file with that many lines in it, as well as do any meaningful diffs on it.

FuzzyDunlop• 14 years ago

I've encountered a few ~10K sloc files, in PHP. One ex-colleague preferred them, on the basis that "it makes it easier to use Ctrl+F."

pserwylo3• 14 years ago

We have some legacy files with > 20K in PHP. I'm yet to find a PHP IDE which will happily consume these files and let me work them. I just jump into VIM when I need to edit them.

For arguments sake, I'm talking an IDE in the model of Eclipse/IntelliJ/Netbeans, not vim/emacs/etc. I'm aware that people have some pretty awesome configurations for such editors, but I'm for the most part extremely happy with IntelliJ.

Cthulhu_2• 14 years ago

Well, that's one point where Javascript should - and will! - improve, modularization. At the moment there is no default dependency framework - you can't say 'my module X depends on modules Y and Z'. Well, not by default anyway; there's CommonJS's modules, AMD, and in Javascript Harmony another 'standardized' module framework.

I personally use requireJS in a rather large Backbone project, and it works remarkably well.

PommeDeTerre• 14 years ago

People with experience dealing with large-scale software development have been pointing out this flaw with JavaScript for years. It's clear that it just doesn't support modularity properly, and there are severe consequences to this.

Yet there have still been those JavaScript developers who insist that it's a good language to use for anything beyond small (that is, a few lines of code) scripts. They go right ahead creating large amounts of extremely unmaintainable code.

I don't think the solution is to extend JavaScript. Realistically, the only sensible thing to do is to discard JavaScript for anything serious. Sure, maybe the language being used instead will compile down to JavaScript and try to fake properly modularity support, for instance, but this should only be a temporary measure.

All I think it would take is for a major player, like Google or Mozilla, to embed a more capable programming language in their browser. Python, for instance. It's has decent support for modularity, and has been proven with very large systems, yet it still offers the benefits of a scripting language.

The situation wouldn't improve over night, but after a few years we'd likely see Python support in the other major browsers, even if it's just the open source ones, and Opera. These days, that'd likely be enough to gain some good traction. Then we'd at least have a viable option for large-scale, client-side scripts within the browser. It'd be a far better situation that what we've got with JavaScript currently.

bjhoops12• 14 years ago

Yeah, I've dealt with 10000 line JS files before. You know, the master JS file that gets included on every page in the application. Too risky to change anything in it. Ever.

eta_carinae3• 14 years ago

There is no easy way to include .js file that are stored on your server.

Groxx3• 14 years ago

huh? post-process them with something like Jammit. Or just `cat file file file file > final.js` and shove it through a minifier.

chrisrogers• 14 years ago

You might look into preprocessing tools like grunt, which are designed for precisely this

sheraz• 14 years ago

I've been using PHP Minify [1], a simple script to concatenate, minify, and send out my backbonejs project.

Works well.

[1] https://github.com/mrclay/minify

OriginalSyn• 14 years ago

Thanks Samuel, this was the best talk at the summit.

hamdiakoguz• 14 years ago

I clearly see that backbone version is better. But i wonder if is it just me that thinks there must be a better way than the event driven nature of backbone ?

rhysbb3• 14 years ago

there are better frameworks out there for larger projects definitely - but event driven is the best way for larger projects.

bjhoops12• 14 years ago

Great post! Only suggestion I might add as a helpful pattern would be leveraging Backbone.Events to implement a Mediator pattern for communication between Views. This is overkill for between Parent Views and SubViews, but I have found it to be very useful in facilitating communication between unrelated Views.

rhysbb3• 14 years ago

Reading this just makes me scared of Backbone for larger projects. Things like having to keep changes to models silent just because a view isn't ready? Backbone is all good and well for small projects, but I think it's be best to look elsewhere for a larger project. The problem is that backbone has a smaller learning curve so people try to get started with it, and it is better than nothing, but in the long run you'll just run in to more dead ends and spend more time on fixing things and getting around edge cases than if you went for a more fully fledged solution like http://emberjs.com or https://github.com/rhysbrettbowen/PlastronJS

conesus3• 14 years ago

You raise an interesting point. That technique was developed in response to a difficult part of the migration. I had stories coming in for subsequent pages of an rss feed, but I didn't want to re-render the story view until I had a chance to work with the un-rendered story views.

I realize this can be a bit complicated, but at some point you'll be wishing you could just turn off an event from firing because it's interfering with a juggling act. This is what that technique is used for.

But any project that reaches a certain scale will tend towards having some unfortunate ties between models that makes a more-than-ordinary transition hard to accomplish. It can be done, but I'm not quite there, and I suspect many other developers aren't either. This one's a stopgap.

eggsby• 14 years ago

I'd argue that the problems in large projects are primarily architecture problems, that backbone's philosophy of 'bring your own architecture' means how well an app is structured is entirely up to its authors rather than defined by library choice. Something like your plastronjs or emberjs are saying 'Here, do it like this'. Which is good. Sometimes.

I've certainly run into many issues using backbone for moderately sized applications (form workflows, several different types of records, etc) but every time I get myself out of them I gain general javascript knowledge rather than domain specific knowledge about framework xyz. I'd much rather know how to effectively manage memory in javascript than how to use a particular framework.

ganarajpr2• 14 years ago

Following the same argument, you should probably have started with assembler - because, then you would have gained a significant amount of knowledge about the system ( at such a deep level ).

The point of programming is about creating abstractions, so that you dont have to think in terms of the underlying infrastructure. The higher the level of abstraction, the faster you can code, the faster your output will be and faster the business can progress towards a product.

The question is : Is the end goal of your project a product for a business or a means for you to learn the nitty-gritties of javascript?

mattdawson2• 14 years ago

> Backbone is all good and well for small projects, but I think it's be best to look elsewhere for larger projects.

This is such ridiculous FUD, and I'm surprised every time I hear it. Compare the apps built with Backbone section of their site against similar lists of any competing framework. There are some seriously complex apps there. More big ones than any competitor.

Just because a framework is minimal doesn't make it ill suited for large projects. That goes for all frameworks, not just js ones. And yet I see this argument trotted out against minimalist frameworks in every language I work in.

jashkenas• 14 years ago

Amen, amen, 100 times amen. It's a real tragedy that this particular line of FUD has caught on, but hey -- so it goes.

Links, for the curious:

http://backbonejs.org/#examples

http://builtwith.angularjs.org

http://knockoutjs.com/examples/

lapusta2• 14 years ago

Backbone is a great framework and moved the industry forward a lot in terms of code quality. But there are definitely couple things broken, like Zombie/Ghost views - everyone(!) is making their own workaround.

View part is too much DIY. Seriously, _.template is okay for views with no input and simple updates, but if you have heavy IO views become bloated. Check the wiki, there are 7 "yet another binding plugins". Make default one, and make it an option (view binding can be slow and not needed sometimes).

Another DIY are models relations & nesting. These two additions wouldn't be big for the core, but they could really improve the ecosystem. Now you have to take in mind those third-party plugins people are using for these covering basic gaps.

timc3• 14 years ago

So what do you suggest?

riprock• 14 years ago

I haven't used Backbone.js, but from what I've read there are extensions like Backbone.Marionette for better view and memory management.

https://github.com/marionettejs/backbone.marionette

eta_carinae3• 14 years ago

Ember.js?

lapusta2• 14 years ago

Backbone is an opinionated software, so it's hard to say if binding would be ever included.

For developers I suggest to try some of plugins, which are listed on GitHub wiki in the binding section and also take a look at Knockout/Ember/Angular so at least you would know what other frameworks offer.

atomical• 14 years ago

In my opinion binding should be included with backbone. Rendering views over and over again is pointless and if it's a form it will lose focus. There is already one binding plugin that isn't being developed anymore. A winner should be picked and integrated.

I haven't created a monolithic backbone application but model relations and nesting could add significant complexity. Adding binding, model relations, and nesting will make backbone look more like Ember which I think they are trying to stay away from.

salimmadjd• 14 years ago

Great post! I wish you had briefly talked about why you picked backbone over other options like AngularJS.

conesus3• 14 years ago

I'll admit, partially it was because I was sitting next to Jeremy as he was pulling backbone out of the documentcloud workspace and into a soon-to-be-released javascript library. Otherwise, the community has embraced Backbone.js and, for better or for worse, you're swimming in the biggest pond. That means more community driven updates and support, as well as more competition to stand out from in the newest javascript writing convention.

gambler2• 14 years ago

I never understood why people proudly boast about their past mistakes. Is it supposed to make their current achievements sound better? "Oh, we had 8500 lines of spaghetty JS code in one file, but we used AwesomeFrameworkX and it fixed everything!" For me, this doesn't make the framework sound more impressive, but rather undermines credibility of the author. How did it get to 8.5 lines? Did no one notice? Did no one care? Was every line necessary? Does having a file like that is really better than having some stuff handled on the server side? Was Backbone the only way to move forward?

conesus3• 14 years ago

The intention was to allow people to commiserate and understand that this happens to many code bases and there is a path out of the woods.

As far as letting the file deteriorate to that length, NewsBlur was a side project of mine for two years. That's how long it took, and because I only had 45 minutes at a time (my commute) to work on it, large scale refactors were not a priority.

And it took two years before I realized that NewsBlur would be sticking around and I should care for the code base. It was at that point that I began the process of refactoring the bejeezus out of it.

tomkit• 14 years ago

Totally agree. It shows more of the author's initial failings and then trying to generate buzz with hot HN keywords like 'backbone'.

One file with 8500 lines could have easily been avoided with the module pattern either by handrolling it or using various libraries out there like requirejs, commonjs, etc.; backbone is not required.

mattdawson2• 14 years ago

You're only addressing part of the problem. File size is a much easier thin to fix than refactoring DOM bound soup.

justinator• 14 years ago

No one's perfect and we all make mistakes, given the circumstances we find ourselves in - we all make choices with incomplete information.

Admitting that there's a better way to do things is a good first step to become better. To share what you've learned is a sign of being humble.

gambler2• 14 years ago

We all make mistakes, but not all of us use those mistakes to promote something. It's an annoying and overused software evangelism trick. You start by decrying your past ignorance, and continue by saying that you were enlightened and started using X. This dramatizes the improvement and subtly implies that everyone who doesn't yet use X are simply not yet as enlightened as you. There is nothing genuinely humble about doing this.

aidos• 14 years ago

The move towards rich frontend applications is a fact of life at the moment. There are lots of ad-hoc apps out there that have 1000s of lines of js in a single file. These guys put the work in to fix that - then they kindly spent their time writing it up so we could profit from what they learnt.

Granted 8.5k lines is a lot - but I'll bet there are more shocking projects out there than that. (I've seen much worse than that on the server side)

zem• 14 years ago

they weren't boasting, they were sharing their solution to a common problem, in the hope that it will help other people who have the same problem. i'm somewhat surprised that anyone doesn't "get" the motivation behind doing this.

kylecordes• 14 years ago

From the blog post and slides, it looks like this was a big improvement.

But...

You may find that moving to a higher level, more declarative solution (like Knockout) yields a considerable additional improvement.

skeletonjelly• 14 years ago

I thought Knockout and Backbone were two implementations fixing the same problem. Can you expand?

rimantas3• 14 years ago

Unless something changed drastically changed in the last year my impression was this: Backbone helps you to fix problem, Knockout just hides it. I think some people just have a problem with backbone being too flexible, because it matches the name perfectly: it is just backbone helping you to solve problems you will have to solve anyway.

Knockout feels more like exoskeleton — it may be very comfortable when you fit in, but as soon as you don't you are in a lot of pain.

nateabele4• 14 years ago

Wow. After using AngularJS for a few months, it's amazing what a nightmare it looks like to work with Backbone.

randall2• 14 years ago

Right? Jquery DOM mess < Backbone < Angular.

porker2• 14 years ago

Please write your DOM -> Angular or Backbone -> Angualar follow up for this article - would love to see the difference.

Like TodoMVC on steroids :)

ww5202• 14 years ago

How is AngularJS compared to Knockout?

nateabele4• 14 years ago

Haven't worked with Knockout extensively, but I know their change listeners have cascade issues, and I'll grant this is a preference thing, but compared to Angular, their binding syntax is ass.

Also, Angular is the only framework where the DOM itself is your template. This cannot be explained, only experienced. :-)

hasenj9• 14 years ago

Angular is more of a framework than a library. You have to do everything the Angular way or things will become very difficult.

In trying to learn it, I found it quite complex (beyond the basic hello world examples).

account_taken• 14 years ago

I'm going to have to try AngularJS. One of the things that put me off is how much it looks like ASP or JSP with the angular tags. Obviously it must be good as many people rave about it.

We're using Backbone for a large project and yes we have to track and dispose of everything manually but it's so small that we can make it do what we want. I will say this, Backbone has made our team better JavaScript developers because it didn't throw the kitchen sink at us. I just hope AngularJS is not Struts on the client side.

tjholowaychuk• 14 years ago

Nothing wrong with backbone, but I do find it hilarious how it took a lib creating faux classes to get people to stop writing hideous code, you can write clean code with or without Backbone, and it'll look nearly identical. Cleanliness is not in a framework, it's in your head.

glassx• 14 years ago

I notice the same thing with Rails vs Sinatra. People complain that Sinatra is problematic because it doesn't enforce a directory structure, but you can still make clean, organized code with it.

hasenj9• 14 years ago

Backbone.js is not going to solve your DOM spaghetti problems.

You will still bind to events, you will still manipulate the DOM, you will still do all the manual work.

I really recommend looking at Knockout.js instead.

It really gets rid of all the DOM manipulation code that tends to become so complex and spaghetti like.

How? It provides a declarative language for two-way binding between the UI and the data.

Check out this example: http://jsfiddle.net/FEVbz/

In the HMTL pane, edit the input boxes and watch as the other DOM elements update automagically.

Notice how simple and clean the Javascript code is. All it's doing is initialization and setup. Nothing else. No event binding. No dom manipulation. No spaghetti. No nothing.

Shameless plug:

Here's an article I wrote about why I think Knockout.js is so much better than Backbone.js

http://dev.hasenj.org/post/35572197519

nerd_in_rage• 14 years ago

I've taken a look at both Backbone and Knockout over the past week or so, and I definitely prefer the Knockout approach.

Backbone... I just don't get it. It seems like there's too much complexity. I'm mainly a back-end developer, so perhaps it's just me.

thibaut_barrere2• 14 years ago

Like you, I'm more a back-end developer and attempted to pick Backbone initially for my SaaS, but I wasn't very successful with it.

Later I discovered Knockout and in 2 hours, I was up and running, and it never got in the way so far.

I can only encourage people to at least try the tutorials, it will be time well spent:

http://learn.knockoutjs.com/

rimantas3• 14 years ago

  > It seems like there's too much complexity

Backbone helps you to do the things you understand. Knockout let's you do things you don't necessarily understand. Sometimes black-box approach is OK. Sometimes not.

sergiotapia• 14 years ago

How would you say Knockout compares to AngularJS? I've looked at both and Angular seems really really clean as well.

thibaut_barrere2• 14 years ago

I'm looking at AngularJS to handle some more advanced cases; my understanding is that AngularJS provides roughly what Knockout.js provides, then more features around (but please note I didn't dive very far yet in AngularJS!).

Knockout.js is great to get started at adding interactive UI on a JSON back-end, and I think AngularJS is the natural progression.

hasenj9• 14 years ago

As I said here: http://news.ycombinator.com/item?id=4792638

Angular is more of a framework than a library. You have to do everything the Angular way or things will become very difficult. In trying to learn it, I found it quite complex (beyond the basic hello world examples).

rimantas3• 14 years ago

For anyone tempted: keep in mind, how trivial this example is. When time comes to nontrivial things knockout will bite and bite you hard.

riffraff• 14 years ago

while this is an interesting reply, it could be way more interesting if it contained a "because ...." subsentence, could you expand on this?

hasenj9• 14 years ago

As opposed to Backbone, which doesn't bite you hard?

Dude Backbone only works for trivial examples, and even then, and I mean, even with trivial examples, Backbone is almost useless.

I haven't yet been bitten by Knockout in any bad way.

thisone• 14 years ago

what do you mean by non-trivial?

I've abused knockout to some rather interesting ends, but I've never attempted to use it for as an in browser MVC setup.

I think of Knockout and Backbone as fulfilling two different purposes.

Offler• 14 years ago

We build online trading applications with KO (we use it only for the view, we have our own Presentation Model were we have observers which pretend to be KO observables) and we have found it quite helpful.

The components built are FX tiles, trade and order tickets.

vidarh5• 14 years ago

Apples and oranges. They address different areas, and so you'll combine them with different other code to fill in the gaps.

Then can even be used together (see, e.g., knockback.js which combines Knockout data binding with Backbone) to complement each other.

All you're really complaining about seems to be lack of data binding in Backbone. So you pick your preferred data binding mechanism and plug it in.

hasenj9• 14 years ago

In theory they are different, but in reality people use backbone because they think it will help them reduce the bloat and mess in their code, when in fact backbone will not help with that.

vidarh5• 14 years ago

> Here's an article I wrote about why I think Knockout.js is so much better than Backbone.js

... and it was written in a horribly obnoxious manner. The disclaimer clearly shows you realize they have different purposes. So why the antagonistic tone? If your issue is really as stated that people use Backbone for the wrong things and to highlight the benefits of data binding for views, then address that, instead of writing some inane comparison blasting Backbone for not providing features you the at the end admit isn't its focus.

It's a bit as if I were to review your blog post as musical theatre and then at the end admit I knew all along it was actually a technical blog post but that I'd decided to slate it for lack of singing anyway.

hasenj9• 14 years ago

> The disclaimer clearly shows you realize they have different purposes. So why the antagonistic tone?

As stated in the disclaimer itself; because people use backbone as if it will help them manage the complexities of creating rich client side UI, when I actually think it's a terrible choice for that.

> If your issue is really as stated that people use Backbone for the wrong things and to highlight the benefits of data binding for views, then address that, instead of writing some inane comparison blasting Backbone for not providing features you the at the end admit isn't its focus.

I want to grab people's attention that they're doing it wrong. It's like when you slap someone in the face to wake them up.

> It's a bit as if I were to review your blog post as musical theatre and then at the end admit I knew all along it was actually a technical blog post but that I'd decided to slate it for lack of singing anyway.

Well, you're evaluating my article as if it was meant to be an objective non-biased review of "pros and cons". It's not. It's an opinionated piece of text that comes from personal frustrations.

Though for the record, I actually respect and admire the author of backbone, after all, he's also the author of coffee-script, which is just awesome.

Pewpewarrows• 14 years ago

I have yet to see a single viable example of a Knockout app that's been progressively enhanced. Until then, I'm not even going to consider touching it.

camus• 14 years ago

Knockout is horrible because you end up putting the "messy jquery code" in the html ! While there is no auto-binding in backbone, it is not really an issue in large apps. Furthermore , knockout doesnt have a persistence layer.

hasenj9• 14 years ago

You don't put "code" in the html.

Knockout's declarative language is not messy; just verbose.

Kiro• 14 years ago

I use jQuery a lot but Backbone is like Greek to me and so is every tutorial I've seen. I just don't get it and I fail to see the benefits.

Can someone point me toward a good and simple explanation/tutorial?

CWIZO• 14 years ago

I feel exactly the same. I tried to make something simple with bacbone the other day but I just couldn't wrap my had around it. Maybe I'm just stupid, but I too would like to know if there is some article that would explain things more clearly.

modarts3• 14 years ago

Try the Peepcode videos:

https://peepcode.com/products/backbone-js

uptown• 14 years ago

I'm going through the same thing. I just got a small application up and running using Backbone.js yesterday, but it still feels like a more-complex application could get messy.

I did have one question regarding redundancy - if I take advantage of something like validation with Backbone, I still need to do the same validation on the server-side for any data that I POST or PUT back to the server since I can't trust what comes from the client. Is the only gain from doing the client-side validation in Backbone the faster feedback to the user without requiring a round-trip to the server?

I'm currently trying to decide between Backbone.js, Angular.js, Ember.js or sticking closer to what I know with a jquery pjax solution.

mcgwiz2• 14 years ago

The primary gain is faster feedback, but this can also reduce server load. In general, you should never trust user input, so you should validate on the server. (In particular, not only is it possible for users to manipulate/disable your client code, including validation logic, but it's trivial to hand-craft requests to your server.)

mcgwiz2• 14 years ago

Simplest explanation:

Backbone is an object-oriented library that can increase maintainability for so-called single-page applications. E.g. it's often used in an architecture which pairs a dynamic web service with static HTML templates, CSS, and JS (no dynamic server-side HTML generation). In this way it is similar to ExtJS/YUI, but generalizes those widget-centric frameworks.

It's not for tightly-scoped JS enhancements.

In terms of patterns, it adheres mainly to the Model-View-Presenter pattern (embodied in the Model class, the HTML template, and the View class respectively). Switching between logical pages in the single-page app is supported by the Router class (which implement the front controller pattern). Data persistence/retrieval is oriented toward RESTful web services (this is customizable) and therefore pairs will with ActiveRecord-based server frameworks like Rails. The separation of concerns it encourages increases testability, and also allows it to pair well with asynchronous module loaders (e.g. RequireJS).

Migrating a large JavaScript project from DOM spaghetti to Backbone.js

Related Stories