The history and legacy of jQuery
blog.logrocket.com
blog.logrocket.com
jQuery plugins/extensions/libraries/whatever.
An awful lot of libraries for things like carousels and masonry type grid systems and other such things are built with jQuery as a dependency, so anyone wanting to use them (especially to avoid rolling out their own version) is stuck relying on it.
Fortunately, a lot of these things have either moved to working as standalone vanilla JS type deals, or to NPM modules instead.
Unfortunately, the latter is argubaly causing the same dependency hell issue, since many devs will now basically throw in a full JavaScript framework and a bunch of task builders and managers like webpack just to be able to include said modules more easily and save on development time/costs.
jQuery plug-ins often have a certain polish to them that works great on desktop browsers and rarely mobile, since it’s from an era where the talented plugin (i.e. component) authors didn’t have mobile browsers as a target. Whereas react-component feels like it’s authored for Chrome targets (iOS safari compatibility by accident) since front end devs kind of live in that DevTools universe nowadays. The npm package community in general is hard to generalize.
As far as frameworks facilitate people who care about really fine interactions I’m all for it. It wildly enriched the ecosystem.
Like someone had to figure out all the little interactions that Google and Apple industrialize (i.e. clone) into their UI frameworks. We just don’t ever hear about the original authors because they don’t have multi-million dollar developer relations budgets. So while you’re right that there’s a dependency hell or whatever high brow engineering problem, we see that with the privilege that someone at Google is getting paid $250,000 a year to industrialize/copy the good idea.
Yep, you're exactly right, the plugins are from a different era and have less utility today.
That said, jQuery itself still has immense utility. It's expressiveness and simplicity are second to none.
The author points to youmightnotneedjquery.com as an example of why jQuery is superfluous today, but if you look at the examples a bit more closely, you'll notice problems. I spent all of five minutes glancing through the YMNNJ example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often much more verbose and less expressive than the jQuery examples.
I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components.
jQuery and SPAs don't have to be mutually exclusive. At my work, we've been building SPAs with jQuery long before Angular, React or Vue even existed. Within the past few years we built our own JavaScript SPA framework whose components can be written with vanilla JS or jQuery. Most of us prefer to use jQuery for our components because the syntax is often more expressive and concise than vanilla JS. We open sourced the framework at https://github.com/elliotnb/nimbly and it's state management utility at https://github.com/elliotnb/observable-slim
Our framework core uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, we don't see any reason to rush to rip jQuery out of the framework core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.
Long live jQuery :)
The reasons for switching years ago may not apply as much. jQuery was slower for large amounts of dom changes but browsers have gotten better so this isn't as much of a concern for a normal website. I didn't get that messy feeling I would get when pages got too complex like thry would in 2007.. perhaps because I'm breaking things up differently. That might be because my understanding of javascript has increased since. Maybe jQuery was never the biggest problem with bloated frontends maybe I was.
But if the site or web app gets larger, I would want to use an SPA to eliminate manual DOM manipulations -- for both performance and maintainability reasons. jQuery still offers great utility in today's SPA world, but unfortunately the most popular JS frameworks have gone so far into developing their own domain specific languages and opaque rendering processes that most parts of jQuery can't be used with them.
I wish more frameworks allowed components to be written in vanilla JS and had rendering that returned standard DomNodes.
Except that it won't work for ~6% of your visitors (± a few percentage points, based on your locality and audience).
Some developers sneer at these kind of numbers and comaplain about old browsers and whatnot. Yeah, it's annoying. But it's also reality, and as a professional you'll have to deal with it.
> The querySelector and querySelectorAll methods replicate jQuery’s selection capabilities
The jQuery selectors have quite a bit of extra useful functionality though.
We recently checked our top sending domains (the car-buying customer’s email address), and of course @gmail.com is #1, but @aol.com and @comcast.net are in the top 5.
Depending on the dealership, all the PCs can be locked-down on IE9.
Yes, by not supporting those users. If you want to use IE 11 that's fine by me, doesn't mean I need to go out of my way to ensure it works for them.
I really hope you are right about January and this counter is wrong.
In the meantime I'm not worrying about IE anymore (have luxury of not working at bigco and can say, "sorry, we don't support that").
The variance is a lot higher than that. Tons of web projects are for internal tools (controlled environment), for mobile first, or in industries or language communities or countries or markets where the browser distribution is entirely different.
So as a professional what you do is (1) measure, (2) reach a business decision about browser support, and only then (3) choose technologies.
With polyfills and Babel, using new features in old browsers isn't really a problem, but it's unfortunate that this is often required, and it's unfortunate that Web development has become so fragmented by developers preferring to use tools built on the platform rather than authoring for the platform directly.
It’s more verbose and everybody has to relearn something they can already do in more readable and compact code.
Why haven’t they simply adopted jQuery’s APIs?
That ship has long long sailed, but still, I think we would’ve been in a much better situation right now.
- `document.querySelector` vs `$`. - `element.addEventListener` vs `$element.on`
JQuery really has some confusing behaviour too. JQuery sets the target of the event as `this` inside of the method. Native makes it an event property.
Also some programmers opt for readabiltiy over terseness.
I've been changing my style to be more terse but that makes it more readable or easier to see the abstraction concept rather than the details.
I'd much rather read
rect = element.getBoundingClientRect()
area = rect.width * rect.height
velocity += acceleration * deltaTime
position += velocity * deltaTime
r = e.g()
a = r.w * r.h
v += a * d
p += v * d
Google, Apple, Microsoft, Facebook etc all specifically say terseness is not a goal and say to use whole words so naming a function '$' would be explicity against their guidelines. I suspect there's a reason for that. The most obvious is I don't know what 'a' or 'd' or '$' mean without digging through the code but I do know what 'area' or 'detlaTime' or 'getElementById' mean
One of the reasons I like lisp-like languages more than the rest is because hyphen-separated-symbols are a lot easier to read than camelCase, which feels cramped by comparison. (underscore_separated_words is an improvement over camelCase, but for some reason people seem to shy away from it. In any event I think hyphen-separated is superior, since hyphens are used to conjoin words in English prose, while underlines typically aren't.)
It reminds me of reading 17th century dense English. I don't see how query or select is any less descriptive than querySelector.
I find that names are rarely all that useful anyway, since you can't capture the full effect of a function in a name in most cases. I once named a method mkdir() and then someone commented that it was "obscure", so it got renamed createDirectory(), then someone commented that it was actually creating all intermediate directories, so it became createDirectoryTree(). This still doesn't really communicate that it won't error if the directory already exists, so I commented it should really be createDirectoryTreeOrDoNothing().
`mkdir` is immediately obvious to someone like you or me that has a background in dealing with legacy system design (namely, any Linux/Unix/BSD/GNU system that all derives from early 70s design ethos (or hardware limitations..)) but to somebody who's not already steeped in this tradition, it's basically a bizarre incantation.
And mkdir is far from the worse of it; once you learn what it means it's easy to create a mnemonic mapping between `mkdir` and "m[a]k[e] dir[ectory]". But what about something like `ln`? Obviously that's "natural logorithm", everybody learns that in highschool. Wait no, it's not that at all. It's "[make] l[i]n[k]" Frankly, that's crap. Contrast with `make-file-or-directory-link` from racket. It means the same thing but it's more than 10x as long (less dense) and there is simply no way you could mistake that for a natural log function.
I don't think the problem with 17th century prose is density either. Rather, it's archaic vocabulary, idioms, and grammar. I've recently been reading through an anthology of English renaissance drama and my impression is that once you become acclimatized to the common archaic vocabulary and grammar, the idioms remain as biggest impediment to understanding. Consider:
> "Art thou in thy wits? I tell thee I must have a pair of shoes; dost thou mark me? A pair of shoes, two shoes, made by this very shoe, this same shoe, against tomorrow morning by four o'clock. Dost understand me? Canst thou do't?
He's asking for a pair of shoes, and questioning whether his request is understood. It's not a particularly complex or information dense paragraph, but it could be hard to understand if all of that archaic vocabulary is obscure to you. In many ways, this makes it very similar to your average bash script. Saying something simple, but made to seem complicated by archaic terminology.
Instead, browser have two incompatible APIs: `querySelector` to retrieve one item only, and `querySelectorAll` to retrieve multiple items.
On top of that, jQuery always returns an array-like object. `querySelectorAll` returns a NodeList that is so poorly designed that it didn’t have a `.forEach` for two years or so, and you’re still better of doing an `Array.from` on it for the sake of consistency and sanity.
For every thing that jQuery got right, browsers got 10 things wrong. For every thing that jQuery got wrong, browsers got 100 things wrong. It took browsers 7 years to implement querySelector/querySelectorAll after jQuery showed it’s possible and useful. And they still got it wrong. 13 years after jQuery debuted DOM APIs are still a mishmash of extremely poorly designed functions that are unnecessarily verbose and error prone.
`querySelectorAll` doesn’t even return an array-like object. It took w3c almost two years to add a forEach to it.
It’s also so badly designed that MDN docs has a whole section oh how it behaves with unexpected results and how, quote “to restore expected behavior”.
So all perceived benefits (like the separation between Element and NodeList) are badly contrived and trumped by how badly they are designed in comparison with a 15-year old library whose core API was designed by one person.
Similar in prose, if you can say it in 5 words, then why use a paragraph?
Of course, there is a sense in which lisp-like code can be dense while at the same time having verbose names for things. Consider this and an idiomatic C equivalent: (filter odd? '(1 2 3))
That is simultaneously intuitive and verbose. Would it be improved by changing `filter` to `fltr` or some nonsense like that? I don't think so. But even though it hasn't code-golf'd the names for things, it's doubtlessly shorter (denser) than the equivalent in idiomatic C using the mangled shortened identifiers that are par for the course in that language. Density through good abstractions is superior to density through short names and abbreviations.
Could you do both? Sure. But for what marginal gain?
* Variable argument types determine different kind of behavior, like ajax taking a string or object as 1st argument. Other functions take a function or string as a parameter. I'd much prefer it enforce a single style or define a new method, ajaxurl() and ajaxobj().
* naming of `off()`. In this context, off is not the opposite of on. On here means 'in event of'. A better word would be 'cancel' or 'mute' or 'ignore'.
element.on('click', dostuff);
element.ignore('click');
It would be insane not to. I don’t really see your point.
My point is that you simply can't do that. It would be irresponsible, short sighted, and dangerous. We are talking about a language used in nearly all of the web. The decisions that get made around it have an impact of decades. I HAS to play nice with all the prior art out there and it would be a _terrible_ decision to start adding one off handling for compatibility with libraries built atop it.
Why would it? jQuery’s APIs could be folded into HTMLElement and HTMLDocument. Instead, we’re stuck with 90s-era Java style in all the DOM APIs.
Of course not. You can implement the same API without stealing its namespace. $$, sel, select, whatever.
>Are you in all seriousness saying that a native spec should account for a library?
If it's by far the most widely used one, one that changed the way we write web apps, and made viable a whole class of solutions, then of course. That's one of the main ways platforms grow. You see how people are using it and you make it even easier, faster.
What I'm saying is, we have a half arsed copy of jQuery when we could've had the real thing, only faster and builtin.
Instead of trying some ideas in a library/framework, iterating until polished, then considering making it official, we reinvented the wheal from scratch, only, unsurprisingly, worse.
Doh! Yeah you are right (and I feel dumb). I suppose that would be more of a w3c/browser vendor thing wouldn't it?
Appreciate the support on the rest of it. :-)
The DOM APIs grew slowly mostly because of the general stagnation in the browser market, but they have been a long-lived, relatively successful API on which popular things like jQuery (or its competitors) could be based.
This is a backwards way of looking at it. jQuery was always a convenience layer over the DOM, and the DOM and other browser APIs have undergone continuous improvement since before jQuery was even a thing.
When you say "native alternative to jQuery" it's clear that you don't understand the orders of magnitude difference in effort required between standardization and browser implementation of new APIs versus throwing a library up on github.
If browser vendors adopted jQuery APIs, you'd have a redundant DOM, incompletely implemented, with unique bugs in each browser, and probably being widely deployed just in time for React to come into fashion and make it all irrelevant.
jQuery is, among other things, an alternative DOM manipulation API built on top of native ones. And it is a better API at it. I say that because we have voted with our feet and querySelectorAll is clearly inspired by, but still a paltry copy of it.
>When you say "native alternative to jQuery" it's clear that you don't understand the orders of magnitude difference in effort required between standardization and browser implementation of new APIs versus throwing a library up on github.
I'm sorry, you are not making much sense. jQuery predates GitHub by a few years and was, at its heyday, more important than any single browser alone, I'd argue. Its API has been stable since before open web standards was a largely agreed upon thing.
>If browser vendors adopted jQuery APIs, you'd have a redundant DOM…
It wouldn't be redundant, it would be the default. I don't think you understand what I was questioning.
>…incompletely implemented, with unique bugs in each browser…
Again, not much sense. Why is implementing the current API guaranteed to be any more complete and bug free?
>…and probably being widely deployed just in time for React to come into fashion and make it all irrelevant.
From the article:
“jQuery is the most widely used JavaScript library in the world.”
“W3Techs estimates that about 74 percent of all websites use jQuery.”
So you're saying native is like an apple and jQuery is like an orange. So far so good.
> And it is a better API at it.
And now you're comparing apples and oranges.
Here's what you're missing: one guy (John Resig) implementing a library can give it a consistent UI and work through the browser incompatibility issues of the day and release something in a matter of weeks. That was enough for jQuery to find a few users and grow. No committees had to approve this. Compare any web standard, ever, with this process.
DOM came first, so it didn't benefit from hindsight, and it was designed to be consistent, sufficiently complete to eliminate non-standard APIs, and well-specified enough that all browsers could and would implement it. Test suites had to be created, each browser team had to implement these features, changes had to be made to the specs in some cases when reality diverged, and so on.
This is the orders of magnitude more effort that I'm talking about. Is the DOM a beautiful API that people love? No, it's a standard created by committees and competing vendors. It's functional, everyone eventually got behind it, and today it still works.
Without DOM and the initial W3C standardization push, there never would have been a foundation for jQuery to build on.
> jQuery predates GitHub by a few years
That's correct. This was the modern shorthand for "make it available to the world". At that time it meant registering a domain and throwing up a website. The point is: no committees.
> at its heyday, more important than any single browser alone
Apples and oranges again. Nobody has ever had the choice between using a browser on the one hand or a javascript library on the other, so I'm not sure what you're trying to say here by one being more important than the other.
> Its API has been stable since before open web standards was a largely agreed upon thing.
This is incorrect, the web standards movement was in full tilt long before jQuery (or YUI, Dojo, Mootools, etc, etc) existed. IE5 still had significant market share, but even MS at that time gave lip service to the importance of Web standards.
> It wouldn't be redundant, it would be the default.
That's not how this works. You can't remove old APIs, because the Web relies on them, so now you have two ways to do the same thing. That meets the definition of redundancy. Whether one of them is the default or not is irrelevant.
> Why is implementing the current API guaranteed to be any more complete and bug free?
It's not. The point is that, since jQuery is a library, it's free to develop workarounds for every known browser bug that affects it. If you get rid of the library and have native implementations... well now you have implementations, not one implementation. Now you need a new library to smooth over the differences.
> Please explain how that's irrelevant in any way.
Developer mindshare has moved on.
Just like COBOL, jQuery isn't going away overnight, but it would be a shame to go through tremendous effort to standardize on something that's already on the edge of obsolescence.
The argument that I've made many times in this thread is that jQuery, built through iteration, feedback loop and with the benefit of hindsight is a better API than document.querySelectorAll() et al.
And there's no reason why we couldn't have used the former instead of the latter. Why would a library to “smooth over the differences” be needed for sel(".element") and not for document.querySelectorAll(".element") ?
No one was suggesting changing document.getElementById(), etc, so nothing would break.
DOM manipulation is not going anywhere, React and friends notwithstanding.
jQuery selectors are quite a bit different from querySelectorAll, among other things, they don't return native DOM objects, but rather jQuery objects, which have bizarre and unnecessary re-implementations of things (like .each) that have not been necessary in modern JS/DOM for about ten years now, so it's not so easy as "just use jQuery, but standardize it".
If your argument was that the standardization process should have considered jQuery and other prior art, and taken good ideas from it, then of course that's exactly what happened.
jQuery is great, and it's still a really useful library in some circumstances such as supporting incredibly old browsers, but if you're adding 30kb of weight to a page because you don't want to learn the fetch API then you really need to rethink how you think about users.
Maybe a comparison using more modern browsers would be more convincing...
I still use JQuery to this day, but probably because I don't really rely on JS in my applications that much. Unless you're building an "app" from the get-go, it's still my default choice.
However, you hardly ever need to use an XMLHttpRequest any more, and the native Fetch API is already as simple as jQuery's interface for most day-to-day tasks. The only major browser that doesn't support Fetch is IE, and if you still need to support IE for now, you might be better off with a simple polyfill for the standard Fetch API rather than coding around jQuery.
Similarly, there is no need for monstrosities like calling Array.prototype.forEach.call on a NodeList returned by querySelectorAll instead of jQuery's $.each any more. Again, everything except IE supports forEach directly on a NodeList, and if you still need IE support, you can use a simple polyfill. If you need a real array to work with, an ES6 spread operator will build this for you with something like [...document.querySelectorAll('.someClass')] since the NodeList is iterable these days too.
So we're left with what? The $? One could simply do `const $ = document.querySelectorAll;` and get quite a bit of the functionality (I wouldn't really recommend this as it's not a drop-in replacement)
Now if we mean the entire jQuery ecosystem. Please.... NO! Tons of bloated non-performant libraries for things like carousels... when a simple `overflow: scroll` could have worked. It was such a nightmare to deal with on mobile devices!
You can peruse Can I Use https://caniuse.com/#search=fetch to evaluate if the API is widely enough supported to be viable. Then you have to figure out which bugs and incompatibilities exist across browsers.
If you look at http://youmightnotneedjquery.com/ you will notice that the native approach is at best similar to jQuery, but in many cases more cumbersome and verbose.
30kb is completely insignificant.
Using jQuery is just easier and less risk.
And by correctly using polyfills only on browsers that don't support native fetch, the majority of your users (chrome/safari/firefox) won't have any extra dependencies by using fetch, whereas jQuery will need to be loaded on every browser that hits your site.
[1] https://bundlephobia.com/result?p=unfetch@4.1.0 [2] https://bundlephobia.com/result?p=jquery@3.4.1 [3] https://www.telerik.com/blogs/jquery-using-only-what-you-nee...
Does the size of jQuery really matter for a typical web site? If you have just a typical size logo, it will dwarf the size of jQuery, never mind if you have some illustrations or photos.
In modern sites if javascript doesn't load sites then become non functional, e.g. navs don't work, some SPAs won't work at all. Whereas an image or favicon taking a long time to load shouldn't stop the user from being able to functionally view most of the site.
JavaScript has, in a addition to download time, parse and execution time. These are non-negligible on lower end devices.
30k of JS has a far greater impact on the speed of your page than 30k of images.
The point is to not send data the user doesn't need. It doesn't matter if you're using 50MB of images, fonts, video, etc in a page... Adding an extra 30kb you don't need is not good for the user. So don't.
(Also don't stick 50MB of assets in a page please.)
Also, if you're serving jQuery from one of the major CDNs (as many, perhaps most, sites do), the probability that it's already in the browser's cache is pretty close to 1, in which case the "30kb overhead" is utterly irrelevant.
> There is more to it than "wanting to learn".
Indeed. What about people who just think the new official APIs suck?
Strange as it may seem, there are people who would rather type "$" than "document.querySelector", especially when they're going to be doing it hundreds of times. With respect to "bloat", "$" is one character. "document.querySelector" is 22.
We've got an entire generation of front-end guys tooled up with awesome-looking IDEs and six hundred npm packages creating sites that need none of that. Each of these packages has dependencies, bugs, security issues, their own roadmaps, and so on.
I believe in brutally low overhead websites, but I'd still use JQuery if I had to. It's one of a very few things that just make sense no matter what you're doing, and combined with CDNs and cache reloads, you're highly unlikely to be pulling even that 30k over the wire when you use it.
We're going to make a ton of super-cool websites using the new stuff we have. Meanwhile we're also going to make a ton of messes. The cool kids will move on to more tools and gadgets. The second-string bunch will be left struggling to maintain. At some point there'll have to be a huge clean up. Consultants will make lots of money. Many of these consultants will be the people selling us all this crap we don't need right now.
I wish this were some outlier story or a case of crotchety cynicism, but tech has been really consistent about repeating this pattern over and over again, sadly. We keep buying and using things based on the way we feel. Then they don't work out, people get frustrated, make an entirely new layer of stuff designed to make us feel good. Meanwhile, about 1-in-100 of these things turn out to be useful over longer periods of time. I'd give that award to JQuery.
The Js framework ecosystem is incredibly easy to work with in 2019, sorry if I came off a little strong with my rant but that sentiment makes me cringe. It is absurd hyperbole that’s not productive and doesn’t reflect the real state of web development in 2019 in any way. Overall I agree a framework isn’t a requirement for a good web app
Can you help me get npm installed under windows 10? Serious question... moved from windows 7 to a brand new computer with windows 10 and the modern js ecosystem doesn't just work. I have node installed paths set
That being said I’m not sure what trouble you’re running into but I highly recommend using chocolatey as a native package manager for windows, it works very well as a replacement for utilities like apt-get, yum, brew etc.
The 30k load once for the entire site is rarely an issue unless you are building super light where you would avoid using an image because you feared that extra few k.
$ = document.querySelector .bind(document);
$$ = document.querySelectorAll.bind(document); $('p').on('click', el => /* ... */)
I just started working on a dashboard for an embedded network device, and bootstrap + jquery seems perfectly fine there, and I don't need spend a month to learn react/vue/webpack/etc and become a js expert before I can do anything productive.