[meta] Replace JQuery with vanilla Javascript in core

This has long been my secret dream. ;)

It's worth noting that the JavaScript Modernization Initiative has already done a lot of work on replacing various jQuery stuff with language-native ES6.

Can we get some articles linked from the GitHub removal of jQuery? I know there was a lot of debate around "cool, but was it worth it?" because they had to maintain their own polyfills for some things. I definitely agree with stripping away as much jQuery usage as possible for `document.querySelector`, but I don't know if it should be bazooka'd just because we're all like "OMG NO MORE JQUERY, PLZ"

Whoa. Ok. I think we need to explore what an effort like this would look like. I know there is a meta around jQuery UI, maybe these efforts can coordinate?

~~~

Oh. I just checked the link. I don't think we should be replacing jQuery with another framework, if you want to use native browser JavaScript, then I am for that.

~~~

Further inspection, thanks for the joke.

@mglaman For me it is not about "Ew, jQuery" but around significant release risk added by jQuery and jQuery UI between them. jQuery has security and release processes that cause a lot of headaches for us already; jQuery UI has historically been even worse and is basically unmaintained now. Implementation of this issue would of course be postponed on the jQuery UI one, and I think that's where our most unavoidable jQuery use is currently. If we get rid of jQuery UI, a lot of the rest is probably replaceable with natively supported JS and whatever's left will tell us where to go from there.

+1 from me. I'm all for dropping jQuery - especially for maintainability. I just wanted to play devil's advocate. We also probably won't need to polyfill as many things out-of-the-box in Drupal core as a full product like GitHub may have to.

Good call Matt (re github for a reference point) -- https://github.blog/2018-09-06-removing-jquery-from-github-frontend/

Not 1 to 1 but largely went from jQuery to Web components, our own personal journey off jQuery to web components has taken some time but I'd say we're 90% off jQuery in our Drupal projects and replaced w/ vanilla / web components in different libraries.

A bigger issue associated with this is what browsers Drupal will support. As suggested with the move to ES6 syntax above by xjm, unless there's a build routine that's saying Evergreen browsers only. I would highly recommend dropping IE11 given that by year's end Edge will be evergreen (Chromium) and support all of ES6. If you can take the build routine aspect out of it (babel / compiling to ES5) then there's way more you can do for improving DX around JS in core.

Legwork was started a while back (remove sizzle specific selector, harmonize use of jquery methods, remove/simplify some dom manipulations, etc.). Things are easier now, clean-up is largely done, no overlay.

The main problem for this will be tabledrag, if we want to keep the same features it has today. Probably the dialog thing might be tricky to replace (there is a bit of a leak in the JS API that exposes jQuery-ui specific stuff, sorry).

The other thing is that jQuery is still above native for most event handling tasks, and does make the code simpler to understand. We'd need to make a few "helpers" to keep the same readability (and not rewrite everything), and at that point we're making our own library.

The path I wanted to take was to reduce the parts of jquery that we use, at the time I looked at which files used what from jquery: http://read.theodoreb.net/2015/viz-drupal-use-of-jquery.html and filled: #2137235: Make core JS work with a subset of jQuery. All that is at least 4 years old, so someone need to have another look at it :)

And ideally we replace all that with the modernization initiative :)

( edit ) having read the github post, yep, we do need all that. We were going the same way, good to know it could have worked :þ

+1 for this. e.g. Bootstrap 5 will also ship without jQuery: https://github.com/twbs/bootstrap/issues/28342

I would love this to happen. Anything I can help with?

It looks like this can be (more or less) automated with the tool mentioned in #15.

#3113400: Deprecate more jQuery UI library definitions still has some outstanding issues around it. It would be good to update the issue summary here for what would need to happen after that.

Should we make this a meta?

Why yes, let's. :)

Happy to make that a D10 target on my end.

Discussed this with @xjm and others and we thought it would be good to scope a small issue that makes a conversion of a single module to see 'how it looks'.

Here is one such issue: #3157328: Use vanilla JS instead of jQuery in path module

Please do not take this as a signal to create N Remove jQuery from {foo}.module issues. We want to see whether this is a reasonable approach before we have a proliferation of such issues.

many scripts are no jQuery already, you can grep it by regex :

^\}\)\((?!.*jQuery).*\);$

jQuery has a very good doc on cross-browsers, we can do more low-level evaluations
https://www.drupal.org/project/drupal/issues/2818655

Basically, you can study Bootstrap v4 & v5 branch. Script's concepts are shareable.

- To me, that's more important to discuss when & who can make the decision to introduce extra helpers, eg:
https://github.com/twbs/bootstrap/tree/main/js/src/dom

- Provide a bridge for jQuery or not..
For example, you will face the event problem like this:
https://www.drupal.org/project/drupal/issues/3068696#comment-13723056

- How to handle the increasing file size
Here we should not minus jQuery size on single page, that's meaningless. We need to take care of a single JS file, from 500 lines to 1000 lines.
diff thing but core concept are the same:
https://github.com/expo/fyi/blob/master/managed-app-size.md#a-note-about...

more lines = more bugs

- Ajax, effects, Promise..etc
Many sites dropping jQuery for another lib, eg. React. That takes care of a lot of things

- In jQuery, that's some parts are fine-tuned. for example $.on. That's Event Delegation. You need to evaluate the performance on the heaviest part on Drupal (eg. Settings tray? )

..etc

Just a note of caution, the situation with JS now is more or less the same as it was during the JavaScript clean-up that lasted 2 years. There need to be some change if we want to be faster this time around.

For me it is too soon to start with individual modules. We need to remove the dependency on jquery from a few things first: once, vertical tabs, ajax, events, tabledrag... after that we'll be well on our way. Starting with patch looks simple but because it uses drupalSetSummary we'll need to rewrite that part with JS before we can remove the dependency on jQuery in the path module.

Backbone might be more challenging than jQuery, because we have toolbar, contextual, ckeditor, quickedit, and tour relying on it and it's not the simplest JS we have in core.

Agreed with droplet about helper libs, and we'll definitely need one for events. There is browser support, can't use classlist in a nice way because of lack of support from IE for a couple of things.

As a side note, once it lands Olivero will be the first true "no-jquery" part of Drupal core (that and date.es6.js)

For me the next step here is #2402103: Add once.js to core and decide how we want to handle this type of library/helper because we'll need a couple more to get to the end.

Agreed that jquery.once is a good place to start here, and any other core libraries that are dependencies for lots of other core libraries.

+1 on jquery.once

+1

#2402103: Add once.js to core done

#2921810: Allow TimestampFormatter to show as a fully cacheable time difference with JS functionality relies significantly on JavaScript. The new feature has been initially designed with jQuery dependency. I've removed the dependency in one of the latest commits.

Updated IS for current state of child issues.

Removed contrib issue from the IS.

Also replacing mis-use of <strong> tags in the IS with semantic markup.

Also removing the IE11 issue which is no longer relevant.

Please note, ES6 trim is not equivalent to jQuery trim, ES6 trim will crash if the caller is undefined whereas jQuery trim handles an undefined parameter perfectly well.

@lauriii has elaborated a patch that adds the additional validation required to prevent ES6 trim from resulting in an exception.

#3291587-34: Regression fix for (if feasible) uses of the jQuery trim function to use vanillaJS

Furthermore, ES6 trim only trims whitespace, jQuery trim also trims newline and tab in addition to whitespace. With that said, the most serious regression of using ES6 is a javascript exception on an undefined calling the trim().

The most urgent issue here now is #3189416: Remove jQuery Form dependency from misc/ajax.js because jquery-form fatals with jQuery 4. It might be we find some more libraries that aren't compatible, but this breaks nearly every core javascript test.

It sounds like the jQuery project has some governance /road map issues if they're breaking so much backwards compatibility. Wondering if there's any reasonable fork options for jQuery 3?

@joseph.olstad, they've removed some code that in some cases has been deprecated for 10 years or more. Forking jQuery is the opposite of moving away from it, which is what this issue is for. If you want to talk about something else, please do it on another issue.

Moreover there is https://github.com/jquery/jquery-migrate

@andypost,
That looks helpful, thanks!

I think the very idea of deprecation is very badly overused and far too often abused and is most frequently avoidable. Seems to be generally a widespread costly practice deeply rooted in arrogance, ignorance and carelessness. Technical debt is also a bourgeoning buzzword that is being abused and used as justification to make poor decisions in the worse sense.

Deprecation should be avoided unless absolutely necessary. Arrogance, ignorance and carelessness are invalid reasons for deprecation.

When something is deprecated I think it would be normal that the benefits outweigh the costs by a decent margin and that there be a well thought out and balanced justification for it and even then go through some sort of a process to allow various stakeholders express their concerns. There should be a new manifesto for this sort of thing. I haven't heard much about this subject lately.

If nothing is done then deprecations will happen even faster when AI gradually takes over software development. There'll have to be some sort of awareness/process/guidelines established for both humans and machines in order to avoid total and utter chaos.

When something is deprecated I think it would be normal that the benefits outweigh the costs by a decent margin

Every single site with jQuery loaded requires it to be downloaded before pages can finish being built, this uses mobile data and battery, build process have to minify it - there's the benefit for jQuery having a smaller footprint. This entire issue is for moving away from jQuery to vanilla JavaScript so that more and more Drupal pages and sites don't need to use it at all, further reducing network/bandwidth/cpu usage. This ultimately translates into more or less carbon emissions and more or less degradation of mobile devices. Arguing to keep things exactly the same is like arguing to keep lead in petrol.

@catch
Many ways to mitigate footprint such as (but not limited to)

• use of a cdn for certain libraries
• exclusion from aggregation due to ability to optionally rely on cdn
• caching

Please provide migration tools. phpstan is awesome. the jquery once change was not. thanks.

Not wishing to go too far down a tangent here, but...

use of a cdn for certain libraries

I feel I should note that when using CDNs you have to be very careful with things like GDPR compliance, any libraries which you are including from a source you do not control are open to the possibility of collect data about users of your website without your knowledge. For example, see this article by The Register on a websites being fined by a German court for breaching privacy law resulting from usage of Google Fonts.

Website fined by German court for leaking visitor's IP address via Google Fonts | theregister.com

Additionally, including libraries from third-party sources increases the possibility of security issues, for example supply chain attacks.

Agree with #64. We, at European Commision, are not allowed to get code via CDN. Security is the primary concern

**optional use of cdn**

This could be a great performance option that could be done well for certain libraries to such as but not limited to jquery.core to reduce the payload and improve the usefulness of the aggregated js file.

js that tend to be frequently mutable should remain included in the aggregation for obvious reasons, otherwise those certain libraries should actually come from a cdn when optionally enabled

AND / Or alternatively offer performance option to separate aggregation into two files.

1) the frequently mutated js file aggregated file
2) the rarely mutated library files aggregated js file

This will help reduce the payload and frequency of mutation of rebuilt files to reduce bandwidth consumption

This is becoming off topic. Also this is something that can fully be done in contrib, you're describing a mix of adv_agg and jquery_update.