Step by step from jQuery to Backbone

http://open.bekk.no/from-jquery-to-backbone/

by kjbekkelund • 14 years ago

353 75 14 years ago

open.bekk.no

countessa• 14 years ago

nice - like the presentation with the file diffs. awesome stuff.

mitjak• 14 years ago

I noticed that as well. Stealing the idea for my own blog. Makes it very clear what changed, which is instrumental during learning.

powatom• 14 years ago

I've recently become a bit of a fan of Backbone, and have been tying it with Vertx and SockJS. It makes my fingers tingly.

swah4• 14 years ago

Might I ask: how are you using those together?

swah4• 14 years ago

I'm asking because Backbone is written for CRUD apps out of the box, and real-time webapps aren't CRUD normally.

gaving• 14 years ago

Really nice way of explaining things.

tilt• 14 years ago

Very excellent read, thanks!

kjbekkelund10• 14 years ago

Author here. The blog appears to be down, check it out on Github instead: https://github.com/kjbekkelund/writings/blob/master/publishe...

krat0sprakhar• 14 years ago

Thank you so much for writing this!

m_st• 14 years ago

I can't say thank you enough! This is the first Backbone.js tutorial that really made any sense to me.

tubbo2• 14 years ago

Awesome write-up, always good to see examples of Backbone apps written properly alongside jQuery.

kjbekkelund10• 14 years ago

Blog update: our Wordpress didn't want to cooperate today, so we're just redirecting the blog to Github instead ...

mattdeboard• 14 years ago

I started a new job this month where one of the big "to do"s is to convert existing javascript app to backbone. This is great, thank you.

gorm• 14 years ago

Very nice article! Thanks!

beshrkayali2• 14 years ago

Well, the website is down... Thanks kjebkkelund

kjbekkelund10• 14 years ago

You can read it here: https://github.com/kjbekkelund/writings/blob/master/publishe...

Our Wordpress bullshit is failing hard.

beshrkayali2• 14 years ago

I found the link, awesome writeup :) Thanks!

jblz• 14 years ago

s/Word[Pp]ress/web host or configuration/

irishb• 14 years ago

Github link 404s. :-(

kjbekkelund10• 14 years ago

Which Github link? This one: https://github.com/kjbekkelund/writings/blob/master/publishe... ?

Jare• 14 years ago

Very nice writeup, probably one of the best practical articles on transitioning code to MVC-style structure.

My only question about the result is the binding of NewStatusView.clearInput to the collection add event. If I understood correctly, it is logically incorrect in that clearing the input field should be a result of having submitted it, not of the fact that something has been added to the collection. A typical example to illustrate this issue would be a collaborative environment where multiple views/users can be adding to the same collection - say, a chat. Every submit would clear everyone else's text fields mid-typing?

kjbekkelund10• 14 years ago

Thanks! And great question. Of course, in real-time environments you need to be really sure which events trigger when. However, on a normal single-page app the add event will only be triggered when you have make a request to the server, and you won't do that mid-typing, only when you're finished typing.

Edit: But, of course, as Robin_Message mentions, it's not always as clear cut as I stated, and there might be some issues with my solution.

xiaoma• 14 years ago

Now this is serendipitous! Earlier today while on my run, I was thinking about finding a resource to take me to the next step after the codeschool backbone.js series.

This is great, though I am having some doubts about whether backbone is the way to go or if angular or ember would be a better choice to invest my time in learning.

dylanz• 14 years ago

After playing with them all, we went with Angular for what it's worth. Less lines of code, IOC is pretty neat, and it just "feels good". We're happy w/ our choice thus far.

clivestaples• 14 years ago

I have recently started moving a project to AngularJS and love it. It really fits my way of thinking about application structure and has significantly reduced the amount of boilerplate code that I'm used to writing. I find it refreshing and have yet to hit any walls...

Toshio• 14 years ago

Nice tutorial.

I have a question: how come you aren't making use of _.bindAll?

kjbekkelund10• 14 years ago

Because I think it's cleaner having it as the third argument on events instead of having a large list of stuff in _.bindAll in initialize (and additionally, I've found it simpler to explain it to others, but I don't know why). I think it's just one of those subjective choices.

epidemian3• 14 years ago

Agreed. Plus, bindAll [1] does quite a lot of magic under the hood that IMO is an overkill compared to passing the context object.

[1] http://underscorejs.org/docs/underscore.html#section-52

Robin_Message• 14 years ago

I like the tutorial style and I wanted to show something like this to someone, so that's really cool.

There's one thing I think you've got wrong in the example: by having functions bound to the same event (addStatus and clearInput), you paint yourself into a corner with Backbone, where you can only bind one function declaratively. However, your solution of clearing the input whenever a status is added is wrong, since (conceptually) the status collection may add statuses whenever it likes for whatever reason, but now doing so will erase the user's input box. Suppose this evolved into a realtime twitter-like thing – you would get hard to understand bug reports of people's input "disappearing".

(Moralising: It's important not to let architecture astronautics distract form the actual logic of the program.) When the NewStatusView successfully adds a status, it should be responsible for clearing its input ready for reuse. The call to clearInput belongs at the end of addStatus. A further argument for this is that it will eventually have to move into a success callback of the collection add, for example when a banned list of words in statuses lives on the server, or you actually broadcast the statuses.

Don't know why I felt compelled to make such a long comment; hope it makes a great reason even better.

kjbekkelund10• 14 years ago

Great point. I'll take a look at it and maybe make some changes. :)

tubbo2• 14 years ago

HAHAHA nice IE 503 error...

chinchang• 14 years ago

Very nice and innovative style and osom tutorial as well. If only one could write this for spine as well :D

8ig8• 14 years ago

The author of Spine wrote this book: http://shop.oreilly.com/product/0636920018421.do

jasonkostempski• 14 years ago

Really nice format. I've been using backbone for over a year and knew exactly how the code was going to end up but my understanding of 'why' is better after reading it, which is a really the most import question to answer. I hope this style catches on, maybe the format could be called a Why-To :)

polshaw• 14 years ago

As others have said, thanks, really great tutorial. I don't know whether i'm going to go all the way to backbone (maybe?), but wherever i stop i'll have better, more maintainable JS.

I also have a quick question; why from the 'Creating a view' section, why do we have:

    var NewStatusView = function(options) {
        var statuses = options.statuses;
        ...
    
    new NewStatusView({ statuses: statuses });

instead of just calling `NewStatusView(statuses)` and having `var NewStatusView = function(statuses){` ??

kjbekkelund10• 14 years ago

I've gradually started passing a hash instead when I expect the number of arguments to increase, which I do for constructors (I hate reading code and not understand the arguments in a function call). But also, it made the change over to Backbone views easier and less "magic".

DougWebb6• 14 years ago

Very well written tutorial, right up to this part:

However, the code has increased from 16 lines to more than 40, so why do I think this is better? Because we are now working on a higher level of abstraction. This code is more maintainable, easier to reuse and extend, and easier to test. What I've seen is that Backbone.js helps improve the structure of my JavaScript applications considerably.

I don't see any justification for those claims. In my experience, more code means less maintainable, because it's more to understand and provides more opportunities for bugs to creep in. I can look at the original 16 lines and understand immediately what's going on, while the 40 line result doesn't even fit onto my screen all at once, and the application logic is broken up and spread out across a bunch of boilerplate-type code.

Regarding reuse and extensibility, I don't see that here either. Sure, you can add more behavior when either element changes, but you could have done that before just as well. For reuse, what's the likely-hood that you're going to need a control like this, which seems to be tightly bound to the application requirements? If you're writing a library or generic control reuse is important, but most of the time most developers are writing custom one-off requirement-specific controls, and reuse just isn't as important as clarity and simplicity. Besides, if you really wanted to reuse the original, you could move it all into a function and pass 'new-status' and 'statuses' as arguments; then any form/textarea/ul triplet can be used as a control.

Finally, testability: yes, I'll grant that your final version is more scriptable which makes it easier to write automated tests. However, you've also got a lot more to test, because now your code is subject to bugs in the 1000 lines of Backbone code you've made yourself dependent upon. What if there is some problem in the communication with your service? That's buried in Backbone and you're insulated from it, unlike in the original where $.ajax gives you nearly direct control over all aspects of the communication. The original, being much simpler, is also easier to visually inspect for bugs. Not much can go wrong in 16 lines of tightly integrated code, but once you switch over to inserting bits of behavior into a larger framework that you don't control and probably don't understand, who knows when your code will get executed (or not) and what edge cases might arise?

BTW, yes I know jQuery is a much larger and more complex dependency, but both the original and final examples depend on it equally. More importantly, your code calls jQuery rather than jQuery calling your code: your code stays in control. With frameworks like Backbone, your code gives up control to the framework.

kjbekkelund10• 14 years ago

Great feedback. What I mentioned are things I've seen from working on fairly large JavaScript apps in enterprise environments. Maybe I should have made it clearer that those where my experiences.

What I failed to note is that in my experience the end result has less code and less complexity when writing my JavaScript like this.

crescentfresh• 14 years ago

IMO what the Backbone.js version has over the jQuery [only] version is readability in a large code base. I assume by "maintainability" this is one thing you mean.

You're only going to cover a small example in a tutorial, so the above benefit is not readily apparent.

epidemian3• 14 years ago

I agree with DougWebb that in this case the 16-line initial version is most surely better/simpler.

The problem is that using a more complex piece of code, one that would really benefit from the structure that Backbone provides, would make the blog post really long and tedious. Maybe you could explain that at beginning of the post: that it's only an illustrative example and that the real benefit of Backbone comes when dealing with more complex applications.

hrabago• 14 years ago

Context matters, because there is a place for both approaches. For pages that you know is unlikely to need updating (such as one-offs or dev-only pages) or for quick UIs or POCs, then a get-to-the-point-quickly approach makes sense. This might also be true for really small teams, or personal projects where the skill level of whoever will encounter the page is really well defined.

There are other cases, though. For instances where this is just a starting point and future enhancements are likely, it makes sense to draw clearer lines between different logic points. In cases where maintenance costs more than development (such as corporate environments), a clear separation can also be beneficial.

geon• 14 years ago

> more code means less maintainable, because it's more to understand and provides more opportunities for bugs to creep in.

In the example, there are more lines, but not really more code. The backbone code is kind of declarative, with very little logic.

I counted to:

* 7 lines of "data"

* 22 lines of boilerplate, including end-braces and empty lines

* 11 lines of logic

Once you have learned the framework, you should be able to filter out the boilerplate, and there really isn't more lines of code/data than in the original jQuery based example.

Anyway, this is the problem with all examples; to make them clear enough to illustrate some point, you also make the end result less of an improvement.

I expect the benefit of a framework like this to be more pronounced in a larger code base, like a full featured web app.

DougWebb6• 14 years ago

I'm not sure exactly how you're counting, but I think the original breaks down to:

   * 3 lines of "data"
   * 8 lines of boilerplate
   * 5 lines of logic

That's less logic to understand, less data to understand, and much less boilerplate to mentally filter out (which does require effort even you're familiar with it.)

A more complex example would probably involve more form controls being submitted to the service and more elements being updated in the response. Neither of these are likely to change the data or boilerplate line count of the original example, and they don't necessarily have to change the logic much either:

data: $('#new-status').serialize() suffices to gather all of the form data in one statement no matter how many controls there are (in a real app your service will probably need most/all of them for validation/context, and a more specific selector can be used to just gather some elements).

When I want to update the display based on my service response, I typically return new markup as one element of my json response. So, my success method is something like $("#status").html(data.markup), once I check data.status to make sure I had a successful response rather than an error. This can be extended to multiple elements by returning a list of id/markup pairs, or going all the way to a jsonp response. Now, this does mean that I'm doing my templating on the server instead of in the browser, but I happen to prefer that because it makes it easier for me to support non-javascript browsers and different templates for different devices. (I try to auto-detect, but also allow the user to override and choose which view they want.)

pacala• 14 years ago

Human brain has a limited ability to juggle a large amount of independent balls at the same time. This is a biological constraint, there is no Moore's law for human brains.

Code complexity is given by the invariants size, not by the actual code size.

If you couple N concerns in 16 lines of code, your invariants may become quite large and you have to keep them all at the same time in your head. Worse, the invariants may dramatically change when you do a "one liner" bug fix. When you decouple your N concerns into N code units, then each unit of code has a clear simple easy to understand meaning/concern. Bonus, there is a lot less risk to have you app subtly do something else as a result of "minor" changes.

DougWebb6• 14 years ago

I disagree; in fact I come to the exact opposite conclusion based on the human brain's limited cognitive ability.

I believe that when you decouple code the way Backbone (and similar frameworks) would have you do, you may simplify the individual bits, but you've obfuscated how they fit together and interact. In fact, you've increased the number of invariants because you've made it possible for the individual bits to be put together in many different ways, not just the one way that the tightly-coupled code allows. You started with N concerns, and now you have N^2 concerns. That's much worse.

It's much riskier too... when your code is decoupled, how can you possibly tell what effect a minor change will have? It's like programming with nothing but global variables. In the tightly-coupled version, you know exactly every single possible code path through your change, and you can ensure that the new behavior will be correct. You just can't do that in the decoupled version, at least not in anywhere close to the same amount of development time/effort.

rimantas2• 14 years ago

  > I can look at the original 16 lines and understand
  > immediately what's going on, while the 40 line result
  > doesn't even fit onto my screen all at once, and the
  > application logic is broken up and spread out across a
  > bunch of boilerplate-type code.

If your application is 16 lines, that's fine. However, when you get 1600 or 16000 lines long jQuery macaroni you will appreciate splitting the code into logical chunks imediattely and those few extra lines will seem a price well worth paying.

DougWebb6• 14 years ago

If the non-Backbone version grows from 16 lines to 16000 lines, then the Backbone version will probably grow from 40 lines to 40000 lines, and will still be worse.

I agree with everyone that it's necessary to structure your code, especially as it grows, I just don't think using a generic-structure-fits-all approach like Backbone is the way to do it. The structure should follow the business functionality, not an arbitrary abstraction that helps the developer talk to the computer. You may end up with 16000 lines of javascript, but if they're spread through 1000 modules that are each clearly related to specific business requirements and/or specific controls in the UI, then as a maintenance developer you'll be able to find the 16 lines you need to worry about for any given task quickly and easily, and then you'll be able to understand those lines once you get to them.

jashkenas• 14 years ago

You're quite correct -- any "trivial" tutorial example will always be better off written without an external dependency. But we're not using libraries to help make writing 10 lines of jQuery easier -- we're using libraries to help write JavaScript applications. The idea is that Backbone will end up helping your write far fewer lines of JS in your real-world app, because instead of having to manually:

    updateTitle: function(id, title) {
      var doc = window.myApp.documents[id];
      $('.document-' + id + ' .title').text(title);
      if (localStorageAdapter.get(".doc-" + id)) {
        localStorageAdapter.set("document", ".doc-" + id, "title", title); 
      }
      var details = $(".document- " + id + " .details");
      if (details.length) {
        details.find(".doc-title").text(title);
      }
      ... and so on, and so forth ...
    }

You have a convenient way to manipulate your data and have your UI react:

    Documents.get(id).set({title: "Don Quixote"});

... at least, that's the hope.

ankimal• 14 years ago

You can also very easily split your code into multiple files. That itself would give you more maintainability. A common breakdown is models, view, controllers and maybe some boilerplate app.js or app.coffee files.

arturadib• 14 years ago

This was the main reason I wrote Agility.js - I too thought Backbone was too verbose (although these days CoffeeScript makes it more succinct, but still not as compact as Agility, as Backbone doesn't have any built-in model-view bindings).

I wanted to keep the same compactness of jQuery's semantics in an MVC framework so that everything from Hello World to complex apps would be more succinct.

For the interested:

http://agilityjs.com

erik518• 14 years ago

Is it just me or do these two apps not behave similarly at all? The jQuery app posts a status to a URL, the Backbone one does not. If the intention was only to show your typed status below once you click a button, why the Ajax call to begin with? Again, maybe I missed the point entirely.

kjbekkelund10• 14 years ago

Ah, minor mistake. Used `add` instead of `create`. It's been fixed in the blog post, and I'll push a fix to the app soon.

dclowd9901• 14 years ago

If the premise of this article is to teach Backbone to people who are accustomed to jQuery, I think it fails miserably. It's long-winded, obtuse, and the example, which is supposed to firmly anchor you, is hazy and enigmatic.

The real trick of Backbone is treating it like a delegator for the UI. It handles creation of new elements, interactions, and creates a 1:1 relationship between the data and what is seen on screen; that's why it's so important in single-page JS websites: It handles the gap between raw JSON data and page visualization.

geuis2• 14 years ago

This is an excellent tutorial. It's also an excellent lesson in why you should stay away from frameworks like Backbone.

(To declare, I have written large apps with Backbone, so I'm not entirely talking from my ass.)

You've gone from a simple, succinct, and easily understood set of code to something that now relies on 2 extra frameworks (backbone and underscore), in addition to still needing jQuery. You've had to incorporate several layers of abstraction (views, cloning events) to simply do what was originally done in a few lines.

I know what the appeal of something like Backbone is. You think that adding in all this abstraction will make it easier to maintain your product. I will even agree that to an extent, it does.

However, a big problem is that the people that already care about organizing their code well, already do so. Backbone is so needlessly open-ended and directionless that a dev who doesn't already know how to write good code will just write worse code.

When I first learned Python, it was enlightening. Here was a language that says, "This is the right way to do it". It got rid of the baggage of other languages and got to business. Backbone is definitely not that for JavaScript development.

Backbone gives you so much rope to hang yourself with, and with so little sense of how things should properly fit together, that it's like wandering around a desert for days on end with a noose on your neck, until you fall into a deep enough hole and die.

I prefer to write my code so that there is an overall architecture, usually with a modular pattern when possible. Anything that needs to happen code-wise for a particular module is all contained within that code block and nothing else. That code is more or less like what was originally posted, where all the things that matter for that module are done in that module.

The other technique I use for modules to talk to each other is sheerly through event signatures. If you have a login module, it can emit events like "loggedin" or "loggedout". Any other module can subscribe to those events and do their own thing, without interfering with others, etc.

This pattern works very well and is a hell of a lot more usable than anything I've ever been able to do with Backbone.

Finally, Coffeescript is not JavaScript. It's another annoying abstraction.

JQuery is not JavaScript, but an incredibly useful library.

Stop piling one layer on top of another thinking you're making your life easier. Get back to basics, learn how to structure your code, and just get some fucking work done.

bherms• 14 years ago

Finally someone who agrees with me. I like Backbone quite a bit and a large part of our application is now using it... However, the added code, layers of abstraction, and lack of any "right" way to do things make maintaining it more of a hassle than anything else. I like that many people are trying to build application frameworks on top of backbone (marionette, etc) but this is just making things worse as now you have 20+ choices on how to write your backbone application, thereby making it harder to maintain across developers (what are the chances the new guy you hired is not only proficient in Backbone, but also backbone using handlebars instead of underscore, and also backbone + chaplin -- or vertebrae, or thorax?)

When our js guru started porting our app the backbone, it was intensely difficult at first for the rest of our devs to make trivial changes to our front end code. What used to be a well defined information flow was now spread across dozens of files.

madoublet• 14 years ago

Don't worry, there will soon be a movement to get back to POJOs (Plain Old JavaScript Objects) and the cycle of engineers over-thinking a problem will be reset.

rimantas2• 14 years ago

  > 2 extra frameworks (backbone and underscore),

Neither backbone nor underscore are frameworks. First is just some skeleton structure, second is just a lib of useful functions. When writing larger applications you are likely to reinvent both. Badly.

> in addition to still needing jQuery

I swapped jQuery to Zepto in the middle of the development of the project without problems. Sure, they are intended to be compatible, but anyway.

  > Backbone is so needlessly open-ended and directionless that a dev who doesn't
  > already know how to write good code will just write worse code.

And a developer who does know how to write a good code can use backbone instead of writing they own version.

  > The other technique I use for modules to talk to each other is sheerly through event
  > signatures. If you have a login module, it can emit events like "loggedin" or
  > "loggedout". Any other module can subscribe to those events and do their own thing,
  > without interfering with others, etc.
  > This pattern works very well and is a hell of a lot more usable than anything I've
  > ever been able to do with Backbone.

Funny, but I am doing the second with Backbone. I have Backbone events in views and global events wherever I need them. And I use Backbone.Events for that too.

  > Coffeescript is not JavaScript. It's another annoying abstraction.

No, it is another way to write JavaScript. So pleasant that after I wile you sigh when you have to write plain Javascript again.

  > Get back to basics, learn how to structure your code,

Good advice.

  > and just get some fucking work done.

And Backbone will help with this a lot. Some people just hate anything popular. Things can be popular for various reasons. Being damn good for the task is one of them.

zanny• 14 years ago

It would be nice to get back to basics, but everything today is built off layers. The entire protocol those web pages are being sent on are an unrelenting tower of abstractions. Mac addresses vs sockets vs tcpip vs http and then all the abstractions that make up ajax and the dom. It's turtles all the way down in web development!

datapimp• 14 years ago

My bet is when you get back to "basics", you will end up writing some ( probably worse ) rendition of views, models, collections, and events.

They are the most basic components of any good UI and if you find yourself deviating from them too much you're probably in the early stages of Dunning Kruger. My advice. God knows I learned the heard way. Develop a little humility and learn from the decades worth of history of people who came before us.

None of these application architecture problems are new. Backbone is simply the re-introduction of time tested historical principles to all you young amnesiacs.

crazygringo2• 14 years ago

> develop a little humility, all you young amnesiacs

Really? There's no need to be insulting or condescending.

The reaction against Backbone is that people like the tutorial author evangelize it as a universally better solution, like the line about the original example code: "It looks like most JavaScript code I wrote a year ago." That's just smug and annoying.

And while a strong MVC pattern is appropriate in some instances, the fact is that it is not appropriate for probably 95% of web apps out there. Instead, it's over-abstraction and over-architecture that gets in the way of productive development.

There, now I'll get off your lawn.

Chris_Newton2• 14 years ago

Thank you for posting this. I had similar feelings as I read the piece earlier.

I think the fundamental problem here is that if we put too much emphasis on trying to keep everything loosely coupled, we tend to lose the cohesion.

It’s all very well trying to separate our code into modules where each module has only one main responsibility. In fact, I’d say it’s probably essential if we’re going to stay sane working on any large project. But there is a flip side, which is that it’s useful to keep code that deals with the same responsibility, or related responsibilities, together.

If we take this to an extreme, as advocates of very short functions tend to do, then we wind up with examples like the tutorial code here. We started with a concise, easily understandable piece of code that we could all scan and understand in a few seconds. We wound up with a monster that is going to take anyone who didn’t write it much longer to get their head around. This is not an improvement.

The difficulty with tutorials is that they necessarily present relatively simple examples. Sometimes it’s hard to tell whether the approach being advocated does go too far, or whether it just looks like it in the trivial case presented but in realistic code it would be reasonable.

swah4• 14 years ago

The pub/sub thing is a great pattern and it doesn't make you write more code. In your example, would all the data the modules need to generate their templates be included with the event "loggedin"?

geuis2• 14 years ago

It depends, but generally yes as I do it. I've found that in most cases the size of data associated with an event is quite small and easily passed around as objects, arrays, or whatever is needed. So if a particular module for a sidebar, a headbar, or mainview all need to update based on an event they subscribe to, each module constructs it's own templates based in the data passed with the event.

crazygringo2• 14 years ago

I would upvote you a thousand times if I could, there's so much of value here.

Why don't we ever see tutorials on how to write modular code? I guess because it usually just works well, so nobody feels the need to evangelize it.

I'm saving your comment to refer to the next time I need to deal with yet someone else who wants to over-abstract their code.

pindi• 14 years ago

I really like this tutorial's format. I made another one in its spirit about Agility.js, another framework that is significantly more succinct: http://www.pindi.us/blog/step-by-step-from-jquery-to-agility...

simonista• 14 years ago

Thank you so much for writing this. I've always felt like I was missing something with Backbone -- I knew that it was mostly infrastructure and assumptions that helped organize and clean up client-side code, but coming from mostly a backend/rails background, I never quite understood the assumptions that were being made and the "magic" that has happening behind the scenes. This step-by-step process is really helpful.

Step by step from jQuery to Backbone

Related Stories