[Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions

Suggested places to look from the previous issues:

https://allyjs.io/api/index.html#finding-elements

http://youmightnotneedjqueryplugins.com/
https://plainjs.com/javascript/plugins/ui/

Also adding some related issues/prior work.

And marked #3067255: Find replacements for jQuery UI components as duplicate - crossposted with lauriii but this has the better issue summary.

Just my thoughts, copied from slack:

I feel like, since there hasn’t been a commit in 3 years to jquery_ui, that we should just do option 3 right now for the remaining components and decouple. Clearly we don’t have to worry about managing backports, so there’s no added maintenance in the short term. Then we should decide on long term option 1 or 2 component by component, and as we get closer to jQuery 4 and Drupal 9, we have the ability to prioritize the remaining components however makes the most sense.

The big problem with that, of course, is adding all that new (I assume) non ES6 code into core

I’m not a JS guy, but I know we don’t have a ton of JS devs working on core, and I know there was a lot of work going into converting to ES6, so I can’t imagine forking non-es6 code and just adding it with follow-ups will be super popular.

I don’t like adding technical debt to core, but realistically, it wouldn’t add more debt than we already have using the unsupported library, it just opens up options on how to fix it in a more controlled manner.

For me, forking or maintaining jQuery UI code should be our last resort. We can barely maintain our own existing legacy JavaScript, much less massive additional libraries. It's a lot of technical debt.

I also don't want us to take on the technical debt of porting these jQuery UI components to jQuery 4, or to support them in Drupal 10. So I recommend the following process:

1. Continue to research potential replacements for the above libraries on a case-by-case basis (one issue each -- let's get them in the IS, although we might want to postpone them on high-level conclusions here). Review them for the core dependency criteria, accessibility, and compatibility with our existing code.
2. If there are one or more strong possibilities for a given component, create a prototype of each to evaluate the quality, impact, and disruption.
3. If there are no strong options for a component, consider creating our own (and possibly open-sourcing them independently of Drupal).
4. If we don't have a clear, reliable solution for a given component by 8.8.0-alpha1, or if the option we pick is very disruptive, go ahead and fork the jQuery UI component and commit that to 8.8.
5. However, continue the issue to replace the component in Drupal 9 and deprecate it for removal before 10.0.0.

Also would like to hear the JS initiative's thoughts on all that legacy ES5 code becoming our problem. I don't think we should expend energy converting it to ES6 since it's EOL. We could just skip the files, or package them as a separate project somehow.

Adding contribution credit for people who helped discuss this problem space in the previous issue.

For me, forking or maintaining jQuery UI code should be our last resort.

From my perspective, this seems like our only real option. Given the relatively delayed start on this work, I don't think it's reasonable to expect a drop-in replacement for the needed jQuery UI components to be available within the required timeframe.

I think Sally suggested (slack/another issue/etc.) that we fork the existing jQuery UI package and only include the components we are currently using. I 100% agree with this.

This gives us a bundle of code that everyone is familiar with, meeting our current standards for inclusion with core, accessibility, etc. We won't be dependent on numerous other release cycles for smaller independent packages. Additionally this gives us some time to develop an alternative solution that could be implemented sometime in the 9.x release cycle.

All new libs should be able to resolve all current issues. Refined requirements of each component for the CORE & potential usage of every site provides a clean view to cross out the requests out of the scopes.

For the instances, with "Lean Core", 3rd parties should be highly extendable. It has to take into account in the selection reviews.

- the new Dialog should resolve the nested modal problem at the same time

- jquery.ui.datepicker is useless in Drupal Core. Simplify it with inputs provides a better UX for both mobile & desktop.

- sortable & draggable should be the same lib

- tabs should share the lib with collapse (It has the same functionality with different visual styling actually)
(Drupal has independent tab lib in CORE: vertical-tabs.es6.js & collapse.es6.js)

Quick question, do we want to have non-drupal related packages on drupal.org? I mean if we fork jquery ui, or we create a new js-only library that we want people to be able to use outside php/drupal. Shouldn't we keep that on drupal.org instead of putting it outside on github?

@nod_ drupal.org now running gitlab aside, which now perfectly supports releases additionally to existing "git archive" of current system

Having worked a lot with jQuery UI components while working on Quick Edit, I am terrified by the idea of maintaining it ourselves. Despite good intentions by its maintainers, it was not very reliable, nor clearly documented. Understanding its code is very difficult. So option 3 terrifies me for that reason alone. What makes it eve more scary is that like @xjm indicates in #4, we barely manage to maintain our own JS.

That being said, given the very tight timeframe, I'm not sure we have any other option. I think we should try to convert Drupal core to use other JS libs for the use cases mentioned in the issue summary, but whether we'll succeed is uncertain. However, this too comes with consequences: Drupal core itself is styling jQuery UI dialogs differently and Drupal's CSS and JS use jQuery UI-coupled selectors. This means contrib modules and themes do the same. Changing to a different JS library would be disruptive, which is exactly what we want to avoid. So I agree with @drpal's reasoning in #15, but have additional concerns that make me agree with his recommendation.

If we agree with @droplet's statement All new libs should be able to resolve all current issues. in #16, then I think even trying may be a waste of time and energy. Doing this for one or maybe two jQuery UI components may work out, but doing it for all of the ones listed in the issue summary is certainly not going to be possible before 8.8.0-alpha1. If the time pressure wasn't present, I'd agree with @droplet: we of course don't want to switch from one suboptimal solution to another suboptimal solution. But given time pressure, we may have no choice. This seems to just confirm @alwaysworking's comment in #15.

Thanks for linking to #2158943: Add a native dialog element to deprecate the jQuery UI dialog for jquery.ui.dialog, @lauriii. I attempted to try to find another contributor to help with that since it's pretty isolated: https://twitter.com/wimleers/status/1157261418913308672 🤞

EDIT: woah, I just noticed he actually linked to #3071552: Replace jQuery UI dialog with a supported dialog library. I wonder how I then ended up in #2158943: Add a native dialog element to deprecate the jQuery UI dialog by following links 🤔In any case, I think it'd be good to continue in that pre-existing issue with some prior art and discussion (but not overwhelmingly much) rather than starting a new one.

For core/jquery.ui.tabs, #3070369: Remove Drupal\views_ui\ViewEditForm::form dependency to jQuery UI tabs removed the only use. 🥳 But we still have to deprecate it. 😊

#27 is wrong — core/jquery.ui.tabs will be deprecated in #3067251: Deprecate unused jQuery UI components in favour of a suite of contrib modules.

Just want to point out one thing about reusable.

#3051766: Deprecate and replace jQuery Joyride (for tours)
shepherdJS powered by -> tippyjs -> Popper.js

#2207383: Create a tooltip component
It can be tippyjs now

#3074267: Replace jQuery UI position() with PopperJS
It must be Popper.js

If it happened, I suggested making a custom build of shepherdJS to exclude "tippyjs" from it.

Re #29
@droplet please have a look i added this build for tests.
https://github.com/iberdinsky-skilld/shepherd/commit/f4a8ee3cd02142ced93...

generates shepherd with tippy.js as global variable using external globals feature of rollup https://rollupjs.org/guide/en/#core-functionality

So we're trying to avoid new deprecations in 8.9.x, but if contrib modules don't actually have to update for the change from jQuery UI to its replacement then there's no API change to worry about as such and I think patches could still land in 8.9.x, but it's probably going to depend a bit on what each patch looks like and how disruptive it might be. Also not sure how we handle BC when there are API changes either.

Re-reading this I think we can actually close this meta issue.

#2158943: Add a native dialog element to deprecate the jQuery UI dialog
#3076171: Provide a new library to replace jQuery UI autocomplete
#3113400: Deprecate more jQuery UI library definitions

All these are independently critical and have patches, the actual removal of jQuery UI will need to happen prior to Drupal 10 but each individual step has a well documented path forward now. I've also listed them on #3118149: [meta] Requirements for tagging Drupal 10.0.0-beta1.

That was premature - there's new discussion on the awesomplete patch and the potential that #1899236: Add new Splitbutton render element to eventually replace Dropbutton could end up superseding it, so re-opening.

I just moved the Autocomplete and Dialog issues to #3265680: Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 11 core. Since the rest of the work is completed, let's mark this fixed.

I see this is closed and yes, I get that jQuery UI is no longer part of core; but this issue had 2 parts:
1. Remove jQuery UI components used by Drupal core AND
2. replace with a set of supported solutions

Did #2 happen?

I see comments like Wim's in #27 that Tabs could be removed as its only use in Core was View UI. This is a bit scary and suggests part 2 of this may have fallen by the way side. Let's remember that utilities in core are not here to build core (as no one builds a web site with core) but to enhance Drupal as a framework for building applications.

Perhaps these have all been replaced? I do see a comment mentioning that collapse.js could be used for tabs. Any documentation on the full set of replacements (should be part of this issue)? jQuery UI certainly has excellent documentation.