Search jQuery

jQuery Forum

Developing jQuery UI

Jemt

Multiple versions of UI running simultaneously

Will not implement

Maybe later
Under review
In-progress
Implemented
Will not implement

in Developing jQuery UI • 7 years ago

Hello guys.

Many web applications supporting extensions (e.g. Content Management Systems), allow developers to build their client code and user interface using jQuery and jQuery UI. That's awesome. But unfortunately these systems ship with only one version of jQuery. So every time they upgrade jQuery, they break a lot of existing extensions (jQuery 1.9 was a challenge, right?)

I'm allowing developers to load any version of jQuery they need, completely isolated. So to simplify, they can do this:

runJquery(

{

version: "1.10.2",

plugins: [ "http://domain.com/jquery-ui-1.10.3.min.js" ],

ready: function($)
{

alert("jQuery version " + $.fn.jquery + " and UI 1.10.3 loaded");

}

});

runJquery(

{

version: "1.8.2",

plugins: [ "http://domain.com/jquery-ui-1.9.2.min.js" ],

ready: function($)
{

alert("jQuery version " + $.fn.jquery + " and UI 1.9.2 loaded");

}

});

Pros:

1) Existing features don't break - they keep running on the version originally targeted.

2) Developers can target new versions as soon as they become available on the CDN we use (Google)

3) Developers are not forced to immediately upgrade jQuery code - there can be reasons not to.

3) Plugins loaded do not pollute a shared instance of jQuery - potentially causing it to become unreliable.

So loading jQuery and plugins isolated works. Even UI loads. The problem is the required CSS theme file since all versions of UI define identical CSS selectors. So CSS conflicts are almost inevitable.

Example of CSS selector:

.ui-dialog { .. }

What it most likely should have been to support multiple versions running at the same time:

.1_10_3 .ui-dialog { .. }

Some sort of version prefix is needed.

I think this makes perfect sense given the reasons provided, and it perfectly compliments noConflict(..) and adds consistency.

Thanks for taking the time to read my proposal.

Regards

Jimmy Thomsen

Replies(9)

kbwood.au

Re: Multiple versions of UI running simultaneously

7 years ago

On the jQuery UI Download page you can specify a CSS Scope to incorporate into the ThemeRoller CSS as you've outlined above.

Jemt

Re: Re: Multiple versions of UI running simultaneously

7 years ago

Hi Kbwood

Thanks a lot for pointing that out. That may prove useful as a work around.

But it is not a solution to the problem. It does not work with UI loaded from a CDN, and asking people to make custom builds for every version and theme they want to use seems cumbersome. In general all jQuery plugins should fully support the ability the run multiple instances. I wonder how this works with AMD - its probably the same issue.

Jimmy

scott.gon..

Re: Multiple versions of UI running simultaneously

7 years ago

Sorry, but there is no problem here. You can't expect to use multiple versions of ANYTHING that requires CSS and not expect to customize the CSS. Your suggestion would likely just create more problems. It's actually quite terrible to load multiple versions of the full jQuery UI suite just to support "simple" upgrades.

Jemt

Re: Multiple versions of UI running simultaneously

7 years ago

Hi Scott.

Thank you for taking the time to comment on my suggestion.

However, I'm quite disappointed that the suggestion is simply thrown away without much consideration, and without actual reasons other than "it's terrible" and "likely to cause problems". Most things are if not implemented properly. If you know of actual problems (facts), I would be very happy to hear about them. I doubt memory will be a serious problem unless there is something fundamentally wrong with the mechanisms responsible for disposing objects in jQuery, or the app is running on a very old PC.

Consider a CMS like Joomla, Wordpress or any other CMS. They include a globally accessible and shared jQuery instance which can be manipulated and have plugins injected by any CMS extension installed. Do you consider that instance stable, secure, and reliable? I certainly don't.

Also, developers (most likely less experienced once) often tend to just switch the jQuery version to one that suit their needs, causing all other extensions to break. That's terrible.

My suggestion seems fairly simple to implement. Future versions of UI should have the version number as part of all CSS selectors (replace "version" with actual UI version number):

.ui-dialog { .. } becomes .ui-version .ui-dialog { .. }

If UI wraps all GUI components in a container with class="ui-version", the problem will be solved, and people will be able to load multiple versions of UI.

What was the intention of introducing .noConflict(true) if not to support multiple versions of jQuery running simultaneously?

Why are AMD support being added to jQuery and plugins if not to support multiple versions of jQuery running simultaneously?

If the purpose was infact to support multiple versions running simultaneously, then why not ensure some consistency across the jQuery suite?

I'm fairly new to jQuery (but not JS or programming in general). I'm incorporating jQuery into an existing extendable web application. I want to do this in a way that eliminates all the problems with the usual implementations that keeps breaking. I think I have raised some interesting questions that deserves some more consideration.

Regards

Jimmy Thomsen

scott.gon..

Re: Re: Multiple versions of UI running simultaneously

7 years ago

What was the intention of introducing .noConflict(true) if not to support multiple versions of jQuery running simultaneously?

I assume you've never read the documentation:

Many JavaScript libraries use $ as a function or variable name, just as jQuery does. In jQuery's case, $ is just an alias for jQuery, so all functionality is available without using $. If you need to use another JavaScript library alongside jQuery, return control of $ back to the other library with a call to $.noConflict(). Old references of $are saved during jQuery initialization; noConflict() simply restores them.

Why are AMD support being added to jQuery and plugins if not to support multiple versions of jQuery running simultaneously?

For dependency management and build systems. I assure you this has NOTHING to do with loading multiple versions of jQuery onto a single page.

My suggestion seems fairly simple to implement. Future versions of UI should have the version number as part of all CSS selectors (replace "version" with actual UI version number):

Off the top of my head, this will 1) hurt performance by requiring additional DOM manipulation on every single widget instantiation 2) break CSS based on position (direct child, nth-of, etc) 3) Not work because of nesting.

Also, developers (most likely less experienced once) often tend to just switch the jQuery version to one that suit their needs, causing all other extensions to break. That's terrible.

Even more terrible than a bad developer doing bad things is "good" developers encouraging them to do bad things. Loading multiple versions of any library is never good.

It honestly doesn't matter how much you want to beat this dead horse. You've been told by many people involved in the project that we think this is a bad idea. We've been saying this is a bad idea for years. You're not going to convince anyone on the team that we should make it even easier than it already is for developers to load multiple versions willy-nilly. And we certainly won't be encouraging it.

Jemt

Re: Multiple versions of UI running simultaneously

7 years ago

Hello again.

Thanks for being patient with me, I appreciate that.

Regarding the documentation for noConflict() - I was specifically refering to noConflict(true) which also releases window.jQuery. I may be wrong, but I don't see the need to release it unless you want to load another jQuery version temporarily and return control to the version initially loaded.

I've misunderstood the purpose of AMD then. I briefly read about it. Thanks for enlighten me.

Regarding the CSS, you could instead do this:

Before: ui-dialog { .. }

After: ui-version.ui-dialog { .. }

GUI components registering ui-dialog should now register the ui-version too (<div class="ui-version ui-dialog">). Perhaps a viable solution.

As to the dead horse, I'll stop beating it now. It seems you made your decision, and I respect that. We just disagree. In my opinion one cannot assume that libraries in general cannot or should not be loaded multiple times - but it does of course depend on the design and architecture of the specific library in question. Security and reliablity is a concern of mine, as well as allowing developers to keep using jQuery code written for previous versions, should they choose to, to prevent features from breaking.

Thanks for you time once again :)

Regards

Jimmy Thomsen

scott.gon..

Re: Re: Multiple versions of UI running simultaneously

7 years ago

It doesn't matter whether you put the class on the element or wrap the element, it still breaks with nesting. You can't have a version X anything inside a version Y dialog, accordion, tab set, etc. Unless you want our CSS to become massive. But I guess you don't care about file size if you're loading multiple complete versions of jQuery UI. Most users do care.

Mick McGr..

Re: Multiple versions of UI running simultaneously

7 years ago

Scott,

I was browsing through some docs, and I came across this thread. I just have a simple scenario which may raise a question about your comment:

Loading multiple versions of any library is never good.

I am building a JavaScript application that uses steal.js as a dependency loader. Steal pulls in jQuery (and various other libraries) for the application to work, and I require jQuery 1.7+ so as to use the .on() method for event binding.

This application is actually an embeddable snippet which users can embed into their site and have things happen via ajax and an API key. Many of these users will undoubtedly have versions of jQuery older than 1.7, but I need my embedded application to work regardless.

I do not have the ability to force the users to upgrade their versions of jQuery.

How then, in light of your comment above, would I ensure that my application still works on sites which already have versions of jQuery older than 1.7 without, ultimately, having multiple versions of jQuery loaded on the page?

Respectfully,

Mick McGrath

scott.gon..

Re: Re: Multiple versions of UI running simultaneously

7 years ago

This is actually off-topic, so I won't reply in this thread after this. You have a few options: 1) Stop requiring .on() and make your code work with older versions. 2) Require the user to have 1.7. 3) Load multiple versions of jQuery.

Top Reply

Response title

Attachments

jQuery Forum

Multiple versions of UI running simultaneously

Will not implement

Replies(9)

Re: Multiple versions of UI running simultaneously

Re: Re: Multiple versions of UI running simultaneously

Re: Multiple versions of UI running simultaneously

Re: Multiple versions of UI running simultaneously

Re: Re: Multiple versions of UI running simultaneously

Re: Multiple versions of UI running simultaneously

Re: Re: Multiple versions of UI running simultaneously

Re: Multiple versions of UI running simultaneously

Re: Re: Multiple versions of UI running simultaneously

Statistics

Tags

Actions