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:
Do you really need a 90k JavaScript library (and thats the minified version) to toggle the size of a menu?
I think his point is valid, and it’s something I’ve seen before in comments, and even from experienced JavaScript developers and bloggers. For example, in an article on SitePoint covering Drag and Drop in HTML5, Alexis Goldstein uses jQuery to demonstrate HTML5’s drag and drop feature. A comment from James Edwards on the post makes a similar point to that of Matt Pass.
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?
Yes, there are small sites built all the time. There are brochure sites, there are one-page info sites, there are microsites — which may not have any, or very little, JavaScript. But those sites are becoming less and less common.
JavaScript libraries are virtually mandatory in websites and web apps today. And sure, it’s nice be able to write things raw like Matt demonstrates in his post. But I feel that in almost all real-world cases, developers will be including at least one major JavaScript library.
So, the problem that Matt points out (i.e. using a sledgehammer to crack a walnut), is actually not a problem at all. In fact, the opposite is true. Because if you are including a library, and you still choose to write lots of raw JavaScript, then you’re probably writing more code than is necessary and are letting the library be a wasted resource.
Yes, in some cases, for performance reasons, even with a library loaded up, you might be better off using raw JavaScript (for example, a simple for loop might be more performant than jQuery’s each() or find() or whatnot). So I’m not completely downvoting the using of raw JavaScript. And that’s besides the fact that oftentimes I just remember the raw version easier than the jQuery version, because that’s how I learned.
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.
JavaScript is Often Beside the Point
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.
So, although a discussion of some of the extra code used with raw JavaScript might have its benefits, I think it’s better to stay focused on the main point of the post, and not get clouded with other more complicated issues. And if anyone wants to learn raw JavaScript, there are plenty of sources for that.
Thoughts?
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.
Do you prefer that tutorials use jQuery in all cases? Or would you rather see raw JavaScript that can easily be put into a page that doesn’t require any dependencies? Do library-free websites exist anymore?
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 think it’s a non-issue like you said. Most non-trivial projects will have a major Javascript library/framework, often being jQuery. As for performance, increasingly that’s not an issue either if you load it from CDN, chances are good it is in your cache already.
I do agree that one needs to be critical in what you use javascript/jQuery for. For example, I don’t think it is conceptually sound to do a lot of styling tricks in your javascript.
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.
Great comment, I think it depends on the target audience. I certainly agree with you that for true educational value, knowing vanilla Javascript is an invaluable skill that can be “ported” regardless of whether one uses a library (or which one) or not.
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.
I don’t think jQuery or whatever “general purpose” library is mandatory to write JavaScript (I write JavaScript since 5 years at least and I never used it). Actually, I would have replaced the paragraph “Is Library-less Code a Reality Anymore?” with “Is Cross-Browser Scripting a Reality Anymore?”. If you omit IE8 and less (which seems reasonable when you want to learn JavaScript), the DOM API fragmentation is ridiculous: there’s simply no need to wrap it. Writing pure JavaScript is so easy and, from my point of view, very elegant. Moreover I think the DOM API is not ugly and, in fact, quite consistent *and stable*.
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?
Hey, Matt.
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.
But there are a few reasons for that: First, although I don’t consider myself a JavaScript expert, I learned raw JS first, and only started using libraries in the past few years.
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.
Hey Louis,
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.
Coding even trivial things with JavaScript was a nightmare – cross browser issues would rear their heads on a continual basis. I’m not sure what the situation is like with raw JS in today’s browser landscape, but I’d hate to go back to the days when I spent countless hours hating JS.
А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 difference between Javascript and any other programming language is that people used it for a long time without any substantive frameworks, because they just didn’t exist. But nobody would give an example of (say) C# code while ignoring the .NET framework as an integral part of how people actually use in in most real-world situations.
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.
I disagree- you say “do you really need a 90k JavaScript library (and thats the minified version) to toggle the size of a menu?”
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.
I think that all the things that are demonstrated in your example are useful for someone to learn at some point. But the example isn’t about teaching x-browser javascript, or ternary switching. It’s about toggling classes.
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.
I’m not so concerned with pushing jQuery or anything else as a framework. Maybe someone writing an example like that should be selling it as a jQuery example, and not a Javascript example. But that’s just semantics. At the end of the day, few programmers creating substantive works will be worrying about the existence of “attachEvent” because either they are using jQuery or prototype or they have their own function to do the same.
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
Hi
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.
In fact, if all developers stuck to jQuery and gave up all other javascript libraries and frameworks, then it would pretty much reduce that overhead to minuscule numbers. Everyone surfing the web would have jQuery cached – I dare say browser manufacturers would even start embedding jQuery right into the browser itself (how awesome would THAT be?!?!)
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.
You missed an important case here: some people may want to apply concepts from your tutorial in a language or environment where the Javascript library (e.g. jQuery) is unavailable.
I’m working in Dart and trying to transpose your CSS concepts. To do that I’m translating the small bits of required Javascript code into Dart. I don’t want to have to try and figure out how to link up JavaScript interop just yet. I just want the walnuts, please!