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.
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 disagree that this spread-out, boilerplate-rich format becomes more readable the more of it that you have. I think the larger your codebase is, the more important it becomes for distinct chunks of application logic and behavior to be written clearly and concisely.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).