Last modified: 2014-07-28 18:08:38 UTC
jQuery 2.x has the same API as jQuery 1.x, but does not support Internet Explorer 6, 7, or 8. Mobile doesn't support IE 6,7,8. Let's join the future and use this instead and get a lighter JavaScript footprint.
Well, if we want to use something different, why not Zepto then?
I think using a different version of jQuery and risking breakage is not worth it: * jQuery 1.11.1: 37.91 KB gzipped (http://code.jquery.com/jquery-1.11.1.min.js) * jQuery 2.1.1: 33.58 KB gzipped (http://code.jquery.com/jquery-2.1.1.min.js) * Zepto.js 1.1.3: 9.77 KB gzipped (http://zeptojs.com/zepto.min.js)
Zepto is documented as having performance issues [1,2] and is not compatible (I've added Krinkle who worked on jQuery 2 so I'm sure he can elaborate on the why) I assume over time jQuery 2 will get smaller and more performant and more in line with what we are doing so this would be more of a long term strategic change than a short term one so I'm not basing this idea on the current gzipped sizes. That said I suspect there are issues with special casing the version of jQuery specifically for mobile, but I was interested in exploring this topic and its pros/cons for a future where maybe desktop doesn't need to support IE6-8. (FWIW I swapped out jQuery 1 for 2 on my local instance and everything in the mobile site worked as expected) Marking as feature request as I guess this is what it is on 2nd thoughts.
Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/bZScKFsq
I wouldn't be too worried about compatibility issues between jQuery 1 and 2. They are designed to have perfect API, feature (and bug) parity. And this is additionally ensured by loads of unit tests by upstream jQuery. The main points I'd like to weigh in: * Maintenance overhead of working with two copies. Relatively low impact and cost. Though it does impact a low-level module at the startup module level directly. This should work fine, but might cause issues. * Having the same module defined in multiple targets. Different ResourceLoader targets have their own reduced registry. So in theory it should be possible to register a module differently in each target. However this is currently not exposed. And we'll need to cover all our bases with regards to cache-keys needing to take 'target' into account in their fragmentation (ResourceLoaderContext hash, module definition hash etc.) * Flexibility issues. The gain is relatively small (a few kilobytes at most) and would then no longer allow the same request context to work for mobile and desktop. It also relates to how long we intend to keep the 'target' system around (in my opinion it should be removed at some point, it has too many issues, inflexibilities, maintenance overhead, and conceptual problems of how programs should be developed). If this relates to the skin, that would impose additional restrictions on having a skin work for mobile and desktop. Similar to when 'target' was first introduced, I oppose the system in general and am convinced we not need it and not want it in the long run. While individual features may or may not be relevant on different devices, at the module level a single module should aspire to work in all browsers, languages, skins, wikis and devices. "Mobile" should be no more of a speciality then different browsers. Sure, there'll be a few lines of code that are specific for Firefox and load in Chrome, and there'll be a hover-event bound that has no meaning, but we'll be good developer and also bind a touch event. Fragmenting the code base at this level is in my opinion a fundamentally flawed idea. And it's fine to deny that while working with an existing code base, but not in the long run.
Lastly, assuming the base motivation for this is performance; I'm pretty sure that there are much more notable and worthwhile areas to focus on when it comes to perceptive performance for the user's experience. Bandwidth is important, but http requests even more, and this is where general platform-wide improvements regarding minification and bundling come in. At the individual app level I'd recommend focussing on execution performance. A few slow DOM operations on every page triumph a few milliseconds of code parsing or one-time downloading (then cached). I don't have statistics at hand, but I believe Ori has done the necessary research on this in the past. It's not worth our time at the moment.
I think that mobile must stick with whatever core uses because we want to share code, e.g. enabling more desktop modules on mobile (preferrably not by default, of course:) and use mobile code on desktop (e.g. Nearby). While the two versions are supposed to be bugwards compatible, those always unavoidable differences will stil slap us hard.
This will potentially cause more problems than benefits. Closing, let's wait until we can use jQuery 2.x on desktop too.
