jQuery 4.0.0 Released
67 points by outervale
67 points by outervale
Hell yeah
One of my favourite quotes at work (we use React) lately seems to be "why is this so complicated, this would be 5 lines of jQuery".
I kinda miss the times where you just sprinkled some jQuery and it worked, but I'm not deep enough into the JS world (luckily) to be able to judge who will benefit from this, I have replaced my (private) use of jQuery and zepto with (also usually 5 lines) vanilla js years ago.
It looks like IE wasn't dropped so as to not delay the 4.0 release. Since they follow semvar, that means it won't get the axe until 5.0.
Pretty wild considering that 3.0 was released 10 years ago. Hopefully they they will scope this one better: they were talking about getting 4.0 released in 2020 back in 2019!
Ironically, the only browser to ever follow the old W3C spec (before it was updated in 2023) was Internet Explorer.
IE followed plenty of specs that have been redefined out from under them, and in a lot of these cases where the browsers differed, IE's way was better. Remember before css box-sixing? IE did border-box. The others (including the w3c spec at the time) mandated content-box. How many of us do * { box-sizing: border-box;} nowadays, opting into IE's behavior?
Anyway, let's take this one jquery mentioned, for example, focusout vs blur.
In the old spec, the one IE followed, they were defined:
A user agent MUST dispatch this [focusout] event when an event target is about to lose focus. This event type MUST be dispatched before the element loses focus. The event target MUST be the element which is about to lose focus. This event type is similar to blur, but is dispatched before focus is shifted, and does bubble.
A user agent MUST dispatch this [blur] event when an event target loses focus. The focus MUST be taken from the element before the dispatch of this event type. This event type is similar to focusout, but is dispatched after focus is shifted, and does not bubble.
https://www.w3.org/TR/2022/WD-uievents-20220601/#blur
Whereas the new spec, which was just modified to bring other browsers into conformance, defines them:
A user agent MUST dispatch this [focusout] event when an event target loses focus. The event target MUST be the element which lost focus. The blur event MUST fire before the dispatch of this event type. This event type is similar to blur, but does bubble.
A user agent MUST dispatch this event when an event target loses focus. The focus MUST be taken from the element before the dispatch of this event type. This event type is similar to focusout, but does not bubble.
https://www.w3.org/TR/uievents/#event-type-focusout
In the old spec, they actually enabled potentially different behavior: focusout gave you a last-moment chance to use the focus before losing it. tbh I can't think of a good example of what you'd do with it at the moment, but that doesn't mean there isn't one. Windows' WM_KILLFOCUS event also runs immediately before you lose it, and the documentation suggests cleaning up some resources here, but you could do that right after losing it too, so idk. (Many of IE's ways were just copying what Windows provided, and if you look at Netscape+Firefox, many of them are eerily similar to how X11 works. Both browser vendors mostly just forwarded their OS events to the web.) Anyway, the point isn't the limit of my imagination at the moment, the point is just that they did different things.
Under the new spec, blur is completely redundant. The only difference is if the event bubbles or not, and handling this in user code is trivial: check if(event.target != this) and you know it is bubbling, so this doesn't enable anything new. And since it is still running both events, it doesn't enable any real performance changes either.
So I get why they'd do this - if you can't think of a specific use case, and since most the existing marketshare* never implemented the functionality to begin with, axing it is a fair consideration. And just plain removing one event or the other is more likely to cause breakage than making them almost synonyms. But still, the difference here is a bit more than just order of execution; there's potentially some loss of functionality. Oh well, it is what it is regardless.
Haven’t heard that name in a long time. I don’t do much web development anymore, but I wonder, is jQuery still necessary with all the improvements JS and it’s ecosystem got in the last 20 years? Isn’t most of its functionality built in nowadays?
It was never "necessary" but provided a utility toolbelt.
It used to be absolutely necessary to use jQuery or one of its competitors for papering over the differences between IE and all the standards compliant web browsers. In the 2000s, if you were doing DHTML, you were either using some library to unify the interfaces for things like attachEvent vs addEventListener... or you were copy pasting MSIE compatibility shims in everywhere, which amounts to doing the same thing manually.
Of course it never strictly was, but writing something non-trivial like 15 years ago without it was torture.
A lot of it is, and there's much less need for a single API to compensate for difference between browsers now. That said, it's still very widely used, though more in the "web design" space than the "web development" space.
Wow, still supporting IE11. What enterprises are still on IE11? I know they exist, but I guess I am just really impressed. Probably some banks and governments I suppose.
There was some discussion at some point about there being certain regions where usage was still over 1%. There is also IE compatibility mode in Edge, so demand is hard to estimate.
However, the main motivator was preventing scope creep and getting the release out (see my sibling comment).