15 ms·
Step by step from jQuery to Backbone
- countessa 14y agonice - like the presentation with the file diffs. awesome stuff.
- mitjak 14y agoI noticed that as well. Stealing the idea for my own blog. Makes it very clear what changed, which is instrumental during learning.
- powatom 14y agoI've recently become a bit of a fan of Backbone, and have been tying it with Vertx and SockJS. It makes my fingers tingly.
- gaving 14y agoReally nice way of explaining things.
- tilt 14y agoVery excellent read, thanks!
- kjbekkelund 14y agoAuthor here. The blog appears to be down, check it out on Github instead: https://github.com/kjbekkelund/writings/blob/master/published/understanding-backbone.md https://github.com/kjbekkelund/writings/blob/master/publishe...
- krat0sprakhar 14y agoThank you so much for writing this!
- m_st 14y agoI can't say thank you enough! This is the first Backbone.js tutorial that really made any sense to me.
- tubbo 14y agoAwesome write-up, always good to see examples of Backbone apps written properly alongside jQuery.
- kjbekkelund 14y agoBlog update: our Wordpress didn't want to cooperate today, so we're just redirecting the blog to Github instead ...
- mattdeboard 14y agoI 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 14y agoVery nice article! Thanks!
- beshrkayali 14y agoWell, the website is down... Thanks kjebkkelund
- kjbekkelund 14y agoYou can read it here: https://github.com/kjbekkelund/writings/blob/master/published/understanding-backbone.md https://github.com/kjbekkelund/writings/blob/master/publishe... Our Wordpress bullshit is failing hard.
- beshrkayali 14y agoI found the link, awesome writeup :) Thanks!
- jblz 14y agos/Word[Pp]ress/web host or configuration/
- irishb 14y agoGithub link 404s. :-(
- kjbekkelund 14y agoWhich Github link? This one: https://github.com/kjbekkelund/writings/blob/master/published/understanding-backbone.md https://github.com/kjbekkelund/writings/blob/master/publishe... ?
- Jare 14y agoVery 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?
- kjbekkelund 14y agoThanks! 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 14y agoNow 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 14y agoAfter 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.
- deleted 14y ago[deleted]
- clivestaples 14y agoI 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 14y agoNice tutorial. I have a question: how come you aren't making use of _.bindAll?
- kjbekkelund 14y agoBecause 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.
- epidemian 14y agoAgreed. 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 http://underscorejs.org/docs/underscore.html#section-52
- Robin_Message 14y agoI 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.
- kjbekkelund 14y agoGreat point. I'll take a look at it and maybe make some changes. :)
- tubbo 14y agoHAHAHA nice IE 503 error...
- chinchang 14y agoVery nice and innovative style and osom tutorial as well. If only one could write this for spine as well :D
- 8ig8 14y agoThe author of Spine wrote this book: http://shop.oreilly.com/product/0636920018421.do http://shop.oreilly.com/product/0636920018421.do
- jasonkostempski 14y agoReally 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 14y agoAs 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){` ??
- kjbekkelund 14y agoI'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".
- DougWebb 14y agoVery 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.
- 14y ago
- deleted 14y ago[deleted]
- erik518 14y agoIs 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.
- kjbekkelund 14y agoAh, 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 14y agoIf 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.
- geuis 14y agoThis 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 14y agoFinally 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.
- peterbe 14y agoHere's how the original one should have been written: https://gist.github.com/3167036 https://gist.github.com/3167036 That's 11 lines of straight forward code. Unlike the 43 lines of structure-masturbation in the Backbone case.
- pindi 14y agoI 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-js http://www.pindi.us/blog/step-by-step-from-jquery-to-agility...
- simonista 14y agoThank 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.