Remove jQuery UI from core

Isn't the real problem that Drupal hasn't adapted to using jQuery UI where possible? It looks suitable for modal dialogs, autocomplete, date widgets, color picker and progress bar, to name a few. It would be great to have more information in this issue on why jQuery UI isn't being used now.

Actually, there is one reference to jquery.ui.core in the overlay module. That said when you take it out, everything works fine. It's a leftover from the jQuery UI days of the overlay.

Related issues:

#675446: Use jQuery UI Autocomplete
#1667742: Add abstracted dialog to core (resolves accessibility bug) (not jQuery UI Dialog, for some unknown reason I never understood)
#1169906: Switch to jQuery UI Menu for the Contextual Links
...

Overall, this seems to be the opposite direction of:
#1666920: [meta] Where/when to use jQuery UI

Not necessarily, "never" is a valid answer to the "when" question of using UI. My position about the other issue is well summarized by the title of this one :)

There hasn't been much love for the other issue, that might be saying something too.

@nod_ I know you would love to remove all jQuery from core. But the whole idea of putting jQueryUI in core, is that we would have access to its great features for drag & drop of blocks/fields. Sadly, none of that ever happened - the idea at the time was that we do not have the resources to develop and sustain that on our own. With the layout stuff coming, do you think we can?

A large part of the challenge is making it accessible, which jQuery is actively pursuing. Our accessibility team is not growing, and similar to the UX-team its only struggling more and more. This is far from a use/not use question, its a question whether we want to develop our own js. for all of the functionality that jQuery UI supports and if we have the team to support that - and this goes beyond the newly found maintainers. It has an impact on the usability team who has to review custom created things, the accessibility team who has to make it all usable, the performance people who have to make sure it doesn't slow drupal down etc.

Also beyond core, how is it used in contrib?

Well, I know that D6 is hellish for a module like FullCalendar. D7 made it a lot easier.

That said, I think this module is a negatively phrased version of #1666920: [meta] Where/when to use jQuery UI, and should be marked as a duplicate.

@sun #1667742: Add abstracted dialog to core (resolves accessibility bug) is a fapi/ajax command wrapper to jquery:ui.dialog
Would love some more eyes on the php side of that patch.
Thanks

In fact, #1667742: Add abstracted dialog to core (resolves accessibility bug) came about after much discussion in #1175830: Update to jQuery UI 1.10.2 where jQuery UI dialog was accessibility tested, and larowlan addressed the remaining bugs in a jQuery pull request that scottgonzales from the jQuery UI team said would be committed in time for D8.

I don't know how feasible it would be to find another dialog widget or roll our own that meets our accessibility needs.

One of the big issues with jQ UI is size. Custom builds could take that down. I'm sure that's an issue floating around somewhere, something like the "expose modernizr build to module system" issue from a while back.

Also, if I remember correctly the Aloha version that Spark is using is dependent on it. With all the effort being put into pushing Spark into core, it seems like jQ UI is a defacto core dependency.

I love cutting out dead weight, but I think the "how can we use jQuery UI more efficiently" is going to be the real Drupal issue. It might not be possible to chop it down, but we can prune it back.

This will likely fail due to binaries being removed.

I love cutting out dead weight, but I think the "how can we use jQuery UI more efficiently" is going to be the real Drupal issue. It might not be possible to chop it down, but we can prune it back.

The way to do that would be to make it able to use an AMD architecture. Here's jquery-ui-core. We'd have to do the same to each component, and then introduce a package.json to bring them in. In the mean time, I don't see anything wrong with its removal. Of course, if it is needed by anything, exposing it in jQuery UI module is always an option.

To back up RobW, I totally don't understand why this is being looked into now, while we're still in code thaw. There are definitely Spark patches and blocks and layouts patches forthcoming that wish to make use of this library, as well as numerous patches in the queue that provide incremental improvements that would be fine to go in even as late as code freeze, like adding date pickers to author date fields and what have you.

I'm therefore postponing this, at least until Feature Freeze, if not Code Freeze. It doesn't make any sense to me to rip libraries out until we're sure we're not using them, and there's no reason ripping libraries out needs to happen before Dec. 1.

@webchick The reason I was pushing this forward is because it's blocking #1542344: Use AMD for JS architecture. I've talked with Scott Gonzalez from the jQuery UI team, and they currently have no plans to support an AMD architecture. Let's get rid of it for now to un-block AMD. If we need it later on, we could do that, otherwise it's just stalling issues.

I outlined what would be required to have jQuery UI under an AMD structure in the comment above.

Views in core is an official initiative and per #8 requires an accessible modal dialog. We can't remove jQuery UI without a clearly identified alternate dialog widget.

@Rob, that's not blocking the AMD issue, we can make it work with UI as-is :)

Let's do it!

What are we using jQuery UI for that can't be done cheaper with native HTML5 & polyfills?

The Government of Canada's WET Toolkit has dropped jQuery UI from their collection of tools because it adds too much to page load times, particularly for mobile users. They can get more for less if they build up from HTML5 rather than working with the larger jQuery UI engine.

Seeing that Drupal 8 is being built for mobile & with html5 this is something to be considered.

Things that can't be handled yet with this approach would be:
- autocomplete
- modal dialog
- contextual links

hm, this is a tricky situation. Although it's used lightly in core having a common UI framework for contrib to leverage is a good thing.

There are very few comprehensive UI frameworks that are built to serve both mobile and desktop, a framework either has a desktop-first approach and hence a heavy reliance on jQuery (eg Twitter bootstrap) or aims for a UI framework that imitates mobile OS's (eg Kendo or Sencha Touch).

Adding a mobile UI framework now is risky, especially when the mobile UI is loosely defined in core currently, see: #1595292: Create a style guide for Drupal's mobile UI

...plus #675446: Use jQuery UI Autocomplete was recently preferred over #1271622: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter) that got wontfixed.

Given autocomplete and dialogs, is there any benefit to keeping this issue open, or should we "won't fix" it and use #1666920: [meta] Where/when to use jQuery UI for ensuring we only use jQuery UI where it's needed?

Sun reopened the chosen issue with valid feedback and dialogs will be abstracted enough we don't need to rely on jQuery UI, even if that makes things simpler for us.

We're now using jQuery UI dialogs in a number of places: the Diff UI, Views, Editor module, and lots of patches in the queue to extend this support. We're definitely not removing jQuery UI in D8 at this point. Any replacements will need to accomodate for these situations.

Let's bump it ahead to D9 then.

Haha it's one of my favorite issue :p

Let's be realistic though, with all the stuff using it now (ckeditor, edit, dialog.js) and the lack of alternatives it can't be not postponed.

CKEditor does not use jQuery UI at all. Only the "drag and drop toolbar configuration" part of it uses jQuery UI (sortables & draggables).

Edit does not use jQuery UI explicitly, it only uses an architectural layer from it: jQuery UI Widgets. And it only uses that because Create.js uses it. And many people have expressed towards Create.js developers that the usage of jQuery UI Widgets is a disadvantage, because it is so very confusing.

So that leaves:

• drupal.dialog (jQuery UI Dialog)
• drupal.overlay.parent (jQuery UI core)
• Views UI (jQuery UI Tabs & Dialog)

It of course seems better to not spend energy on getting rid of jQuery UI at this point, but long-term it might make sense. Potentially even after code freeze, if jQuery UI turns out to be preventing good front-end performance (after profiling).

It of course seems better to not spend energy on getting rid of jQuery UI at this point, but long-term it might make sense. Potentially even after code freeze, if jQuery UI turns out to be preventing good front-end performance (after profiling).

Are you referring to the overhead of loading all the source code or performance problems with usage? I wound encourage you to discuss any problems (if there turn out to be any) upstream before deciding to remove jQuery UI from core. You can file issues at http://bugs.jqueryui.com, or ping me directly. I'm scott_gonzalez on freenode (#drupal-contribute and #jqueryui-dev) or scott.gonzalez@gmail.com for email/jabber.

I'm referring to the loading of source code indeed. I personally don't know of any performance problems in jQuery UI's code itself.

For whenever this is unpostponed (or if someone feels like doing it before then), an updated issue summary would help. At this point, are the reasons:
- updatability between minor Drupal releases?
- accessibility?
- code loading performance?
- something else?

I think many of these things have already been addressed or are being addressed. For example, for the dialog uses, the jQuery UI code is only loaded when a dialog is actually returned to the user, so there's no performance cost on pages that don't have dialogs, or have potential dialogs that are never opened.

temporarily tagging. :)