I loved jQuery, and still do (2019)
withblue.ink
withblue.ink
For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`? Natively cloning a node is `el.cloneNode(true)`, so now I have to remember what `true` is for and whether I want it or not (surprise: the default changed between JS versions, so the "optional" argument must always be included for compatibility!). Probably the most commonly used line in web JS in jQuery is the terse `$('selector')` but natively is the mouthful of `document.querySelectorAll('selector')`.
So while jQuery isn't strictly necessary, it's certainly a nice syntactic sugar, and IMHO a more sane and consistently-designed API than native. It's a great choice for developers who want avoid big frameworks like Vue and get as close to plain HTML/JS as possible, but still want a pleasant JS development experience.
I found that while jQuery offers some nice synthetic sugar, it's mostly geared towards web frontend and actual logic continue to have to reside in native. I'd rather just know one thing (but I'm a backend programmer that only does js/ts for fun, so there's that).
Actually, .children is the child elements; .childNodes is all the children (including comments and text as well as elements).
> Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`?
I’m not sure why they want with .classList instead of .classes, but I expect .className is a part of the history. If redesigning it from scratch and still retaining the functionality of .children, I’d rename it .childElements. Certainly not .childList.
And of course, the reasons for most of this stuff is the history. Some of the web’s APIs have aged well; others haven’t.
I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find it's too easy to re-use a word in different context, especially if it's different people doing the coding vs CSS.
Of course if that’s a need the page needs work but, not everything is “fixable” in time limited business cases.
document.querySelectorAll("[data-my-attr=something]")
document.querySelectorAll(".foo > [data-my-attr=something]")
etc.
Since the ViewModel binds the variables to the controls, hundreds of lines of jQuery required to update controls literally vanishes. It blew my mind once I understood what reactivity meant in real life. I rewrote a fairly large site in Vue and the JS LOC shrank by nearly two orders of magnitude (of course, a lot of that was due to the previous webdevs problems).
Now that I'm used to Vue, I view jQuery more like a skin disease, some kind of rash that makes everything ugly and swollen.
(Although I reach for the "cash" library instead of this or jQuery when I need something jQuery like)
I look at that site and laugh. Is this supposed to be making the case ~against~ jQuery? Maybe the audience for that site are seasoned developers for whom the vanilla JS syntax is easily understood. Everybody else is going to look at those code snippets and think jQ is the way to go.
For people that have struggled through HTML and CSS, there is perhaps nothing more deflating than to realize that even basic UI interactivity requires JS. But with jQuery the code snippets needed are short and understandable. Vanilla JS in comparison looks like an entirely different language.
In a corporate environment, if "I need to include jQuery as a dependency" involves asking another team how to set up custom deployment or whatever, and that is the difference of days between deploying a feature or not, then I'll definitely take the hit of 10 more SLoC vanilla JS.
Not every site out there is an database-driven SPA that needs QA review and a deployment pipeline each time an update is made. Lots of sites are just simple WordPress or even raw HTML pages that need a little bit of a facelift, with animations or transition. jQuery does the trick, and as a bonus, it's a much gateway drug to JS than the official ES6 documentation could ever be.
Proceeds to download 30kb (compressed) swiss army knife of a library when just a toothpick would do.
jQuery is about as much of a gateway to ES6 as pot is to heroin. Devs who still use jQuery have had 10+ years to learn `document/element.querySelectorAll()`. Longer for event listeners.
> Devs who still use jQuery have had 10+ years to learn
Or possibly we learned it in 9 years 11 months ago and still think jQuery was a more elegant solution.
I agree that 30kb can be big, especially since it's JS that needs to be executed, but on the other hand if the toothpick means you save a minute, you can use it to optimize an image and end up with a lighter and faster website.
I recently removed jQuery from a website, and the YMNNJQ website was one of the bits of info that gave me the nudge to do that. The website in question only used jQuery in a handful of places, it was one of the few third party libraries being used (so the % size savings was significant), and I'm fairly fluent with JS... The website simply hadn't gone through a major update in the past 5 or 6 years, and the browser landscape has shifted enough in that time that the pros/cons weigh differently now.
So I think there are scenarios where this info is sometimes useful in the "I might remove jQuery" sense, and not in the "wow, I'm definitely keeping jQuery!" sense.
My original comment left out some context: on HN, a lot of the hostility to jQuery is either cultural or gatekeeping oriented. Cultural opposition is of the 'not invented here' variety, e.g. 'Why use Dropbox when you could do this w/ rsync? Gatekeeping-related opposition is where it's implied that you shouldn't call yourself a dev if you use jQuery and not vanilla JS.
That is the kind of discussion that happens nearly every time a link to YMNNJQ is dropped.
jQuery promotes bad development patterns, AND brings a cost for end users. Developers will do themselves and futures devs a favor by not choosing to use it. Is it really gatekeeping to expect people to be aware of commonly used 10 year old features?
I assume developers who share YMNNJQ are just sick of inheriting messy projects built with jQuery. I know I am.
Part of my screening process is making sure something like that doesn't fall in my lap again. Even static sites aren't safe these days.
If you do web development as a job, it's your responsibility to stay up to date on what best practices are. With EC2015 being several years ago now, jQuery wouldn't be a learner's starting point today.
Those that developed bad habits during jQuery's heyday a decade ago may still be writing bad code. And it's someone else's job to clean that up. That's the circle of life, and it's hardly exclusive to jQuery users.
I've never seen that. The closest I've come to seeing that is that comments that imply that using jQuery indicates lower levels of experience as a developer.
> Cultural opposition is of the 'not invented here' variety, e.g. 'Why use Dropbox when you could do this w/ rsync?
How is that "not invented here"? That seems more like a preference for open source software.
I looked at submission history and I don't really see either of those attitudes prevalent in a quick scan of the comments:
https://news.ycombinator.com/from?site=youmightnotneedjquery...
Some use a bad technique; e.g. “Empty” removes the first child repeatedly, which is O(n²) in many environments, rather than removing the last child repeatedly, which is O(n), or `el.innerHTML = ""` which is shorter and more efficient in general)
Some suffer because they’re supporting IE which no one should do any more (fite me); e.g. “JSON” is long because it’s using XMLHttpRequest, but the Fetch API would make it vastly shorter (`data = await (await fetch('/my/url')).json()`—as an aside, suffix await like Rust settled on is so much nicer: `data = fetch('/my/url').await.json().await`); and “Each” should use `document.querySelectorAll(selector).forEach((el, i) => …)`; and “Matches Selector” is just `el.matches('.my-class')` now.
Also some look bad because jQuery optimised an operation that isn’t terribly common or should generally not be done, such as most of the width/height things (most uses of measuring element dimensions in JS are unnecessary, bad or wrong; aim to use CSS most of the time), “Index” (needing to know that an element is the nth child element is decidedly esoteric), “Type” (if you use this, you’re almost certainly doing the wrong thing), and “Parse HTML” (picture me running away, screaming in horror; this method is practically a primed security grenade). And remember, jQuery having optimised these things means you’re paying to ship that stuff that you’re not using.
And finally some seem more complex because they’re matching some unnecessary jQuery complexity, e.g. in “Set Height” (and alike in “Set Width”), $(el).height(…) takes a string, a number, or a function that returns a string or a number—but you’d be wiser to write `el.style.height = string;` or `el.style.height = number + 'px';` rather than being unnecessarily flexible.
Most people that use jQuery use a tiny subset of its functionality. The site is about showing that most uses of jQuery could actually dispense with it at little cost, if they’re the sort that value performance and such and want to ship less unnecessary code.
const data = await fetch('/my/url').then(r => r.json());
Mind that in this example the then is a little nicer only by chance that the continuation is quite trivial. If you'd need something more complex than the single function call it is annoying and if you do any later change to this code, you likely have to change this as well.
I typically go to the multiple lines, but wanted to show that there is a kind-off suffix await.
I am not used to suffix await, as i like to spot the places where i jump out of the coroutine easily. But maybe that would change if I'd use languages with suffix await more :)
In the past, I believe that most or all browser implementations used array-like structures to do various things like this, and so removing the first element entailed shifting all the remaining elements, whereas popping from the end doesn’t require shifting any elements.
More recently, I believe that most or all browser implementations have shifted to linked-list-like structures, with bad patterns like this being a cited reason. (I don’t know the full story by any means, but I’m inclined to be disappointed by the switch, because for most access patterns arrays aren’t a problem at all, and use less memory, sometimes even being a smidgeon faster. But although I suspect they’d have better typical performance and certainly better memory size, they have vastly worse worst-case performance, being approximately O(n) instead of O(1) for some operations.)
Remember also when talking of NodeList like this that it’s a type for JavaScript to consume; what browsers use internally for representing their DOM is an implementation detail. A leaky one, certainly, in performance details like this and types like HTMLCollection and NodeList (especially live NodeLists), but an implementation detail nonetheless.
Starting with the Ajax exmaple isn't the best way to get people on board, either. Until the Fetch API was widely adopted, I also reached for a library if I had more than one very simple API call.
It's supposed to be making a case against jQuery if you're pulling in the whole library just to do this one thing.
I've always read the site as "here's how to do it in native JS, yes it's uglier, but if you only need this, you can skip pulling in another dependency."
Over-engineering websites has been around forever. That's partially why jQuery is modular, letting you pick what you need.This covers the 'use jquery for just this one thing' crowd. And if they're lazy, well, they can hang their heads in shame because they have added an entire 83 KB to the page's initial load time. /s
(unless the browser has a CDN cache stored, in which case it wouldn't impact load time at all)
I write random bits of scripts for internal use, I'm happy enough to drop the min.js in with my index.js, index.css and index.php files, especially if it means I can continue to use
getJSON('/my/url', function(data) {
});
var request = new XMLHttpRequest();
request.open('GET', '/my/url', true);
request.onload = function() {
if (this.status >= 200 && this.status < 400) {
// Success!
var data = JSON.parse(this.response);
} else {
// We reached our target server, but it returned an error
}
};
request.onerror = function() {
// There was a connection error of some sort
};
request.send();
I've just looked at one page I wrote which has a little jquery in it. The outputted data is 673kb, which takes nearly half a second to generate and load. The jquery file being static is down in 0.01s.
This isn't a problem
I can just drop in the library onto any existing webpage, and have almost complete control of the DOM with just a few lines of code. And the built in actions and animations are all so simple and perfect for the web. And the structure and naming is so good that I rarely need to look up any references anymore.
I get that browser support isn't as important as it used to be, but it is nice to know that you can just use an effect in jQuery and it will just work exactly as you expect it.
> $("#button").on('click', function(){ > $(".modal").slideUp(); > });
Obviously a simple example, but this is really easy to understand - even for a non-programmer! The equivalent vanilla JS to do this is honestly pretty nasty in comparison.
The only problems I have seen when maintaining jQuery is when someone wants to drop in a bunch of custom functions they have designed in vanilla JS - or try to treat it as a replacement for a front-end framework.
But for it's intended purpose of adding interactivity into HTML content, I think it is still the king.
I know React enforces some better practices that my spaghetti-jQuery of yore never followed, and that I was getting a crash course in those practices at the same time, but I was nonetheless surprised at just how slow I felt working in it! It gave me a new appreciation of just how accessible jQuery is, and how intuitive its concepts are to someone without a background in software development, perhaps for better or worse.
Obviously this is a bit of an apples-to-oranges comparison, given the intended uses of the two frameworks, but for simple projects, it's hard to imagine a better balance of accessibility and flexibility than jQuery.
I manage my wife's electronic store that's based on WordPress, and I see absolutely no reason for ever changing it. I've written a bunch of custom scripts, all in PHP back-end and jquery front-end, and... It just works. And it's fast. And complexity is totally manageable.
But, I've also written a few SPAs for her business deployed as PWAs, and I can't even begin to think about how it would look like if I was using jquery for these tasks. React (or Vue or whatever) is an escape hatch from going insane in such situations.
Our marketing site is in Wordpress.
I daydream about making a framework that lets me use django templates as a SPA that does server side rendering on the first request, or when javascript is unavailable.
This is a drawback unless you truly need an API. YAGNI.
I've found a hybrid approach works well. Your site is mostly server side, but some individual pages have Vue and an API endpoint or two. If that mobile app or that third-party integration becomes a need, add endpoints for that particular use case.
I've gone the other route and prematurely optimized for the "what ifs" first, and it's painful when they don't happen and you're left holding all that complexity.
The fundamental issue is that it binds the server to the client, who must understand HTML structure. It also makes it more difficult to reuse the endpoints in different ways or for new applications.
Returning data and letting the client render it decreases coupling and increases flexibility/testability- you can run unit tests on the client for mock data, and run unit tests on the server to test the desire
whatever frontend framework you're using has really nothing to do with it at all.
The people here saying they still use it have so far demonstrated what I always say. If you're using jQuery, it's time to go back and relearn javascript. Most people should REALLY research the querySelector and querySelectorAll DOM methods.
I've always felt that jQuery encourages you to let your skills stagnate and you don't learn what your code is actually doing. Learn what the current spec has to offer. You don't need another dep just to target dom nodes ffs.
But for existing projects that still work well and for which there is no reason or gain from updating the code and, for which, time and money would be spent for what is really a lateral move, I think it's fine to leave it as is.
And there are many projects like this where the JavaScript barely changes, jQuery is holding it in place and nicely and there's hardly any technical debt. There's no incentive to spend the money and time. Making a developer feel better is not really worth it in these situations unless they'd like to work for free.
I build (barely) working websites with jquery and html and css though, having the "this is the one way jquery would do this and ignore all that other crap" value is high to me for that very reason - I work mostly on databases and having to learn the current spec every 2 years or whatever you web sickos are doing suuuuuuucks.
I've roughly as fluent in vanilla as I was in jQuery and I still think jQuery was a nicer, more elegant, more humane API to the DOM.
Query selectors are like slow motion drowning in syrup. They are so astonishingly slow. They are also limited in what they can do.
Just learn the DOM. It can be learned in a single afternoon but for some reason people will fight you to death on this and then stake their careers on it like a heroic battle that nobody cares about.
I really learned to appreciate jquerys clean codebase at that time. Learned a lot about the DOM and how to misuse it.
Yeah, we've all seen spaghetti code monstrosities that involve lots of jQuery, but it's just a library, it can't be blamed for people not knowing how to structure their code.
This is why I appreciate Svelte's take: with a compiler-heavy approach, you can have a great dev experience without saddling your users with extra dependencies.
That's not the dilemma though. Developer can build solutions without jQuery. They'll be faster, smaller, and have fewer dependencies.
Plus, if you're only using jQuery for DOM and events then it probably isn't helping you. Those are two areas where writing vanilla JS is can often be easier than writing the jQuery code to do the same job.
jQuery versus [framework of the month] is "faster, smaller, and [has] fewer dependencies". Simpler build, too, while still keeping you from having to worry about which browser supports what.
Depends on what the most likely alternative is, then.
A fair point, but compared to the payload of most sites (let alone apps) these days that is chicken feed.
Just opened that page itself and DevTools tells me 5.2Mb was transferred including ~175KB of JS from twitter, 65Kb JS for the video player (which seems to have 46Kb worth of css associated with it!), ~1Mb worth of font resource, ...
> so that you don't need to learn about 5 standardized browser API methods
That and the way jQuery does method chaining, which a lot of people find far more convenient, but other features. jQuery does a lot more than querySelector/querySelectorAll/friends.
> No doubt that gives you a better developer experience*
<attenborough>And here we see a forum commenter in its natural habitat, hunting the point. It sidles up slowly, and pounces...</attenborough>
(with apologies for failing to resist being facetious and slightly dickish there)
>* but I don't think your users are thanking you.*
I don't think most users will notice. Those that do due to slow connections, metered connections, low-power/low-memory devices, etc, are going to baulk at much more before even noticing jQuery on this site.
On something like HN (23.8K transferred for this page before my comment was added) 30Kb might look chunky, but few sites are remotely close to being as lean as HN.
No apology necessary. That was funny. Because it's true. :)
Requests have gotten better with "fetch", but unfortunately, the "modern" DOM API is quite bad in some parts, making lots of stuff unnecessarily verbose. On top of that, it's really odd that the DOM API is not compatible with for-of loops, which could have been a selling point.
I'm not sure what you mean by that? querySelectorAll returns an iterable. Also, your link is outdated. It doesn't include the fetch API which has enjoyed wide support for quite a while now.
Apparently my knowledge is outdated. Last time I tried to switch from jQuery to vanilla JS, the results of document.getElementsByTagName and others were not iterable with for-of.
$(".elements").css("color", "red")
versus
var selector = document.getElementsByClassName('elements');
selector.style.color = 'red';
const $ = document.querySelector;
$('.elements').style.color = 'red';
Which is only marginally more verbose.
You can however do:
document.querySelectorAll('a').forEach(a => a.style.color = 'red')
const $ = document.querySelector.bind(document);
const $ = function(x) { return document.querySelector(x) };
const $ = (x) => document.querySelector(x);
> document.getElementsByClassName('comment').style
> undefined
You'd need a for loop right there I believe.
Best being
$("#id") replacing document.getElementById("id");
Makes code look cleaner
Does the same as the $ query but native in every browser in IE9+ and gives you a native node. Also more performant than getElementBy<whatever> methods.
jQuery is elegant, concise, and was designed by a genius. The "modern" methods are ugly, verbose, and were designed by a committee.
function $(arg) {
if (arg.charAt(0) == "#") {
// HTML spec does not support ids to start with numbers [0]
// (you may not need this conditional on your website)
return document.getElementById(arg.slice(1))
}
return document.querySelector(arg)
}
$('#27677234')
You could just extend the function to detect '.' vs '#', and do a class selection as well. And then add all of the selectors, subselectors, etc. (similar to, but far more powerful than css3's selectors.) and if you go far enough, you reinvented zepto (but still a long way from jQuery)
(actually, since $ is basically synonymous with jQuery, it'd probably be better to choose a different function name. too bad you can't define it as #(id).)
Yes. For a high degree of jquery-compatibility, you can use my library.
const $ = document.querySelectorAll.bind(document);The problem is jQuery has no business being used today unless you have to maintain legacy code. Even then I would deprecate jQuery wherever possible. Using jQuery for a "quick and dirty" application today is just terrible and it sends the message to green devs that jQuery code slinging is a skill worth having.
If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel. You will get all the advantages of Babel and Polyfills (if you need them) with little to no effort.
jQuery has no value except for maintaining legacy code. jQuery was useful back in the day (and John Resig had the best solution), but I don't love it anymore. In fact, I have serious judgements of the devs that use it that should know better.
Edit: I should note that jQuery is bad because it has no state management and you cannot easily track side-effects. I would much rather see someone use something like Svelte and construct the functionality with modern best practices while keeping a very small footprint.
There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.
If you have a use case as simple as the author is advocating, this only take about 15 minutes to grok. If it takes longer then you probably don't have enough front-end experience to productively contribute to this conversation. That is a little harsh, but the FUD in the JS world is incredible, mainly by people that have very little experience and understanding.
You also don't need to include packages that are poorly engineered and maintained. For what you do decide to use, you are getting visibility into the warts that you may have blissfully ignored in the past.
The issues you are describing are not really problems anymore unless you let your app get woefully out of date. The web and browsers are a moving target, so it's critical that you minimize running legacy code wherever possible. Npm/Yarn and Webpack is a huge step in making that manageable. jQuery has been on autopilot for years because it has limited usefulness. We've collectively moved on except for a few holdouts.
Sincere no-snark question from someone who's been out of the frontend game for a while: Why do I need Node in order to do "quick and dirty" frontend development?
(FTR I'm with you that jQuery is silly these days. Today's built-in web APIs do pretty much everything jQuery ever did.)
Because using current JS standards while moving the vast majority of the “make it work across a moving-target set of browsers” concerns to build toolchain configuration settings is a simplification from either explicitly managing all the compatibility issues and/or restricting to least-common-denominator JS features. Yes, build toolchains are themselves a source of complexity, but in net they can be a simplification.
When you just sling jQuery on a page and try to use spread syntax or async/await, shit's gonna break.
(Thank you for your patience with this backend dev who finds your whole world very confusing.)
JS is interpreted by the browser, but we compile locally so that the code produced implements workarounds for missing language features. The code produced is typically minified so that the payload sent to the browser is much smaller than it would otherwise be.
Node is analogous to Python, Ruby and PHP... they all can run webservices, power desktop apps and compile/build projects.
python -m http.server my_cool_cli_thing
Thanks again.
Node js and the the package manager are inextricably tied together. Node js provides a local js runtime environment for the e.g. dev time packages to execute. It's also the api for interacting with the filesystem. Somewhere down there, yes, Node js is a web server, but it's kind of 'the' javascript execution environment for building local packages ("plugins"?) against.
The whole ecosystem is built up on javascript. If you're running grunt or gulp or webpack, it's all javascript. When you install packages globally they're put in a global folder. There are exceptions (I'm looking at you Cypress) that have native assemblies instead of js, but by and large there it's js, and it's stored locally. There are some pretty simple conventions (e.g. the 'node_modules' folder and the hidden '.bin' folder inside that) When running npm it feels like passing a one-liner javascript command into node's javascript repl/environment. The .bin commands are ambiently available.
It makes a lot of sense how it's grown organically... why there haven't been efforts to separate the constituent parts... I don't know. At some point maintaining the 'working thing' with <large degree of> complexity is easier than following a more rigorous, provable set of tools. I think it's a culture thing. Probably the same reason most of the problems are fixed by deleting node_modules and re running `npm i`
Addititionally, jQuery loads on the first request and sits in local cache thereafter. And it could already be in local cache if you use a CDN.
There is probably no reason today to use Prototype.js, however, jQuery still is a better choice than React/Angular/Vue for small projects if the author prefers some syntactic sugar over plain DOM.
I was not expecting this to surface out of the blue 2 years later, so I had to go back and re-read what I wrote
I still stand behind what I wrote for the most part. If what you are looking for is not building a full SPA and you need compatibility with most browsers, for most users, then jQuery is still a very solid alternative.
A few things have changed however since then:
- As others have pointed out in the comments, a larger chunk of the Web has moved to SPAs, sometimes just because they wanted to build on the back-end something API-driven that can be reused for other scenarios (like mobile apps). The amount of apps that follow the more "traditional" model of server-side generation and then use JavaScript just to "augment" that experience is much smaller, but there's still a lot of use for them if you want to build something quick-and-dirty, like an internal app for your business. - Browsers are now implementing [cache partitioning](https://developers.google.com/web/updates/2020/10/http-cache...) which means that jQuery must now be re-downloaded by every website. It's still a rather small library, and compared with most modern apps the impact is negligible (average web page size is now [1900-2100KB](https://httparchive.org/reports/state-of-the-web#bytesTotal)). But this has negated one of the benefits of jQuery, the ability to serve it from a CDN that then is reused by other websites.
For a SPA, I would go 100% with Svelte as my first choice (but you may say I'm biased), but other frameworks are good too especially if you need to leverage existing skills on your team.
Thanks for the addition insights anyways
If I had a choice, I'd go with one of the reactive libraries, I've used Vue. For me, if you're relying on Javascript IMO it gets the job done quicker.
It'd be interesting to see what jquery is used for in aggregation of all its usage. For me it was always selecting element(s) and XHR requests. With fetch (and a polyfill for IE), and the likes of querySelector it seems that a lot of the problems jquery solved have also been solved by the majority of popular browsers.
I say that as a layman of client side dev, happy to be corrected.
I am awaiting my fetches with async functions in place of $.ajax with MDN pages in the next tab. Don't see how replacing one library of JQuery with another library like Vue/React/etc is any better. A crutch is a crutch by any other name.
They're not so comparable TBH, the reactive element is the key difference. I can simply create logic, apply changes to the input data and the UI is updated. With jQuery you have to update the UI and data, far less easy. Point I was making is that if you're site relies on JS, I'd pick a reactive framework to do the heavy lifting.
I find jQuery and Bootstrap great for fast prototyping. The thing I love about jQuery is the cross-browser compatibility. I know things have improved but I have very little faith in native JS "just working" as I would expect on all browsers.
But of course it was not designed for building reactive apps and so should not be used for that. It's nice just for fast-and-dirty UI interactions and animations.
Now that these browsers are no longer relevant and support has been removed from jQuery, what is the performance hit, if any for using jQuery as opposed to vanilla JS?
I agree with many, I find the jQuery syntax to often be better than the alternative.
'Rich Internet Applications' were not the same thing as web 2.0 sites. Rather, they were a precursor to modern concepts like Electron and webview2.
OWA and Ajax appeared 6 years earlier. Why would Gmail be considered the milestone instead?
It seems a valid milestone, if not the first example.
It was a great library for what it did and it holds up a lot of sites still.
Oh and BTW it pairs really well with StimulusJS. I've used it thoroughly and it's been a godsend