6 ms·

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 clear

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.

crescentfresh 14y ago
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.
- DougWebb 14y ago
  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.
epidemian 14y ago
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.
- DougWebb 14y ago
  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.
  - epidemian 14y ago
    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-examples/vanillajs https://github.com/addyosmani/todomvc/tree/master/vanilla-ex... jQuery: https://github.com/addyosmani/todomvc/tree/master/architecture-examples/jquery https://github.com/addyosmani/todomvc/tree/master/architectu... Backbone: https://github.com/addyosmani/todomvc/tree/master/architecture-examples/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 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).

crescentfresh 14y ago

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.

DougWebb 14y ago
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.

epidemian 14y ago

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.

DougWebb 14y ago
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.
- epidemian 14y ago
  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-examples/vanillajs https://github.com/addyosmani/todomvc/tree/master/vanilla-ex... jQuery: https://github.com/addyosmani/todomvc/tree/master/architecture-examples/jquery https://github.com/addyosmani/todomvc/tree/master/architectu... Backbone: https://github.com/addyosmani/todomvc/tree/master/architecture-examples/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 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).