Add jQuery 2.0 to available scripts to enqueue

[tw2113]

jQuery 2.0 was released, and is a major release, more than previous ones. the 2.0 branch removes support for IE8 and down. Personally, I think it'd be best to add it alongside jQuery 1.9.x instead of outright replace. That way people who want to use the 2.0 branch can, but those who need legacy IE support still, can still use 1.9.x.

My thoughts were for a new enqueue handle of 'jquery2'.

[ryanduff]

That could work. Would allow core to enqueue 'jquery' by default and users an option to dequeue 'jquery' and enqueue 'jquery2' if they wanted to use it on the backend (assuming, other than browser support, everything in wp-admin works with 2.0). On the front end it wouldn't matter as much other than giving the user the option to enqueue one or the other for use in the theme.

[tw2113]

To clarify. This wouldn't be able to be replace jQuery in WP Admin, because of needing to support IE7+ still in the admin. However, making it available to theme/plugin developers would be beneficial for those who want it.

[ryanduff]

Yeah. Noticed that once I started digging into things. First pass patch to include jquery2 for front end use.

Probably punt this to 3.7 (I think all will agree), but I can't change/set milestones.

[nacin]

I think we'll probably want to just stick with the 1.x branch in core for now. There isn't much benefit to having a script in core we're not going to use that has the same API as an existing script.

I had some conversations with jQuery core members back when 2.0 was merely a line on a roadmap, and they supported the notion 1.x would be what we'll use for the foreseeable future. I'm not sure we gain anything from bundling it. Eventually (in 2-3 years maybe) we can drop 1.x, or if the landscape hasn't changed much in the next year or so, add 2.x, possibly by using conditional comments (so we serve 1.x only for lte IE8, 2.x otherwise).

[tw2113]

Not even strictly for frontend facing applications? What about those who have no need to support less than IE8 that want the lighter footprint that would be available. I know many people who advise against using something like google CDN copies of jQuery, and making available would appease that. However, not bundling it would force them to get it from somewhere else.

I fully support staying to the 1.9 branch in admin.

[knutsp]

What is the downside not to add it? May themes and plugins start to bundle it for front end use? Might it be better to add it early, even if not used in core yet, than later?

I mean, we are talking about jQuery, not some nicetohave.js

And WordPress is evolving beyond a CMS, taking the role as an application framework.

[ocean90]

Having the handle jquery2 is weird. What happens when we drop the 1.x branch? What happens on jQuery 3.x. jquery3? It's inconsistent with our current handle naming.

It's means also that we need to support both versions more or less.

Patch should also include the minified version. We doesn't add unminified versions of external scripts.

[ryanduff]

Replying to ocean90:

Having the handle jquery2 is weird. What happens when we drop the 1.x branch? What happens on jQuery 3.x. jquery3? It's inconsistent with our current handle naming.

It's means also that we need to support both versions more or less.

Correct. Without handling both versions this issue is moot because I don't see WordPress supporting jQuery out of the box. How else would you propose switching between which version is enqueued if we were to enqueue both under the handle of jquery? A constant that we check on in scripts-loader.php? I think the general consensus is not to make new constants either, if all possible.

As far as handling future versions, I think using jquery2 is appropriate because it's such a huge jump. The thought was that once we finally defaulted to jQuery 2.x, we'd update the 'jquery' handle to use that and just deprecate the jquery2 handle.

Patch should also include the minified version. We doesn't add unminified versions of external scripts.

Where's jquery.min.js in core? I couldn't find it. I have no issue with adding a minified file, but I was consistent with what was there now-- an unminified version of jquery. Not to mention there are a fair number of js files included in core that aren't minified-- ​http://codex.wordpress.org/Function_Reference/wp_register_script#Handles_and_Their_Script_Paths_Registered_by_WordPress

[SergeyBiryukov]

Replying to ryanduff:

Where's jquery.min.js in core? I couldn't find it. I have no issue with adding a minified file, but I was consistent with what was there now-- an unminified version of jquery.

In all releases since 2.2, jquery.js is minified:
​http://core.trac.wordpress.org/browser/tags/3.5.1/wp-includes/js/jquery/jquery.js

In trunk, it's temporarily uncompressed for easier debugging: [23301], [23421].

[tw2113]

Closing.

If you wish to use it, enqueue jQuery 2.0 on your own and don't unregister the core copy of jquery to use the handle. Use a different handle for 2.0. Make sure to leave on frontend only, and out of the admin.

[micasuh]

Understanding a huge majority of plugins using jQuery 1.x by default, I'm curious to know, now that it's 3+ years after this thread was started, if integrating jQuery 2.x should be considered.

jQuery 3 is on the horizon as an alpha phase:
​http://blog.jquery.com/2015/07/13/jquery-3-0-and-jquery-compat-3-0-alpha-versions-released/

<=IE8 are globally in low single digits as of last month with IE6 and IE7 not even registering or measured:
​http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201510-201510-bar
​http://www.w3counter.com/globalstats.php
​https://stats.wikimedia.org/archive/squid_reports/2015-06/SquidReportClients.htm
​https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

At what point does the WordPress community force theme and plugin developers to drop oldIE support and move to 2015 (and less than two months from 2016)?