Step by step from jQuery to Backbone(open.bekk.no)
open.bekk.no
Step by step from jQuery to Backbone
http://open.bekk.no/from-jquery-to-backbone/
79 comments
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 2 extra frameworks (backbone and underscore),
> 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.
> 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.
> Coffeescript is not JavaScript. It's another annoying abstraction.
> Get back to basics, learn how to structure your code,
> and just get some fucking work done.
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!
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.
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.
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"?
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.
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.
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.
[deleted]
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.
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...
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.
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.
Really nice way of explaining things.
Very excellent read, thanks!
Author here. The blog appears to be down, check it out on Github instead: https://github.com/kjbekkelund/writings/blob/master/publishe...
I can't say thank you enough! This is the first Backbone.js tutorial that really made any sense to me.
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.
Blog update: our Wordpress didn't want to cooperate today, so we're just redirecting the blog to Github instead ...
Thank you so much for writing this!
Awesome write-up, always good to see examples of Backbone apps written properly alongside jQuery.
Very nice article! Thanks!
Well, the website is down... Thanks kjebkkelund
You can read it here: https://github.com/kjbekkelund/writings/blob/master/publishe...
Our Wordpress bullshit is failing hard.
Our Wordpress bullshit is failing hard.
I found the link, awesome writeup :) Thanks!
s/Word[Pp]ress/web host or configuration/
Github link 404s. :-(
Which Github link? This one: https://github.com/kjbekkelund/writings/blob/master/publishe... ?
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?
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?
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.
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.
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.
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.
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.
[deleted]
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...
Nice tutorial.
I have a question: how come you aren't making use of _.bindAll?
I have a question: how come you aren't making use of _.bindAll?
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.
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
[1]: http://underscorejs.org/docs/underscore.html#section-52
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.
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.
Great point. I'll take a look at it and maybe make some changes. :)
HAHAHA nice IE 503 error...
Very nice and innovative style and osom tutorial as well. If only one could write this for spine as well :D
The author of Spine wrote this book: http://shop.oreilly.com/product/0636920018421.do
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 :)
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:
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 });
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".
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.
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.
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 ...
}
Documents.get(id).set({title: "Don Quixote"});
> 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 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.
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.
That's not necessarily true.
You're not comparing Python to Java, where the verbosity differences are intrinsic to the languages. Programming in the large definitely requires different techniques that can bloat small code examples, but shrink larger code bases. Consider the example of a system that communicates with a server and modifies the layout based on signals and the data the server returns. Backbone can simplify your code by abstracting away some of the details of transferring the data into the rendering code.
You're not comparing Python to Java, where the verbosity differences are intrinsic to the languages. Programming in the large definitely requires different techniques that can bloat small code examples, but shrink larger code bases. Consider the example of a system that communicates with a server and modifies the layout based on signals and the data the server returns. Backbone can simplify your code by abstracting away some of the details of transferring the data into the rendering code.
Just a thought - 'help[] the developer talk to the computer' is pretty much the goal of most abstractions I've seen (not just javascript abstractions, but, y'know, languages and such). :)
The point in Jeremy's post may not seem absolutely consequential in the case of 16 line marginalia; but a common frame of reference that ALSO satisfies 'business requirements' seems pretty desirable to me. That probably has something to do with pretty much all(?) client javascript being either (1) creating/reading some kind of local state Object, (2)updating by way of events you attach to the dom, and (3) the ajax endpoints which send 1 and 2 to the server.
So - admittedly green, college senior - I'm not really sure how to elegantly get 1000 modules loosely coupled, or what looks like, but I'm genuinely curious how many (most?) of those wouldn't fall under the three types of abstractions that Backbone gives you. I am intrigued, and I have a feeling that someone's about to point me to some unifying abstraction which espouses this method and ISN'T just the dom?
The point in Jeremy's post may not seem absolutely consequential in the case of 16 line marginalia; but a common frame of reference that ALSO satisfies 'business requirements' seems pretty desirable to me. That probably has something to do with pretty much all(?) client javascript being either (1) creating/reading some kind of local state Object, (2)updating by way of events you attach to the dom, and (3) the ajax endpoints which send 1 and 2 to the server.
So - admittedly green, college senior - I'm not really sure how to elegantly get 1000 modules loosely coupled, or what looks like, but I'm genuinely curious how many (most?) of those wouldn't fall under the three types of abstractions that Backbone gives you. I am intrigued, and I have a feeling that someone's about to point me to some unifying abstraction which espouses this method and ISN'T just the dom?
'help[] the developer talk to the computer' is pretty much the goal of most abstractions I've seen
Here’s another thought for you: are those abstractions to help the developer talk to the computer, or to communicate better with other developers, perhaps including themselves a few months later?
I'm not really sure how to elegantly get 1000 modules loosely coupled
The trick is not to wind up with 1,000 modules that need to be coupled in the first place.
Even in the largest systems, it’s rare for more than a few modules to need to communicate intimately at any given level of abstraction. Usually you can break a system down into a few top-level subsystems, maybe break those down into a few layers and divide up the major concepts within each layer, or otherwise decompose your overall system into smaller chunks.
This way even if you have a lot of intricate dependencies within a certain part of the system, hopefully you can wrap them up in some sort of higher-level module and present a relatively simple interface to the rest of the system. Even then only certain other parts of the system would depend on that interface directly. This reduces the number of immediate dependencies in your system to some vaguely logarithm-like function of the number of modules in your system and the degree to which you decompose it, rather than something approximating the square of the number of modules if you have an everything-talks-to-everything design.
(Edit: Removed any hint of mathematical notation since this is hardly a rigorous formal argument...)
Here’s another thought for you: are those abstractions to help the developer talk to the computer, or to communicate better with other developers, perhaps including themselves a few months later?
I'm not really sure how to elegantly get 1000 modules loosely coupled
The trick is not to wind up with 1,000 modules that need to be coupled in the first place.
Even in the largest systems, it’s rare for more than a few modules to need to communicate intimately at any given level of abstraction. Usually you can break a system down into a few top-level subsystems, maybe break those down into a few layers and divide up the major concepts within each layer, or otherwise decompose your overall system into smaller chunks.
This way even if you have a lot of intricate dependencies within a certain part of the system, hopefully you can wrap them up in some sort of higher-level module and present a relatively simple interface to the rest of the system. Even then only certain other parts of the system would depend on that interface directly. This reduces the number of immediate dependencies in your system to some vaguely logarithm-like function of the number of modules in your system and the degree to which you decompose it, rather than something approximating the square of the number of modules if you have an everything-talks-to-everything design.
(Edit: Removed any hint of mathematical notation since this is hardly a rigorous formal argument...)
> 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.
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.
I'm not sure exactly how you're counting, but I think the original breaks down to:
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.)
* 3 lines of "data"
* 8 lines of boilerplate
* 5 lines of logic
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.)
To be honest I haven't looked very deeply at the example. However, I recently started working on a backbone project and while it's definitely overkill for basic stuff, if your data visualizations and paths become more complex then it definitely helps you make sense of all the stuff going on.
Also, a custom solution is good and might possibly work better and be smaller/more-efficient/etc. However, the one benefit of frameworks that's often overlooked is the fact that other people might work on the same thing.
If I, as developer X work on a project and develop it in backbone then it's likely that developer Y (a backbone developer) can come in and continue working on it. However, if I were to write a custom solution it could take developer Y a while to get into it.
For example, I can picture how complex the Google Analytics dashboard code must be. If google invited me to work on it, I would have to learn whatever it is that they use to do stuff like that. If it used backbone, I would probably pick it up faster. Just an example.
But as code bases get larger, structure becomes really important. I think that's really where backbone comes in. Your points are of-course valid too, just wanted to share :)
Also, a custom solution is good and might possibly work better and be smaller/more-efficient/etc. However, the one benefit of frameworks that's often overlooked is the fact that other people might work on the same thing.
If I, as developer X work on a project and develop it in backbone then it's likely that developer Y (a backbone developer) can come in and continue working on it. However, if I were to write a custom solution it could take developer Y a while to get into it.
For example, I can picture how complex the Google Analytics dashboard code must be. If google invited me to work on it, I would have to learn whatever it is that they use to do stuff like that. If it used backbone, I would probably pick it up faster. Just an example.
But as code bases get larger, structure becomes really important. I think that's really where backbone comes in. Your points are of-course valid too, just wanted to share :)
You are bringing up a valid point. Doug is saying that I should not use Backbone but instead create my own code structure and organization... but that's the thing. I don't want to reinvent the wheel. I want to use something proven. And yes I have tried structuring a 100% javascript application and I don't like the way it turned out. If someone wants to criticize backbone that is fine, but I want to see an alternative suggested other than 'roll your own.'
The criticism here would probably apply to any other framework in the same space - the alternative way to solve those problems can only be described in guiding principles - otherwise he'd be incurring in the same mistake he is criticizing, by giving you another framework...
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
You're only going to cover a small example in a tutorial, so the above benefit is not readily apparent.
statement: {
context: { opinion: "mine" },
subject: "Backbone.js",
type: new Comparison("jQuery [only] version"),
filter: new FilterContext("large code base"),
result: "readability",
action: raise("assume", { subject: "maintainability" }),
};
on("assume") {
belief: "one thing you mean"
};
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.
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.
Without a more complex example that shows the 'real' benefit, that would just be another unsubstantiated claim.
I know I'm setting a tough bar, but Backbone (and most frameworks) ask for a lot of faith. I've seen far too many "Framework X will make everything easier; all you have to do is totally commit yourself to it until switching to something else is not a feasible option" claims, almost always followed (eventually) by "Yeah, sorry, we really thought it would work out."
In contrast, libraries like jQuery say "Hey, you don't need us, but if you want to do X you can use us to do Y, which is simpler." They don't require a huge commitment up-front; you can start to use them gradually and let them prove their worth. I think that's why jQuery and many library-type products have been so successful compared to the framework-type products.
I know I'm setting a tough bar, but Backbone (and most frameworks) ask for a lot of faith. I've seen far too many "Framework X will make everything easier; all you have to do is totally commit yourself to it until switching to something else is not a feasible option" claims, almost always followed (eventually) by "Yeah, sorry, we really thought it would work out."
In contrast, libraries like jQuery say "Hey, you don't need us, but if you want to do X you can use us to do Y, which is simpler." They don't require a huge commitment up-front; you can start to use them gradually and let them prove their worth. I think that's why jQuery and many library-type products have been so successful compared to the framework-type products.
That's a good point. A good post about a rewrite of a non trivial application would make that claim more substantiated, i agree.
The examples at TodoMVC can serve as a comparison:
Vanilla JS: https://github.com/addyosmani/todomvc/tree/master/vanilla-ex...
jQuery: https://github.com/addyosmani/todomvc/tree/master/architectu...
Backbone: https://github.com/addyosmani/todomvc/tree/master/architectu...
Though i think the Backbone.js example is quite unfavourable, as it's very over-structured. There is no need for so many files; the original code at http://backbonejs.org/docs/todos.html is much better IMO and i think it compares favourable against the jQuery and vanilla JS examples at TodoMVC.
I'm also in the "Libraries before Frameworks" camp, but not as much as i was not so long ago. I used to associate frameworks to bloat, unnecessary complexity and a feeling of being trapped with no hope of escaping. After using light frameworks like Sinatra (Ruby) or Backbone i now don't so negative opinions towards frameworks; they can be utilitarian and serve their purpose without getting too much in the way, but only when they are _focused_, and don't try to implement all possible use cases (Backbone, for instance, lets you use whatever you want for dealing with the DOM).
The examples at TodoMVC can serve as a comparison:
Vanilla JS: https://github.com/addyosmani/todomvc/tree/master/vanilla-ex...
jQuery: https://github.com/addyosmani/todomvc/tree/master/architectu...
Backbone: https://github.com/addyosmani/todomvc/tree/master/architectu...
Though i think the Backbone.js example is quite unfavourable, as it's very over-structured. There is no need for so many files; the original code at http://backbonejs.org/docs/todos.html is much better IMO and i think it compares favourable against the jQuery and vanilla JS examples at TodoMVC.
I'm also in the "Libraries before Frameworks" camp, but not as much as i was not so long ago. I used to associate frameworks to bloat, unnecessary complexity and a feeling of being trapped with no hope of escaping. After using light frameworks like Sinatra (Ruby) or Backbone i now don't so negative opinions towards frameworks; they can be utilitarian and serve their purpose without getting too much in the way, but only when they are _focused_, and don't try to implement all possible use cases (Backbone, for instance, lets you use whatever you want for dealing with the DOM).
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.
[deleted]
(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.