Slashdot Mirror
JavaScript Devs: Is It Still Worth Learning jQuery?
Nerval's Lobster writes: If you're learning JavaScript and Web development, you might be wondering whether to learn jQuery. After nearly a decade of existence, jQuery has grown into a fundamental part of JavaScript coding in Web development. But now we're at a point where many of the missing pieces (and additional features) jQuery filled in are present in browsers. So do you need to learn jQuery anymore? Some developers don't think so. The official jQuery blog, meanwhile, is pushing a separate jQuery version for modern browsers, in an attempt to keep people involved. And there are still a few key reasons to keep learning jQuery: Legacy code. If you're going to go to work at a company that already has JavaScript browser code, there's a strong possibility it has jQuery throughout its code. There's also a matter of preference: People still like jQuery and its elegance, and they're going to continue using it, even though they might not have to.
Basically this. jQuery is one of those things that's almost literally bloat: it adds nothing that your browser can't already do, it just wraps around it. You absolutely do not need to use it.
However it saves on development time. It's effectively a bunch of boilerplate code that you don't have to deal with. It's one of those things that if you were to decide not to use it, you're likely to end up rewriting a chunk of it by the time you're done anyway, so you might as well go ahead and use it from the get-go and save yourself some time.
(Which isn't to say you should always use it. I've written pages where the amount of dynamic code was small enough that using jQuery would make absolutely no sense. But the larger your project gets, the more sense it makes to use frameworks like jQuery.)
You are in a maze of twisty little relative jumps, all alike.
I saw a very insightful & funny talk on this subject last year. The very clever Josh Broton lays out exactly why jQuery has become an excuse not to do it right the first time. Basically it comes down to this:
A few facts about latency and user behavior: "...250 milliseconds can be the difference between a return customer and an abandoned checkout cart." "...every 100 milliseconds of latency resulted in a 1% loss of sales." "...lose 20% of their traffic for each additional 100 milliseconds it takes a page to load."
The average overhead jQuery adds to a website: "... add roughly 150ms to 1 full second of load time..."
He goes into many other good reasons too, it's well worth a read.
Slide here: https://github.com/joshbroton/...
Instead of throwing many small fragments at the browser and stealing user cycles to cobble it all together, just serve up the content already.
I have served the document. Now the user has activated a control to expand details of a particular part of the document. How should this click be processed?
Or I have served the document. Now the user has opted into real-time updates of part of the document. How should these updates be served?