This is an excellent tutorial. It's also an excellent lesson in why you should stay away from frameworks like Backbone.
(To declare, I have written large apps with Backbone, so I'm not entirely talking from my ass.)
You've gone from a simple, succinct, and easily understood set of code to something that now relies on 2 extra frameworks (backbone and underscore), in addition to still needing jQuery. You've had to incorporate several layers of abstraction (views, cloning events) to simply do what was originally done in a few lines.
I know what the appeal of something like Backbone is. You think that adding in all this abstraction will make it easier to maintain your product. I will even agree that to an extent, it does.
However, a big problem is that the people that already care about organizing their code well, already do so. Backbone is so needlessly open-ended and directionless that a dev who doesn't already know how to write good code will just write worse code.
When I first learned Python, it was enlightening. Here was a language that says, "This is the right way to do it". It got rid of the baggage of other languages and got to business. Backbone is definitely not that for JavaScript development.
Backbone gives you so much rope to hang yourself with, and with so little sense of how things should properly fit together, that it's like wandering around a desert for days on end with a noose on your neck, until you fall into a deep enough hole and die.
I prefer to write my code so that there is an overall architecture, usually with a modular pattern when possible. Anything that needs to happen code-wise for a particular module is all contained within that code block and nothing else. That code is more or less like what was originally posted, where all the things that matter for that module are done in that module.
The other technique I use for modules to talk to each other is sheerly through event signatures. If you have a login module, it can emit events like "loggedin" or "loggedout". Any other module can subscribe to those events and do their own thing, without interfering with others, etc.
This pattern works very well and is a hell of a lot more usable than anything I've ever been able to do with Backbone.
Finally, Coffeescript is not JavaScript. It's another annoying abstraction.
JQuery is not JavaScript, but an incredibly useful library.
Stop piling one layer on top of another thinking you're making your life easier. Get back to basics, learn how to structure your code, and just get some fucking work done.
Neither backbone nor underscore are frameworks. First is just some skeleton structure, second is just a lib of useful functions. When writing larger applications you are likely to reinvent both. Badly.
> in addition to still needing jQuery
I swapped jQuery to Zepto in the middle of the development of the project without problems. Sure, they are intended to be compatible, but anyway.
> Backbone is so needlessly open-ended and directionless that a dev who doesn't
> already know how to write good code will just write worse code.
And a developer who does know how to write a good code can use backbone instead of writing they own version.
> The other technique I use for modules to talk to each other is sheerly through event
> signatures. If you have a login module, it can emit events like "loggedin" or
> "loggedout". Any other module can subscribe to those events and do their own thing,
> without interfering with others, etc.
> This pattern works very well and is a hell of a lot more usable than anything I've
> ever been able to do with Backbone.
Funny, but I am doing the second with Backbone. I have Backbone events in views and global events wherever I need them. And I use Backbone.Events for that too.
> Coffeescript is not JavaScript. It's another annoying abstraction.
No, it is another way to write JavaScript. So pleasant that after I wile you sigh when you have to write plain Javascript again.
> Get back to basics, learn how to structure your code,
Good advice.
> and just get some fucking work done.
And Backbone will help with this a lot.
Some people just hate anything popular. Things can be popular for various reasons. Being damn good for the task is one of them.
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.
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.
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.
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.
> 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.
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.
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!
(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.