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 :)
Comment | File | Size | Author |
---|---|---|---|
#27 | core-js-jquery2-1974340-27.patch | 352.4 KB | nod_ |
#27 | patch-nojQuery.txt | 1.09 KB | nod_ |
#17 | jquery-2.0.0.patch | 356.2 KB | jbrown |
#17 | interdiff.txt | 1.29 KB | jbrown |
#14 | jquery-2.0.0.patch | 355.93 KB | jbrown |
Comments
Comment #1
nod_forgot tags
Comment #2
cweagansMarked #1974236: Update jQuery to 2.0 as a duplicate
Comment #3
cweagansIf 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.
Comment #5
Wim LeersOne big concern: doesn't using conditional comments cause worse JS aggregation?
Comment #6
nod_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.
Comment #7
Wim LeersSPDY 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.
Comment #8
jcisio CreditAttribution: jcisio commentedSPDY 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.
Comment #10
aspilicious CreditAttribution: aspilicious commentedAccording 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/
Comment #11
Wim Leers#8: Browsers != servers. An additional request can make a huge difference for a highly optimized site.
Comment #12
droplet CreditAttribution: droplet commentedjQuery 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. :)
Comment #13
jcisio CreditAttribution: jcisio commented#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.
Comment #14
jbrown CreditAttribution: jbrown commentedReroll.
Comment #15
jbrown CreditAttribution: jbrown commentedAlso, why aren't we supplying the minified version?
Comment #16
nod_Because Drupal isn't relased yet. Helps debugging.
Comment #17
jbrown CreditAttribution: jbrown commentedBetter.
Comment #18
Wim Leers#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.
Comment #19
NaheemSays CreditAttribution: NaheemSays commentedIs 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?)
Comment #20
droplet CreditAttribution: droplet commentedIs there any 3rd JS in CORE using these 2 function (and other deprecated function) ?
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."
Comment #21
Wim Leers#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 :)
Comment #22
seutje CreditAttribution: seutje commentedThis 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.
Comment #23
catchThis 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.
Comment #24
jcisio CreditAttribution: jcisio commentedWho 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.
Comment #25
seutje CreditAttribution: seutje commented@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.
Comment #26
nod_meh. #1787012: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)
Comment #27
nod_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).
Comment #28
jbrown CreditAttribution: jbrown commentedThis is fine!
Comment #29
cweagans+1. So happy about this.
Comment #30
Dries CreditAttribution: Dries commentedCommitted to 8.x. Thanks!
Comment #31
nod_Added to IE8 module: http://drupalcode.org/project/ie8.git/blobdiff/0dafe7d352acc87914ba279d6...
Tagging to keep track of issues backported.
Comment #32
nod_updated the change notice we used for jQuery 1.9: https://drupal.org/node/1966536
Comment #33.0
(not verified) CreditAttribution: commentedconditional comments comment.