Step by step from jQuery to Backbone
open.bekk.no
open.bekk.no
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.
(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.
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.
> 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.
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.
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 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.
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.
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.
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.
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"
};
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.
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.
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).
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.
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.
* 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.)
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 :)
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 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 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.
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.
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.
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?
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...)
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 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:
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?
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.
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.
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 });
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.
I have a question: how come you aren't making use of _.bindAll?
[1]: http://underscorejs.org/docs/underscore.html#section-52
Our Wordpress bullshit is failing hard.