3 ms·
I appreciate your feedback and understand that previous posts of mine have framed this as a jQuery vs. Dojo debate; I tried particularly hard not to do so in th
by rmurphey3 15y ago
I appreciate your feedback and understand that previous posts of mine have framed this as a jQuery vs. Dojo debate; I tried particularly hard not to do so in this post, and I think you'd be rather hard-pressed to say that this post was a "jQuery vs. Dojo" diatribe. Yes, it linked to my Berlin slides, but that's simply because a post in response to them is what got this whole post percolating in my head to begin with.
The fact is, though, jQuery and Dojo are the two libraries with which I am quite familiar, and so they are the two libraries I am most able to compare. Having used both, it is easy to see the weaknesses of ... both! I truly believe there is a "jQuery divide" -- there are people who think jQuery is what there is to know of JavaScript, and that it can solve all of their problems; then there are the people who know there is more, either because they have always known or because, like me, they've discovered it through some painful mistakes.
What I am asking for, in this post and in my Berlin talk, is for the people who know there is more to take some responsibility for bringing the others up to speed, to show people what can be done if you leave behind the "get some elements, do something with them" mentality.
None of this is to say that jQuery is not a useful tool, and the right tool in so many situations! I have used it, I have contributed to it, I have taught it, I have recommended it. Its API is seductive and its API is a huge contribution it has made to the JS landscape. The point, though, is that it's just an API -- an API that can be and has been be readily replicated. My experience has been that other libraries' APIs can have their own elegance, once you get used to them. The problem is that the appeal of jQuery's API I think is what can lead people to keep approaching problems in a DOM-centric way long after it makes sense. I do not fault jQuery for this, but I think as a wider JavaScript community we do well to discuss -- and not in an us v. them way! -- other viable approaches that exist.
Finally: Backbone is a viable entry in the field, and I am eager to see more complex examples (to-do list applications fall far short of this) that use it. I haven't used it personally, but I mostly like what I see and have heard good things about it. Unfortunately it had just come out right before my Berlin talk, and while I may have mentioned it in my actual talk, it isn't in the slides. (That said, I do cringe a tad that its examples suggest (http://documentcloud.github.com/backbone/#Model http://documentcloud.github.com/backbone/#Model) that a "Sidebar" is a thing that should be a model.)
- jashkenas 15y agoOops -- that's a very good point about the Model example being a bad one -- I was just trying to use something visible, in order to see the "change" event binding in action. Perhaps we should swap it out for something more model-y. These days, if you're looking for complex Backbone examples, there's a bounty to choose from: * http://getflow.com http://getflow.com * http://m.soundcloud.com http://m.soundcloud.com * http://basecamphq.com/mobile http://basecamphq.com/mobile * http://getcloudapp.com http://getcloudapp.com * http://www.documentcloud.org/public http://www.documentcloud.org/public
- rmurphey3 15y agoThank you for these :) I admit the last time I went hunting was a while ago, it's good to see so many more. For various reasons, the templated widget part of Dojo made it the right choice for my current project, but I strongly suspect a Backbone project will be in my future, either for fun or profit.
- rmurphey3 15y agoOne other question: are there Backbone examples small enough to digest but large enough to be more authentic than a to-do list? This is where I struggle to come up with good teaching examples -- a whole real-world app is simply too much to take in when one is trying to transition to a JS app mindset (and of course the code is usually minified/obfuscated), but examples like to-do lists are so simple that they don't show how a tool addresses actual real-world problems.