A trackback on one of my previous posts (yeah, trackbacks aren’t just for spam) alerted me to an interesting point brought up by a blogger named Matt Pass. In his post entitled Walnut, Meet jQuery Sledgehammer he politely explains why he feels it’s overkill to use jQuery in a simple tutorial post.
His main point is summarized in this quote:
I almost responded to James’ commment at the time, and I had written a comment for Matt’s post, but felt this was something I wanted to open up to my larger audience.
Is Library-less Code a Reality Anymore?
for loop might be more performant than jQuery’s
But in my opinion, simple code examples that use jQuery are not overkill at all, but are simply catering to the needs of modern developers — the majority of whom are using jQuery in the very projects where they might be using the simple tutorial code Matt is talking about.
Finally, the other reason I think it’s okay to use jQuery in a post like that is that, well, the point of those posts is often more about principles or concepts, not code architecture, cross-browser issues, or other peripheral matters that would, in my view, distract from the point of the post.
I will continue to use jQuery even in simple posts that are more focused on CSS3. But maybe there’s something I’m overlooking. Would love to hear anyone’s feedback on this.
I think you should keep posting with jQuery. Despite being an easy-to-understand library, even for those who felt in love for MooTools or Dojo, I agree with you: posts are about concepts, not details of implementation. For my feelings, using jQuery is like saying “I don’t care about how does my browser expects me to select an element. I just want to write once and have the library choose the correct form from the wide variety we have available”.
I disagree – slightly – with the fact that every big project uses a library. You assume new projects or modern ones. A lot of people have to deal with old systems that could benefit from a new feature but can’t if all you show is a jQuery solution for it.
The main issue is that we reach for the hammer jQuery for convenience reasons. It is simpler to show short code examples. It is however also hiding a lot of complexity that needs explanation from the reader. A lot is happening in browsers these days that gives us native support for complex matters. These things are hardly ever covered because we use jQuery in our demos. Things like querySelector and classList cover a lot of the basic fixes jQuery gave us in the past and should get some love from tutorial authors.
The reason why a lot of big projects use jQuery is not that it is simpler to code (actually writing maintainable jQuery for distributed teams with various skills is very hard indeed) but that it gives us a level playing field across browsers and zombies like IE6.
So as an educator, I’d always go for the lowest common denominator in explanations. Native code in browsers trumps over having to use a library that has a different syntax and rules than the language it is built on.
It should not stop you offering a jQuery version in the form of a plugin though.
If your goal is to teach then cutting dependencies is a damn good idea. There is nothing more annoying than a tutorial that looks damn easy and small and then asks you to use all kind of other things before you can see the result.
Having said that, you have to look at the real intend of such demos and their true audience. Call me a pessimist, but I think they’re not intended to be *that* educational. It’s more of a snack-size “here’s how you do this in 10 minutes” copy-and-paste style of tutorial. They’re easy scores and they will be consumed by people who want to get something done quickly, regardless of whether they understand it. You’ll see it in articles that explain a demo yet lack a live demo, the comments are full with “where’s the demo” and “example?”.
Great points, Christian. For the most part, I concur, especially the part about writing maintainable jQuery for distributed teams.
And my statement about libraries being “mandatory” was probably more bold of an opinion than was intended. I certainly don’t think libraries are mandatory — that would be ridiculous. But I do feel strongly that libraries are just so common today that it almost feels like they’re mandatory.
Please keep the jQuery code coming. As you say, we’re already loading it on our pages, and jQuery saves all the discussion about browser differences which is what has made it such a widespread solution in the first place. Contrary to check_ca, I don’t have the luxury of just ignoring IE8 and less, but jQuery does that job for me.
Most important part is HOW! Everybody say something but no one show us easy way.
Well guys, this is very funny for me.
Everyday we (real coders) are challenging with a lot of problems. Something is not working, something is working, but have a little bug and so on. Today I was fighting with Knockout.js. After all at 8 PM (time in Slovakia) I’ve opened SM and found this article. Do you really think this is very very important topic?
There are beginners, I know. I believe, that they are reading your article, because it contains jquery solution. For quite experienced it doesn’t matter if you are using plain JS or jquery/moo/… Because solutions are about logic. But don’t you think that everybody who uses jquery, mooTools understant plain JS?
In my opinion, if you come up with some new great idea, it will be rewritten very fast by others :)
Interesting to see the divide in opinions here and glad to see my article was taken in the right way (definitely not a dig but a difference of opinion).
Over the years I’ve created around 300 websites, large, small and of all different types (informational, eShops, apps etc) and probably only around 5 use a library such as jQuery. This is because I always weigh up each project before deciding whats needed and almost always find a library is just unnecessary (the handful of cases where I’ve used them are on apps & eShops).
Like most people, I like websites to load as quickly as possible and will avoid anything thats unneccessary (same reason my CSS is slim, images optimised etc). As we’re heading into an era of where mobile devices are a major factor to consider and the speed of the connection and device power tends (esp phones) tends to be less than a desktop, every byte counts.
If we lived in a world where load times were instant and mobile devices as good as desktop machines I’d include every library under the sun just incase I want to use it. But as thats not the case I’ll continue to be choosy. ;)
My other worry is that things come & go and maybe another library will be more popular in a couple of years? Maybe not likely, but certainly possible. Will people start writing dual format tutorials?
Yeah, that’s a pretty large number of sites that don’t use libraries. To be honest, I was in the same boat a few years ago, so I would probably say the same thing: Out of the probably hundreds of sites I’ve had a hand in building/coding, only a handful use jQuery.
Second, even in those non-library sites, I had my own personal library of functions and whatnot that I would reuse for each project. So although I didn’t use a formal library, because of the amount of code I was using, and the possible complexity introduced by my own poor JS habits, it may have been more efficient to actually load up a library and use that instead. When you factor in maintainability of jQuery vs. novice or average raw JS, I think the slight performance hit in file size is worth it.
And regarding your comment on what libraries will be popular in a few years: Well, it’s we as web developers that “pave the cowpaths”, so as long as we continue to promote jQuery and hold it in high esteem, that will be the popular library. A library is popular because people write about it, not the other way around. I mean, it’s not a chicken/egg syndrome.
But overall, I think you and some of the others have made good points, so thanks for bringing this topic to light.
I agree – there is no point in using jQuery with a simple tutorial. I think this is where “library-less” JS comes into play, like Ender.js. With that, you could load in a selector engine, and maybe a DOM manipulator, but that’s it. None of the extra stuff jQuery has by default.
Anyways – great post.
I remember the days before jQuery, et al.
Аbsolutely agree, jQuery is good because that removes all cross-browser compatibility issues and even if it is a simple animation is better to do it with jQuery, especially if it’s animation with transparency.
jQuery code tends to behave like general good code: it’s mostly self-documenting.
If you read a chunk of jQuery code, you can more or less figure out what’s going on. As other commenters have noted, the point isn’t getting the code to run, but to understand what the technique is trying to illustrate. Most end projects won’t use the trivial solutions as provided in tutorials – the programmer doesn’t need code, they need the logic behind it. Unless an article is specifically about a coding trick (i.e. not about implementing a UI widget, etc), the code itself needs to get out of the way.
The reality is, this is what people use. I just read today that jQuery is now on more web sites than Flash. In the “Walnut, Meet jQuery Sledgehammer” example, he disproves his own point, by showing the nearly 3x as much code — which is far less readable and comprehensible than the jQuery example – that is needed to create his demonstration.
Why on earth would I want to see examples of some general concept (changing properties of an element), that include all the microcode needed to make it cross-browser compatible, e.g. testing for attachEvent? That’s just BAD CODE. Anyone writing in-line code to handle edge cases is writing unmaintainable, error-prone, redundant code. Good code abstract such things. Good coders use abstractions instead of writing an inline test for attachEvent every time they create an event handler. This should never appear in an example – unless the point of the example is, actually, to show you how to write cross-browser code.
Think you misread my post, as the point clearly is about saving bytes & not being reliant on jQuery. The pure JS example is larger and I state that, however the jQuery example becomes larger in bytes when you include its library too.
My example shows extra things such as x-browser code, ternary switching and leaving it open to more than just toggling as in the jQuery example. The things shown here are pretty common in pure JS examples and so I’d hardly say its bad code.
No – of course not. But does anyone really have an application that is, in its entirety, a single function to change a single class of one element? The point of the example isn’t an application unto itself. it’s an example.
And I really don’t think that anyone should be writing code with inline x-browser tests except as a one-off. Do you really have an application that only needs to do this once? If you’re teaching one-offs, okay, fine, but most people want to learn how to code applications, not one-offs.
Btw I very much agree that jQuery isn’t necessary for every single application. There are lots of alternatives. But writing code without a framework at all is just violating DRY up and down the block. As we’ve observed, you can hardly set an attribute in JS without having to address edge cases. We shouldn’t be teaching new programmers to reinvent the wheel on a daily basis.
yes, agree that jQuery more and more becomes essential in any websites.
I usually use CDN for jquery file, like Microsoft CDN to solve the problem of 90k bandwidth
I understand his view, but I think it’s a little short-sighted.
First, can we really call it a 90k library? How many people that have a browser/system capable of viewing jQuery have never been to another site that has jQuery called from Google APIs, or another CDN that’s commonly used? So really, we’re not talking about feeding them all of jQuery every visit. Most likely, it’s already cached on their system. Divide the number of visitors by the number of visitors that actually need to download jQuery fresh to see your site, and then divide the 90k by that – or something like that – and the actual overhead per visitor is going to be very small.
Second, we ARE talking about tutorials, right? Isn’t the intent of teaching to send out the student with something to build on – rather than a brick wall? When a student learns how to make a jQuery animation to fold up a menu, is that it? Do they go out to their web design job and do only THAT? Or will they build robust web applications using the fundamentals of what they are taught and expand from there? My guess is mostly the latter. I’ve picked up a great tidbit here and there from quick lessons that I’ve turned into major ideas. Would I have built on the same experience from a tutorial that’s “worthy” of using jQuery? What’s that? A tutorial on building a fully featured browser-based office suite in only 70 days?
Snippets and small lessons are how we become walking libraries of jQuery brilliance.
Why would someone bother about extra 90k? Also everyone have jQuery in their cache anyway.
jQuery is one of the frameworks. There are other JS-libraries and they could have a solution just as well, although the implementation might differ. It could be, that the solution presented is influenced by the choice of jQuery (a valid choice imo), but you are writing about some concept, don’t you?
Furthermore can explaining the basic concepts using raw script help readers to understand how jQuery or any other frameworks operates. There are plenty of sites in which someone can find how to accomplish a certain task with a certain framework. But are there many blogs talking about the concepts without the use of some library? That might be quite unique and hence very helpful.