Not to jQuery!

Last week I asked:

Would jQuery make the tutorials better? Or harder to understand? Should I just stick with pure JavaScript? Or is there a library that’s so much better than jQuery that I’d be crazy not to use it? Have I just inadvertently asked a question that’s going to set off a religious war between devotees of different JS frameworks? Any answers very welcome below.

I had to update it a bit later to clarify:

I’m only considering rewriting the DOM access and stuff like the onload callbacks using jQuery, and then only to make it easier and more readable. I’d explain the jQuery in as much detail as I currently explain JavaScript. The WebGL and canvas access would remain pure JavaScript.

There were tons of great comments, both pro and con. The one thing that stood out was that people who were using jQuery themselves thought it would clarify things and make the DOM access code much neater and clearer — but some of the people who weren’t using jQuery thought it would make it harder to read. In addition, it sounded like people who knew neither jQuery nor much JavaScript when they first came to the tutorials saw adding jQuery as adding something additional to learn rather than smoothing the path through JavaScript. Most concerning was that some people were saying that they tend to skip “how-to” guides that require jQuery.

What this boils down to is that while all people who like jQuery will live happily enough with “pure” JavaScript, some people who don’t like jQuery or who don’t know it would be put off by it. So the best way to make the tutorials useful to the maximum number of people is to not use it — so that’s what I’ll do. Perhaps I can put some time into making the JavaScript use the latest and best features of the core language, as Nicolas suggested.

(I do, however, reserve the right to make occasional catty comments like “of course, in jQuery this would be easy but I’m not using third-party frameworks here” ;-)
You can leave a response, or trackback from your own site.

9 Responses to “Not to jQuery!”

  1. EMpiRE says:

    Hey, after all its your blog…you do it like you are the most confortable with it… is already enough hard to work on a blog, so thanks to you for your effort even if your using or not jQuery ;) I think we are all thanksful to you already!

  2. teadict says:

    I applaude your intention to poll the argument :)
    I said no to jQuery but I would not have stopped following the blog for anything, you are doing an awesome job.

    Cheers from Argentina and let’s keep on javascripting.

  3. I think that’s a poor decision and doesn’t really address the real issue. Javascript is a real, standalone language that is being utilized in a ton of different concepts. It’s also a language that spent 80% of its time growing up on a browser envionment.

    Use jQuery what it’s awesome for, which is abstracting the DOM. The DOM is a browser API exposed to Javascript which is extremely inconsistent. Element, asyncRequest (ajax), etc. That’s all DOM. The problem is that people who don’t know Javascript as a language don’t understand where the line between Javascript ends and jQuery (as a DOM/browser abstraction layer) begins. Nearly all good example jQuery code (written by ninjas) seamlessly blends the two. However, with a specific goal is separating them, it’s easy to split them. For example, nearly all example jQuery code shows any situation with a callback as an inline anonymous function. People raised on jQuery take it granted but barely know what it means, how amazing it is, how rare it is in most currently used languages (PHP just barely added support for lambdas in 5.3 and it’s nowhere near what JS has supported for a decade and a half),

    Underscore.js is an awesome example of how much JS territory exists outside of jQuery. Without an environment with the DOM (AKA any situation outside a browser) Underscore.js is vastly more useful than jQuery aside from a handful of things jQuery supplies. At the same time, all the of the stuff that jQuery provides with regards to event handling, data utilities, and especially in 1.5 with promises and a better concept of handling deep asynchronous functionality, jQuery still brings some heft to the game.

    The point is, you NEED to use jQuery to teach the legions of people raised on it what is JQUERY, what is JAVASCRIPT, and for what reasons Javascript is so awesome that it allows libraries to literally redefine the game, while still being a part of the original language.

  4. steve says:

    Brandon, your argument would work even better if you used mootools as the library instead of jQuery. Mootools does the same DOM abstraction and also has additional consistency for Javascript. That’s the problem though. As a jQuery user, would you read tutorials based on mootools? Picking a library is implicitly taking sides in a stylistic debate that has nothing to do with WebGL.

    I don’t read jQuery tutorials because I don’t know how much of the logic is going to be wrapped around some jQuery function that would be difficult for me to replicate into plain JS or mootools. To do that translation, I need to learn whatever weird bit of symbol soup jQuery is using… then convert it to work without jQuery. No, I’m not going to use jQuery. I’m already loading mootools.

    This is the argument that is being side-stepped by not using _any_ library. Everyone can read plain JS, and modern plain Javascript is a lot better than it used to be. The problems you’re pointing out are more applicable to IE6 and pre-WebGL browsers.

  5. Omiod says:

    I agree with your choice.
    I usually use jQuery when coding for websites, but in case of canvas/webgl, it is not really needed, so I try to avoid it and stay “pure” as much as I can.

  6. oos says:

    Good choice! Thanks!

  7. Nicolas says:

    Great! I’m very happy my comment was useful to you. I learned a lot from your lessons, and I’m looking forward to the next ones! (picking, shadows), so thanks once again!

  8. Mike says:

    Could You eventually provide an instructive example, where the WebGL model is controlled via Node.js (Socket.IO) on the server. Let’s say a bowl changing it’s spin dependant on events via Node.js. BR

  9. Basic says:

    Of course, you could always do both ;)

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter