I think the reason is that many of the problems JQuery was designed to solve (DOM manipulation, cross-browser compatibility issues, AJAX, cool effects) have now been implemented as standards, either in Javascript or CSS and many developers consider the 55k minified download not worth it.
The general argument now is that 95%+ of jQuery is now native in browsers (with arguably the remaining 5% being odd overly backward compatible quirks worth ignoring), so adding a JS dependency for them is "silly" and/or a waste of bandwidth.
Obviously, if jQuery is still your jam in 2019, that's your decision and no one is going to force you to stop using it. The approach Bootstrap is taking is interestingly backwards compatible in that the updated plugins will still register their previous jQuery APIs, even if their actual implementations will now be "vanilla" JS directly against the modern browser APIs.
I think jQuery is a good option if you're making "rich applications"; that is, normal HTML pages with some JavaScript for better UX. For many applications this is still a good approach.
If you're making an SPA, then jQuery is a bad choice for many reasons. jQuery is just a DOM wrapper, and doesn't give you any application structure, which tends to lead to pretty messy applications.
I believe Vue.js is much better option for this use case (just enhancing UX on an existing HTML page), and is similar in size while giving you much more flexibility.
I only looked at VueJS for about an hour, but it's my impression that Vue.js is much more of an application framework for SPAs than "rich HTML"? Quickly looking at the "getting started" guide doesn't give me the impression that it will work well if JavaScript is disabled?
What I want is just intercept some (but not all) form submissions and load the results via AJAX, and such.
You can just use DOM templates with Vue.js. Basically write your HTML the way you normally would and add the Vue.js attributes that tells Vue what to bind with. If JavaScript is disabled you just have plain HTML. It does scale up to doing a full SPA with single file components and compiled templates with Webpack.
jQuery is fine for spicing up a blog or something with really basic JavaScript functionality (e.g. a carousel, basic 'contact' form with validation/AJAX).
Anything more 'rich' gets confusing very, very quickly and with how accessible Vue/React/Angular are it doesn't make sense to use jQuery.
Not a total expert, but as a fan of JQuery I've read the arguments.
JQuery modifies the DOM at runtime, this means lots of node traversals and redrawings on the fly, which make it nearly impossible for the Javascript engine to optimize anything.
More modern frameworks in general use the concept of a Shadow DOM: they keep their own representation of the DOM internally and only send the full frame to the engine for rendering. It seems to be extremely more efficient and flexible.
I think you may be confusing Shadow DOM with Virtual DOM. Shadow DOM is more about encapsulation and isolation of independent DOMs, while Virtual DOM is about keeping an in memory representation of the DOM to allow for more efficient rendering. Shadow DOM is a browser API whereas Virtual DOM is implemented in frameworks.
You’re confusing the shadow DOM with the virtual DOM and if you benchmark it, the only way the virtual DOM is faster is if you’re doing a bunch of horribly inefficient interactions. I usually find the DOM to be faster by several orders of magnitude because ultimately the real DOM has to be updated so any overhead is going to be on top of the same work.
That’s not saying don’t use a virtual DOM but pick it knowing that you’re taking on a moderate degree of inefficiency in exchange for a better coding experience, consistent structure, etc.
Agreed. I've seen otherwise great developers overlooked by recruiters just because they haven't been practicing RDD.
Thankfully there are still places that will see past that. Still, the idea of "keeping up" does need to factor in, and the experience could serve as a wake up call to where the industry is headed.
I think it's generally considered good when you can eliminate a dependency's reliance on another dependency to function. There's nothing inherently wrong with jQuery. If the functionality and size match your needs, there shouldn't be any problem.
My sense is that jQuery and early web front-end approaches reflect how designers think. They were created by designers who understood code for other designers who didn’t so that designers could play a role in the web. Sites wanted to be unique.
New frameworks reflect how developers think. Sites want to work more than they want to look unique. In many cases, uniqueness is viewed as driving up training or onboarding cost.
http://vanilla-js.com/