A love letter to jQuery
madebymike.com.au
madebymike.com.au
Sometimes when I'm working with React or Ember on a large project, and have to do quite a bit of work for a small feature, I fondly remember the days of just banging out a two-liner with JQuery that would do the same thing.
I do think that data bindings in angular or the methods of working with mithriljs or react bring a lot to the table that you don't get from using jQuery, but I do respect what jquery gave us.
It was a cute article / nerdy fluff piece.
(I probably actually will move on at some point... when the dust settles and there are clearer options. And when I can go through some tutorials and have stuff all work. And when there isn't a huge huge library I don't need to to a few little things. In the meantime I proudly like jQuery and it works really well for the amount of JavaScript I need. Which amount incidentally is never on a server.).
"Doing it the [insert framework here] way"
Most frameworks try to change your beliefs about how and why you should do things, and they are differentiated by how different/better they are from then going through the "pain" (in their words) of using jQuery.
Personally I like the way Vue.js approaches things, it's like a nice mix of syntax readability and singe state/unidirectional data flow.
There is a server-side port of jQuery which is absolutely fantastic: https://github.com/cheeriojs/cheerio This allows you to render jQuery based views on the server or client with the same code.
All the latest JavaScript view libraries are a huge pain to work with. Sharp learning curves, punishing APIs, and extremely unexpected performance issues. jQuery just works.
<3 jQuery
I'm pretty firmly in the "You don't need JQuery camp", and the reason is that you don't need JQuery now. It was an amazing piece of software when it came out; it made rich JS development not only practical, but easy, without worrying about cross-browser issues. But it succeeded. Resig's goal - from very early on, at least as soon as he started to working at Mozilla - was to get JQuery baked into browsers, and he's largely done that. We got querySelectorAll. We got a unified event model that all browsers support. We got FormData. We got a consistent box model, and consistent getComputedStyle() behavior. We got animations and transitions, and the native versions even run on the GPU for fast mobile performance.
As a result, most of the problems that JQuery solved just aren't problems in modern web development. Cross-browser issues are minor and getting smaller every day. Selectors are baked in. Animations and transitions are CSS one-liners, rather than needing to spin up a setTimeout loop and manually calculate the delta in the property each tick.
That doesn't deny the historical significance of JQuery, or just how much it improved web development back in 2007. But we build apps for the world we live in today, and today, JQuery gives you some minor programming convenience in exchange for 30K of download size and a bunch of layout thrashing if you use its CSS or dimensions methods.
Forgetting to say "thank you" to people who helped us a lot is something that happens more than often in IT.
I still remember when I heard of jQuery. It was in 2007 and it was so amazing.
Yes, I admit, the 'alert()/console.log()' was amazing :)
JQuery and Firebug deserve a lot of credit for bringing some sanity to JS/web development. Sure things have moved on now, but they were ground breaking.
I never worked with Venkman but I recall all too well the hellish time I had debugging JS back around the turn of the millennium. IE was laughable, if there was an error in a script somewhere it would often just say error on line -1.
[1] https://webkit.org/blog/61/introducing-drosera/ [2] https://webkit.org/blog/41/introducing-the-web-inspector/
I think the sea change for me was not using front end frameworks, but when I first started trying to play with nodejs.
As soon as I started working with that AND started coming to understand the async nature of javascript, my entire world shifted underneath me.
In hindsight, I'm amazed that I managed to remain employed for so long while NOT knowing that javascript was async. Oh well. Such is life.
Anyways, I've definitely said "you don't need jQuery" on numerous occasions. There are plenty of places where it is the best and cheapest solution, but other times when it isn't (or isn't available).
1) First order functions that you can pass around.
2) The fact that those functions can be closures over the local scope, so it's easy to pick up from where you left off.
Two big mistakes in the design of JavaScript that work against easy "asynchronous programming" are:
1) That "this" is not lexically bound in the local scope (technically it's a magic "keyword" that's dynamically bound by the interpreter), even though in most cases capturing "this" lexically is what you really mean to do.
To mitigate that problem, you have to do silly stuff like "var self = this;" to copy dynamically scoped "this" into lexically scoped "self".
2) Each { block } doesn't have its own variable scope, so variables you bind inside loops that repeatedly create closures (like callbacks for a list of menu items) have their value changed out from under them to the last loop iteration when those closures are called later on.
To mitigate that problem you have to wrap another function(){ ... }(); around the loop body to capture the values for each loop individually.
Both problems cause subtle hard to find bugs, even when you know about them and are expecting them and programming defensively to avoid them. And both problems were bad naive design decisions that many other languages had previously gotten right.
But modern bleeding edge JavaScript now has "=>" fat arrow functions that bind this lexically, and "let" that declares block scope variables. (But that's not supported in all browser yet.)
Yay for progress! Worse may be better, but once you've wiped out the competition and taken over the world, there's no reason to keep it worse on purpose.
However, I disagree with your number (1). First, you shouldn't have to use "var self = this;" very often, unless this is your preferred style. Many JS libraries will let you pass in the context as the final argument in a function call. And if you can't do this, you should look to `bind` and `apply`, they're very handy for handling contexts [1].
I do strongly agree with your (2). But if I'm not mistaken, the latest versions of many browsers do support block scope already. I know Chrome does, and Firefox and Edge may as well.
1. http://javascriptissexy.com/javascript-apply-call-and-bind-m...
I am looking forward to the time that most major browsers support => and let.
I'm not sure I'm still against referring to javascript as asynchronous or at least as having asynchronous methods for the purposes shorthand and quick communication.
Consider the code (or paste it into a chrome console)
function _done(){ console.log(arguments) }
var db = window.openDatabase("dbfoo", 1, "test db", 5e6)
db.transaction(function(tx){
tx.executeSql('CREATE TABLE t1(a, b PRIMARY KEY);', _done, _done)
})
console.log("i happen before the line above me")
Anyways, looks like I'll have to train myself to use the right word for it. Thanks for pointing that out without making me feel dumb or being all insulting and internet-y. :) I really appreciate that.
EDIT: Hmmm... additionally, to be fair: it appears that some agree that it is OK to refer to parts of javascript as async http://stackoverflow.com/a/16524240/398055 so it might not be perfectly accurate, but it isn't wildly inaccurate either.
However today, I don't think it's as useful—I am not saying it isn't useful—as it once was. The overhead to support multiple modern browsers is usually very low, and often it's even none.
I also believe most of the problems people point about jQuery is that at some point a lot of confident, but bad developers, started using it and somehow jQurey unjustly gained that bad reputation.
I do avoid jQuery now though, I can't remember the last time I used it.
My experience is definitely that developers under 25 are much less likely to understand the historic context that jQuery came from, and hence have less respect for what it achieved (and continues to achieve).
Now I use typescript and no libraries at all. It isn't too difficult to write a utility object that can handle whatever depreciations or abstractions are fluctuating.
If you are writing a library of any kind and expect your clients to install jQuery for the benefit I'd say you've added too much bloat.
They also smooth out browser quirks which is less of an issue now with Modern browsers than it was at the dawn of jQuery which was another USP it had that propelled it to popularity.
But the biggest thing that I have learnt over the last few weeks was "browserify" it's really useful for all sorts of things. Take a look at 'npm' and how it installs all sorts of gubbins for you. You may never use it, but for things like coffee script, sass (I assume you know about bootstrap css?) npm will install them for you. browserify will transpile them for you.
I miss the web before the framework bro's came in and over-engineered the hell out of it.
I'm young enough that there's a generation of jQuery-loving developers above me, and the whole generation younger than me is enamoured with the newer frameworks. But for me it wasn't until I stopped looking at jQuery and focused on proper JavaScript that any of it made sense to me.
The thing I find remarkable the more I learn Js is that the 'level' of the language seems perfect for the problems you're working with. jQuery makes things abstract and high-level enough you'll never figure it out - and any lower level and JS would be a lot harder to learn. The more I get into it the more perfectly suited to the task it seems to be.
I disagree. While I am building our actual app in Angular, our landing page and that still uses jQuery for things such as ajax requests. There's no need to pull in any major framework like Angular for such tasks.
jQuery still has a lot of relevancy in the web.
From personal experience: just few days ago I've made a landing page. Focus was on mobile and performance so no jQuery, modernizr, lo-dash, and so on. We only grabbed some syntatic sugar from microjs.com so we could write $(el).remove() instead of el.parentNode.removeChild(el);, etc.
Turned out a nice, little page with all the usual bells and whistles only really needs a 12KB of JavaScript code (uncompressed). We actually missed lo-dash more than jQuery.
In age of "modern browsers'" ubiquity, and Angular/React/Ember/MV* libraries doing the heavier stuff, the support for older IEs is really the last selling point of jQuery. And that goes away soon.
P.S. Very handy: http://youmightnotneedjquery.com/
I mean, it's like less than 30kB minified+gzipped, and if you load it from a CDN, then there's a 95% your users already have it cached.
I guess it's technically a "bloat" but unless all your images are gzipped SVGs, it's almost certainly one of the smaller elements in your page.
And for various reasons, it's not a terribly good reason to use the "latest" jQuery version with no version, unless you're prepared to deal with sudden code breakage.
In reality, there's a less than 5% chance that your users will have the right version cached, but a 95% chance that your users will notice when the public CDN is over capacity.
jQuery was originally a bridge for the gaps between browsers for lots of basic functionality. These days, all modern browsers give you a decent starting point with plain js, meaning there's not a whole lot of things that you really need jQuery for. Secondly, you mention that you are using angular, which already provides its own $http and $resource libraries for ajax... which I think shows even further that you don't actually need jQuery.
I do wish jQuery would update to support ES2015 module exports so I could do something like import { ajax } from 'jquery';
As other posters have written here, you can easily now do just about everything on "Vanilla JS" as you can using jQuery. In my experience, the possible exception to this are animations which require significant boilerplate. However, most common animations are now extremely trivial to accomplish using CSS.
I haven't used jQuery for new project in 2 years, unless I have to support less than IE9 (and even then, I make sure I really need it first).
jQuery is vanilla JavaScript. As a full stack JavaScript developer, it pains me that people think that something written in JavaScript isn't vanilla JavaScript. It is.
yeah if you are a masochist
Alright, technically it's not 'needed' for any web projects. But it sure can help in a lot of ways on a lot of projects.
On modern browsers? Can you give me an example?
* A lot of plugins/libraries require jQuery, so by using jQuery you can use those plugins.
* It's easier to hire junior devs that can write good enough jQuery, compared to native JavaScript.
* As a very mature library, there's lots of documentation out there for standardising the way you do things. This makes it easier for other devs to pick up your work.
I'm seeing more and more mature "Vanilla JS" libraries for common tasks I used to use jQuery plugins for. But yes, if you must have some plugin, then you have to use jQuery. In that case, it's probably not worth the time to re-write the plugin in Vanilla js unless you have some specific bandwidth constraints among your users.
> It's easier to hire junior devs that can write good enough jQuery, compared to native JavaScript.
Sadly, you're probably right about this. I'm a little uncomfortable with the term "native" JavaScript since that makes some devs think it's some kind of OS hacker-level of difficulty, when in fact, most jQuery equivalents in modern JS are quite similar to...jQuery.
> As a very mature library, there's lots of documentation out there for standardising the way you do things. This makes it easier for other devs to pick up your work.
Sure, I can see this being true. I guess if you have to hire and train a bunch of relatively middle-of-the road junior developers, jQuery is a good choice at the moment. But even if I were in your position, I'd still try to push them to get used to writing in vanilla JS. This is good not only for your project, but also for them, since more and more employers, even mediocre employers, will start expecting potential frontend dev employees to be able to write vanilla JS.