Hacker News new | past | comments | ask | show | jobs | submit login
The history and legacy of jQuery (logrocket.com)
124 points by blast 30 days ago | hide | past | web | favorite | 107 comments

There's another reason to use jQuery not included in the article, albeit one which has lost a bit of relevance in the last few days:

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.

There’s a difference in quality between these jQuery and NPM (and react component) things.

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.

> There’s a difference in quality between these jQuery and NPM (and react component) things.

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 :)

I started a project a few weeks ago and decide to use jQuery because someone on the team didn't know vue and I felt it wasn't worth the effort to convince them to try it. Use jQuery I'm finding the expressiveness and simple approach amazing.

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.

Yeah, for smaller sites plain old manual DOM manipulations can work just fine. You're writing productive code right from the get go. No need to learn the nuances of a JS framework.

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.

> For example, the Fetch API can replace jQuery’s Ajax functions

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.

So, I work with car salespeople at dealerships, and also their customers (car-buying folks).

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.

You can polyfill it in under 500 bytes: https://github.com/developit/unfetch

And 7 more polyfills later and you've ended up with a hacky and incomplete version of jQuery.

No, you've ended up with standard web APIs so you can safely drop those polyfills whenever browser support is at an acceptable level.

Yes, there is also polyfill.io, which sniffs user agents and only sends the scripts a particular browser needs.

You still have to polyfill Promise, so it's definitely not under 500 bytes.

> ± a few percentage points

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.

> and as a professional you'll have to deal with it.

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.

As a person for your hobby project or whatnot? Sure. As a business? Yeah nah, that's not how it works. Imagine turning away 7% of your customers at the door of your shop.

In some industries it's much more than 7%. Luckily once IE11 is EOL (which IIRC is in January) I'll be able to block requests from that browser, but only because I can use the argument "this browser is EOL and using it is a security risk." Not every business has that luxury.


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").

I very well might be in a management role before I have to stop worrying about IE 11 directly. This countdown couldn't come sooner.

Ah, crap. It’s IE10 I was thinking of, so it’s still IE11 I’ll be suffering with for some years.

It's all just a matter of cost x profit. If supporting those 7% doesn't make up for the the cost of supporting them, then it doesn't make sense to support them. However, if supporting them is worth more than the cost to do so, then it'd be silly not to.

IE10 will be EOL in January. IE11 will only be EOL in 2025...

At a previous job ignoring these users meant ignoring the size of a small country monthly.

Support them the same way you support users without JavaScript. There will always be users without JS, so you need to deal with that. Treat old browsers as just another browser without JavaScript. It’s very easy to do if you use script type=module.

I never understood why browser vendors went to the trouble of agreeing on and creating a native alternative to jQuery.

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.

> agreeing on and creating a native alternative to jQuery

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 was always a convenience layer over the DOM

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.”
Please explain how that's irrelevant in any way.

> jQuery is, among other things, an alternative DOM manipulation API built on top of native ones.

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.

I was about to answer you point by point, but it's probably not much use.

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.

If your argument is that the method names in DOM should be shorter, then sure, I agree. It seemed to me you were arguing for something else.

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.

I appreciate the clearer naming of the built in methods.

- `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.

I hate the verbosity of it. The “fun” part of jQuery is important to its success.

Personally I don't see the problem with code that's verbose in this manner. If the right names for things are chosen then the code written with those names will read like prose, which makes it pleasant for a programmer and approachable for a self-styled non-programmer. And it's not like it's much more typing, what with modern completion systems in modern text editors...

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.)

I find long names like this much harder to read because the entire text/code is so much more dense, and it really adds up quite fast if all function/variables are dense. It gives a "wall of text" effect.

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().

I'm not sure what you mean by dense. If two symbols mean the same thing (both reference the same procedure) but one is longer than the other, then surely the longer one is less dense, no? In physics, density is a measure of mass / volume, so in programming density would be a measure of meaning / code length

`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.

In case of `query` you’d have a uniform API from which all other APIs would flow. That’s what $ essentially is.

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.

This criticism makes no sense. If you always want an Array-like object, just always use querySelectorAll. If you don't then don't. Why is it bad that the DOM gives you a choice instead of giving you a pseudo-array that sometimes acts like an element and sometimes not? The DOM more clearly separates NodeList from Element than JQuery, and that's good! I agree that not having forEach by default was a mistake, but it's long since been solved.

> If you always want an Array-like object, just always use querySelectorAll

`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.

Obviously a poorly designed API is inexcusable, but I don't think the verbosity of function or variable names is the cause of that.

True, it’s the symptom (in many, but not all cases)

Meant as an edit:

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.

It's dense in the sense that there's a lot of text on the screen, and a lot of reading required. All other things being equal, I find it easier to read very short names rather than very long ones, even for code I didn't write myself.

Similar in prose, if you can say it in 5 words, then why use a paragraph?

If you can say it in five words, why say it in five letters? That's the problem with a lot of old Unix/C stuff in particular. Consider atoi. If you're not already steeped in the arcane language of unix beards, how are you meant to divine that it means "a[rray] to i[nteger]"? It's simply unreasonable. By comparison, string->number seems pretty intuitive. (That ascii-art arrow may be straying from the code-as-prose ideal, but I think it's intuitive enough to make up for that.)

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?

I never claimed atoi is a good name or that the least amount of characters is always better. But str_to_int() is better than, say, convert_string_to_integer(), while still being equally clear.

For each their own I suppose, but I think string->number looks nicer than either. Writing str instead of string is like writing ppl instead of people. Some people seem to prefer it (https://hn.algolia.com/?query=ppl&type=comment), but personally I find it almost intolerable.

Interesting naming problem what about EnsureDirectoryTree() or EnsureDirectoryExists()? This name kinda implies that you only care about success and not if it has to create it or not.

You can repo the shortness with a few tiny functions you put in your own library. Probably less than 1k vs all of query.

Also some programmers opt for readabiltiy over terseness.

Maybe it's just me but the terseness is beautiful.

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.

> terseness is beautiful.

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
but to each their own.

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

I hate the "fun" of debugging jQuery. I'd rather have a plain boring easy api.

What's there to debug?


Not every code you deal with is your own.

Besides, terseness is one issue, but far from the only one: https://news.ycombinator.com/item?id=20978608

No need to be rude. A simple, "I disagree, how about..." would have been more civil.

You’re correct. I just don’t see any argument for jQuery that doesn’t boil down to “I don’t want to take the time to learn how the DOM works” at some level, and it makes me mad on the internet.

Why spend time on learning a bad API when there is a nicer one? Ergonomics matter, but hey if you are masochistically inclined, go ahead.

Because there is no other API. The DOM is the API. If you only know jQuery, you're shooting yourself in the foot because you can't do anything more advanced than class swizzling. You have to learn the DOM to use the web well, might as well use it directly instead of through a pair of boxing gloves.

Also, I don't actually find jQuery to be nicer. It wraps its nodes in its own objects, but then you end up getting native DOM elements passed to you up anyway. It's an extremely leaky abstraction to the point that it is not nicer. As I said, if you think "document.querySelector" is a mouthful, just alias it and be done.

"this" is also set by native listeners. IIRC it's the elem the event was added to where as event.target is the element that the event was cause from (often not the same). Example: https://jsfiddle.net/greggman/qpb7ct15/

The biggest irritations for me:

* 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);
off('click')/off('mouseover') sounds like if you click/hover off the dialog box which is incorrect.

The reason they didn't adopt jQuerys API's is because TC39 has a rule to always be backwards compatible. See the flat map/smoosh controversy to get an idea of what I mean. Every decision that gets made by that group is designed to that end. If they adopted jQuery's api's it would break 70%+ of the web. It would be a total shit show to put it lightly. Think about how tangled up and hard to change the average jQuery site is. No, they can't do that.

TC39 has nothing to do with DOM APIs... but you're right that backward compatibility and "don't break the Web" is one of many reasons why this idea would never fly.

> TC39 has nothing to do with DOM APIs

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. :-)

W3C or WHATWG these days. One browser tries something and then another one decides to implement it, and someone writes up a spec.

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.

It’s entirely possible to create a native implementation of jQuery without breaking compatibility with it.

It would be insane not to. I don’t really see your point.

Are you are suggesting that they make a spec that implements API's that would conflict with 70%+ of the web and they deal with those conflicts by adding a `if (window.jQuery) return;` in all those calls? Are you in all seriousness saying that a native spec should account for a library?

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.

>Are you are suggesting that they make a spec that implements API's that would conflict with 70%+ of the web and they deal with those conflicts by adding a `if (window.jQuery) return;` in all those calls?

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.

> make a spec that implements API's that would conflict with 70%+ of the web

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.

I want to be clear here: its totally possible to implement jQuery's api's in the native spec. That's not the part that makes doing so irresponsible and dangerous. Its the fact that (to use a trivial example) `$('.thing-i-want').click(doSomething)` implemented on an existing site would now potentially behave differently when the new spec got released. Worse, it might not break outright and instead cause a bunch of confusing errors that you gotta trace back to the source. Now scale that out to web scale, add it to every jquery version and api out there that conflicts. Think about all the little mom and pop wordpress sites that don't have a staff of developers on hand to scramble and address the litany of bugs that would cascade down upon them. The web would go up in flames.

These things can still be designed and implemented. `element.query().<all the new apis>` for example.

The primary benefit of jQuery was to provide a compatibility layer on top of the bugs, omissions and and inconsistencies in the browsers implementations of the standards. The solution here is for the browsers to iron out these issues, not to provide a brand new API for ding the same things which would probably have the same amount of issues.

Edit: I misinterpreted parent comment, please disregard

The implementation is largely independent of the API. A native jquery implementation could be just as performant as the standard query methods on document.

Perhaps I misunderstood the original comment, seemed like they meant implementing identical APIs to jQuery, I thought they meant simply writing an abstraction in JS (I.e. not a native impl). That’s my bad

... and plenty of developers prefer using its API even when native methods are available.

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.

There is more to it than "wanting to learn".

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.

> 30kb is completely insignificant.

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.

A fetch polyfill can be added to a project for ~500 bytes[1] vs jQuery which is ~30kB [2] - or if you were to import just the ajax element from jQuery it would be 13kB [3]

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...

Just for comparison, the "favicon" for Hacker News is 7.66 KB.

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.

See https://v8.dev/blog/cost-of-javascript-2019

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.

So what is the parse and execution time for jQuery on a low-end device? Genuine question, I have no idea.

I agree there are often more important performance issues on sites, especially with images, but that doesn't mean we should completely ignore javascript bundle sizes.

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.

You should optimize images as well as removing unnecessary JS libraries.

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.)

Since the jQuery API is more concise than the standard API, you probably save bytes anyway. And if you use a CDN, jQuery will likely already be cached, so it will perform a lot better than writing your own code to present a similar abstraction layer.

Tbh, I still prefer a "classic" no-bullshit website that depends on jQuery just because the dev likes it a thousand times over the modern overloaded "just-because" SPA that depends on five dozen Js frameworks that were hip the day that page was created.


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 whole “so many Js frameworks!” thing is ridiculous. The same dominant frameworks have been popular for _years_ now, and while new frameworks do pop up people mostly use these same dominant frameworks, and these dominant frameworks are incredibly _samey_, relying on reactive data concepts, components, and a Fluxlike data store pattern for more complex apps. Going from React to Vue or even to modern Angular is really not a huge context switch anymore.

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

"The Js framework ecosystem is incredibly easy to work with in 2019"

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

To be clear I’m talking about the ecosystem of front end frameworks ala React, Vue, Angular not the Js ecosystem as a whole.

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.


That might be false economy. Most images in a page would come above 30kb. I've seen 3rd party widgets for chat and support sometimes bundle their own copy of the React framework, not to mention huge chunks of CSS, most of which are unused.

If you're putting jQuery in your main application bundle then it has to be parsed and executed before you can do anything. That's not the same as an equivalent sized image which just needs to be decoded and painted. If it's a chat widget hopefully you're loading it separately. I agree that CSS can also be a problem.

Pretty sure serverside rendered html works just fine before JavaScript is parsed and executed..

Very few people are replacing JQuery with super lite pure native JS implementations, it is getting replaced other libraries like React which is a wash, at best, for users.

Maybe jQuery should be simply included in browsers.

What is jQuery though? From the author's standpoint, it was a library built to smooth out the edges of bad browser support. This is a problem that doesn't exist as much these days. If you're looking for a way to select one or more DOM nodes and manipulate or jack content into it/them, browsers already provide an easy way to do that now days. The other abstractions it provides ($.get/$.getJson, $.each) have no reason to exist anymore. What's worse, the entire promise-like ability in jQuery is incorrect. (but has to be maintained for backward compatibility)

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!

Agreed. I've seen numerous times developers include jquery just to make a simple request that can be replaced by XMLHttpRequest.

Ref: http://youmightnotneedjquery.com

What strikes me with this youmightnotneedjquery is that half of the examples take many more lines of code than a single jquery instruction.

Especially when it comes to browser support...why would I not use JQuery in those cases?

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.

That site looks more like an secret advert for jQuery than any attempt to remove it.

Maybe a comparison using more modern browsers would be more convincing...

A friend of mine created a spoof to make exactly this point: https://youmightneedjquery.com/

Even the information on that page is quite dated now, as IE becomes less relevant. As others have said, some of its examples were ironically pretty good adverts for jQuery at the time it was first published.

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.

the uglyness of document.Selector is something that never gets discussed.

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.

So do you put 'Content Type' and all that other stuff on every fetch call over and over again?

I still like to bind $ to querySelector and $$ to querySelectorAll:

    $  = document.querySelector   .bind(document);
    $$ = document.querySelectorAll.bind(document);

Everyone's got their little snippet but here's my 15-liner that gives you $() and .on() syntax:

    $('p').on('click', el => /* ... */)

Counterpoint. “Why I'm still using jQuery in 2019”, https://arp242.net/jquery.html

jquery is less verbose than native ES6+ js functions, I'm not a frontend developer myself, my understanding is react/vue/etc are for SPAs where you manage lots of states inside the browser locally instead of on the server side, but majority web-related UI actually does not need that ecosystem/complexity at all, a bootstrap+jquery can still serve majority of use cases in my opinion.

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.

Nostalgia When jQuery used to be thing everyone used and wanted to learn.

I get laughed at by typescript devs for using it, I feel jQuery will stand the test of time than these frameworks. However wasm will have the last laugh

babel solves the problem of polyfills in a more elegant manner.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact