[meta] Replace JQuery with vanilla Javascript in core

Created on 1 May 2019, over 5 years ago
Updated 10 May 2024, 7 months ago

Problem/Motivation

Inspired by #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path โ†’

jQuery used to be so awesome and It has been with us since Drupal 5.0 โ†’ !
IE10 was released in 2012 and supported most (all?) of the vanilla javascript that is needed to replace jQuery code.

Using vanilla javascript would allow us to remove jQuery from Drupal core as a dependency.

Proposed resolution

http://vanilla-js.com :)

The web is full of great resources for making the switch:

Remaining tasks

Relevant issues and their status as of Dec 19, 2022

Including the date here as the summaries may go out of date -- but I think it's useful to have here as we have enough tabs open already.

Postponed:

Replacements

The total size of helper libraries must be lower than minified jquery which is 88kb today + 0.9kb for jquery once.

๐ŸŒฑ Plan
Status

Active

Version

11.0 ๐Ÿ”ฅ

Component
Javascriptย  โ†’

Last updated 1 day ago

  • Maintained by
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom @justafish
  • ๐Ÿ‡ซ๐Ÿ‡ทFrance @nod_
Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States shaal Boca Raton, FL

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany pminf Nuremburg (Germany), formerly Dresden
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    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 โ†’

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    The most urgent issue here now is ๐Ÿ“Œ Remove jQuery Form dependency from misc/ajax.js Needs work 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.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    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 fork options for jQuery 3?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @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.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    @andypost,
    That looks helpful, thanks!

    I think the very idea of deprecation is very badly overused and far too often abused and is often avoidable. Seems to be generally widespread. Technical debt is also a new term that is being abused and used as justification to make poor decisions in the worse sense.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    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. 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. Arguing to keep things exactly the same is like arguing to keep lead in petrol.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    @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
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada Charlie ChX Negyesi ๐ŸCanada

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

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom AaronMcHale Edinburgh, Scotland

    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 no 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.

  • ๐Ÿ‡ท๐Ÿ‡ดRomania claudiu.cristea Arad ๐Ÿ‡ท๐Ÿ‡ด

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

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    ** use of cdn**

    This could be a great performance option that would 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 tends to be frequently mutable should be included in the aggregation, otherwise those certain libraries should actually come from a cdn when optionally enabled.

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance nod_ Lille

    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.

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly trickfun

    Sorry but i don't understand.
    Drupal 11.0.0 will ship with jQuery 4.

    Is there no hope to have vanilla in D11?
    Thank you

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @trickfun see the child issues of this issue, as you can see, some are fixed, some or not. When they are all fixed, we won't be using jQuery any more. Libraries are only used when they're needed, so the more core libraries don't use jQuery, the more actual sites/pages on sites will be vanilla.

Production build 0.71.5 2024