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