So we have the latest jQuery UI in core.

Already created:

The cold and hard truth is that jQuery UI is big and takes more than 0.3s to initialize on mobile – beside any file loading. And needs to load a big chunk of CSS as well. I don't have to spell out how huge this is. This is in fact pretty much incompatible with the mobile and performance target of D8. jQuery UI will not have significant improvements on that front in the foreseeable future.

If our priorities are well defined, this is a no-brainer.

  • 1) easy 2) fast: use jQuery UI everywhere.
  • 1) fast 2) easy: don't use jQuery UI.

I believe the current priorities for mobile are : 1) fast 2) easy.

I'm setting major since we want that answered to get going with the other issues.

Comments

sun’s picture

Title: [Meta] where to use jQuery UI » [meta] Where to use jQuery UI
Issue tags: +JavaScript, +Front end
RobLoach’s picture

#1341792: [meta] Ship minified versions of external JavaScript libraries will speed it up.

The benefit of using jQuery UI is that all the components are re-usable. This means that once the framework is loaded, major parts of it will be re-used elsewhere. It also means that they share the same CSS framework to keep consistency in both the UI and the CSS classes.

The cons of not using jQuery UI are that we have inconsistent designs between all our user interface elements, and need to implement all the components separately. They will not share the same CSS and we'll have to maintain all the components ourselves. jQuery UI has a large well-established community, and is actively maintained.

Also, if we're looking for Mobile support, there is jQuery UI Touch Punch, which adds a few mobile-related events to jQuery UI components.

nod_’s picture

Title: [meta] Where to use jQuery UI » [meta] Where/when to use jQuery UI

Well that's a biased reply if I know one :) minified version will not speed it up, D7 already ships minified versions. The 0.3s delay on mobile is uncompressible as of today and in the forseable future. It's not just about filesize.

I want to know the priorities to decide on this, basically you're voting for 1) easy 2) fast. Yes it's more work to do our thing but that's what we're doing today so that somehow works. The consistency is not an unsurmontable issue and even with UI there is an issue in the queue to get rid of the default styling of UI. One way or another that will be worked on anyway.

rbayliss’s picture

I'd like to point out two things. First, the things we're talking about replacing with jQuery UI are typically admin-level tasks (autocomplete, contextual), meaning that the extra load time wouldn't necessarily be transferred to every user. Second, a 'typical' Drupal site has a lot of "extra" javascript weight loaded on a given page for things like modal popups or tooltips. If it was easier to do these things using jQuery UI, maybe we could get rid of some of the extra plugins and see a net speed gain. The next step in making this happen is to have core set an example for how and when to use it.

Right now, we have the UI in core, but it feels like everyone is scared to be the first one to add it to the page, because of the overhead nod_ mentioned above. But the relative cost of that overhead goes down dramatically if we agree to make it a common component and start replacing other things with it. I guess this makes me 1.) Easy 2.) Fast.

nod_’s picture

That's a totally fair point and seeing how the direction jQuery is going in I might even support it. I would just like to point out that one of the jQuery lead had a very different opinion a couple of months ago about the recent changes announced for jQuery #1541860-73: Reduce dependency on jQuery.

Also the autocomplete is not admin-only, for example it can be used for the search input. So while the majority of the components may be used by admins/editors (and it can be a lot of people, think intranet) D8 is still supposed to focus on mobile, editor experience and editor experience on mobile :)

Thanks for the input, keep it coming! the more opinions we have the better :)

servantleader’s picture

IMHO In today's world, a UI framework that does not support touch screens is worthless. It is inexcusable that Jquery UI did not have touch support 2 years ago. I just visited the Jquery UI demos page with my Windows 8 tablet, and most of the demos did not work. Should we be depending on framework that is years behind the technology curve? In my modules, I only use the date picker, because that is one of the few Jquery UI widgets that will work with a touch screen. The library is way too heavy to be justified as only a date picker. So, my vote is to drop Jquery UI.

nod_’s picture

Priority: Major » Normal

Was major at the time since there was much less js people around and was trying to get attention. We have a decent number of JS people around now.

The use cases are growing more or less organically around jQuery UI and I don't think a strategy is needed at this point. If it is it's for the issue sun linked to about the jquery themes.

warmth’s picture

Is there any remote idea of backporting this to Drupal 7? I would love to use jQuery UI modals & tooltips in the future and there is no module to do that (I think).

quicksketch’s picture

With #1870764: Add an ajax command which makes it easy to use the dialog API in complex cases, this makes the question quite a bit easier regarding dialogs. It's not question of Easy vs. Fast, since for dialogs it's "only when it's needed". The entirity of jQuery UI is loaded on-demand now for dialogs, making the use of jQuery UI non-controversial for the case of dialogs. You don't encounter any overhead at page-load time and the 0.3s delay is acceptable if you're about to do something that *requires* a dialog (say like uploading an image into a WYSIWYG or configuring a view).

This is potentially still an issue for #675446: Use jQuery UI Autocomplete, which could need jQuery UI on a lot of front-end pages. But otherwise I'm not sure if loading jQuery UI is a problem. If you're doing a drag and drop interface, it'll have to be included, but that's a page-specific problem.

quicksketch’s picture

Issue summary: View changes

finish writting

YesCT’s picture

Issue summary: View changes
Issue tags: -Front end +frontend

correcting the tag to the more common one.

nod_’s picture

Status: Active » Closed (works as designed)

Not a problem now really.