But in fact, jQuery is largely not needed since Internet Explorer lost market share and there's less of a need to have lots of workarounds for it.
I would massively prefer to have a blank page, or a page with no buttons, and wait a few seconds for the buttons to appear in their final locations, than this.
I find most sites using this kind of progressive loading are completely useless during the loading phase... What's the point of showing the user a page full of skeleton/loading placeholders? You might as well have just server-rendered the whole thing and made the user wait an extra second or two.
The idea being the browser would know how to render the things around the picture without needing to download the picture first, preventing the page from jumping around as the quicker and lighter HTML was downloaded and rendered first.
That "jumping around" is now referred to as "CLS" -- Cumulative Layout Shift -- one of the "Core Web Vitals" metrics used to quantify performance-related UX.
elem = jquery.clone() ... elem.slideDown()
And this renders bits of the page moving them as it does it; slideDown() is in jquery core. It used to be popular before that biz of rendering grey squares first got invented
You can document.write() in js by default so it has to wait for the js to load.
"async" tag stops the default behaviour but the person writing the blog does not sem to know what.
As someone who's late to the webdev party I feel that jQuery is pretty awesome (all I ever heard is people poopoo it). The vanilla API for the DOM manipulation is just plainly awful and borderline nonsensical so I'd say jQuery is still very much needed.
What was not amazing was the manner in which many projects utilized them.
jQuery lets one use an innerHTML-ish style, but it is supposedly guarding against injection attacks in some way. I don't like the hand-wavy way it claims to guard against injections, as basically it has no way to tell what part of a string was meant to be text, and what was meant to be elements.
So I ended up coding my own library. No conversion of strings to elements, so naturally no injections. Very small and simple. But saves a ton of typing when generating DOM structures in JavaScript: https://github.com/NoHatCoder/DOM_Maker
Though if jQuery works for you and isn't a performance issue, then by all means keep with it. It may not be ideal, but good enough and does the job. Let the naysayers spend their time debating whether you should or not, and just get on with making things!
---
[1] selection engine, chained selections, chained modifications, …
[2] not the issue it once was, if you can abandon IE and old Android browsers from your supported UAs or can deal with any issues that crop up individually
[3] again, if you can afford to drop support for legacy UAs
With Jquery it seems the balance of writing code to make page active, and not writing too much code, is correct.
I guess I prefer reading code than docs.
Quite a few of the mini-jQuery libraries, like the ones I linked to, are doing just that and allowing the sort of DOM manipulation it does but without all the other stuff.