jQuery 2.0 stable is just out, we made sure our JS was compatible with jQuery 1.9 a short time ago so that we could use jQuery 2 when possible.

Here it is.

- Put the library version as 1.9 since it's the API we'll keep compatibility with.
- I move jquery in it's sub folder like the rest of vendor scripts.
- renamed the jquery file with the "official" file name, we don't care it's all abstracted in the library declaration.

It's a perf thing too. Several other reasons but we should do it anyway.

(conditional comments are not great but I'd say to get rid of them the easiest is to drop support for IE8 in D8 :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nod_’s picture

Issue tags: +mobile, +frontend performance

forgot tags

cweagans’s picture

Marked #1974236: Update jQuery to 2.0 as a duplicate

cweagans’s picture

If we can agree on #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8), then we can just use jQuery 2.0 here. IMO, that's a better solution, but if this is the only way to get jQuery 2 into core, then so be it.

Status: Needs review » Needs work

The last submitted patch, core-js-jquery2.patch, failed testing.

Wim Leers’s picture

One big concern: doesn't using conditional comments cause worse JS aggregation?

nod_’s picture

Status: Needs work » Needs review
FileSize
354.75 KB

Fixed tests, they were using jquery.js where drupal.js is slightly more appropriate. That's a file we own.

@Wim, there are concerns, yes. It's more fun to talk with a green patch around though, just in case.

For aggregation, we'll all be using SPDY soon right? :) And it can't be much worse than what it currently is.

Wim Leers’s picture

SPDY is still far away from being used on the majority of sites.

And yes, JS aggregation is already very crappy in core, so you're right, it can't be much worse.

jcisio’s picture

SPDY is currently used by 52% of browsers http://caniuse.com/spdy. However make one or two more requests for jQuery I don't think it is a big deal.

Status: Needs review » Needs work

The last submitted patch, core-js-jquery2-1974340-6.patch, failed testing.

aspilicious’s picture

Status: Needs work » Needs review

According to the jquery site, we should use 1.9 if we support IE8. The dual approach isn't recommended. Certainly because IE19 and IE10 can render inccorrectly if they are run in "compatibility mode".

If we all know these concerns and we still think this is the way to go I'm fine with that. I don't use IE anyways ;)

http://blog.jquery.com/2013/04/18/jquery-2-0-released/

You can (and should) continue to use jQuery 1.9 (and the upcoming 1.10) on web sites that need to accommodate older browsers.

No more support for IE 6/7/8: Remember that this can also affect IE9 and even IE10 if they are used in their “Compatibility View” modes that emulate older versions. To prevent these newer IE versions from slipping back into prehistoric modes, we suggest you always use an X-UA-Compatible tag or HTTP header. If you can use the HTTP header it is slightly better for performance because it avoids a potential browser parser restart.

Wim Leers’s picture

#8: Browsers != servers. An additional request can make a huge difference for a highly optimized site.

droplet’s picture

jQuery blog telling us use 2.0 on IE9 / 10 could be not safely. and suggest you to add X-UA-Compatible to force it rendering IE9 / 10 mode. We fixed the X-UA-Compatible issue: #1203112: Add X-UA-Compatible HTTP header. So I don't think it will be a problem.

dual approach always better than loading single script. :)

jcisio’s picture

#11 Handling static requests is not a problem for good server. For a "highly optimized site", the same server that serves 100 PHP requests/s (that already means thousands of online users) can easily handle 100x number of requests for static files, a server that is optimized for static files even does it better. Adding 1% more will change nothing. So servers hardly play a role here.

jbrown’s picture

Title: Use jQuery 2 in better browsers than IE8 » Use jQuery 2 in browsers better than IE8
FileSize
1.65 KB
355.93 KB

Reroll.

jbrown’s picture

Also, why aren't we supplying the minified version?

nod_’s picture

Because Drupal isn't relased yet. Helps debugging.

jbrown’s picture

FileSize
1.29 KB
356.2 KB

Better.

Wim Leers’s picture

#13: I was not talking at all about back-end performance or server load. I was talking about front-end performance ;) There a single additional HTTP request can make a very big difference. Especially on optimized sites.

NaheemSays’s picture

Is there an issue to fix the problems with the aggregation?

(I would think its best not to aggregate the bigger library files such as jquery at all?)

droplet’s picture

+++ b/core/misc/jquery/jquery-2.0.0.jsundefined
@@ -9574,24 +8719,37 @@ jQuery.each( { Height: "height", Width: "width" }, function( name, type ) {
+jQuery.fn.size = function() {
+	return this.length;
+};
+
+jQuery.fn.andSelf = jQuery.fn.addBack;
+

Is there any 3rd JS in CORE using these 2 function (and other deprecated function) ?

(I would think its best not to aggregate the bigger library files such as jquery at all?)

Yeah, on our non-Drupal application, we split it into verdor.js / app.js.

http://brunch.io/ framework do the same way:
"This is better solution for browser caching than using one file, because you change dependencies not as often as you change your application code."

Wim Leers’s picture

#19/#20: There is no single best way. For some sites it's better to have jQuery aggregated with the rest of the JS, for others it's the other way around. The only rule is that we shouldn't make it impossible. That's all I've been saying, really :)

seutje’s picture

This feels like a bad idea, mainly for reasons stated above (extra request, ...), but I can't really think of a better solution.

I could live with this, but I feel like there needs to be an easy way to opt-out and force it to use either 1.9 or 2.0 (in code or settings), so people who don't support IE8 can effectively drop support and still be able to aggregate jQuery with the rest.

catch’s picture

This is a release blocker for me, but I'd much rather figure out #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) or just drop support for IE8 altogether than mess around with dual versions here.

jcisio’s picture

Who cares about the extra request can simply implement hook_library_info_alter() to put jQuery 1.9 unconditionnally back. I think this patch could get in, then if we decide to remove JS support for IE8, we could easily remove jQuery 1.9 without much verification.

seutje’s picture

@23: This feels like a safer solution than #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) as I feel like IE8 will still be a factor come D8 release-day. Contrib can still come up with a no-js solution for IE8.

@24: Granted, easy enough for me.

nod_’s picture

nod_’s picture

Title: Use jQuery 2 in browsers better than IE8 » Update to jQuery 2
Status: Postponed » Needs review
FileSize
1.09 KB
352.4 KB

We're not supporting IE8 anymore #1993322: [Meta] Drop IE8 support, we only need jQuery 2, yay!

jQuery 1.9 can be added back in the IE8 module (patches welcome).

jbrown’s picture

Status: Needs review » Reviewed & tested by the community

This is fine!

cweagans’s picture

+1. So happy about this.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thanks!

nod_’s picture

Issue tags: +ie8

Added to IE8 module: http://drupalcode.org/project/ie8.git/blobdiff/0dafe7d352acc87914ba279d6...

Tagging to keep track of issues backported.

nod_’s picture

updated the change notice we used for jQuery 1.9: https://drupal.org/node/1966536

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

conditional comments comment.