https://bugzilla.wikimedia.org/show_bug.cgi?id=65865
--- Comment #5 from Krinkle <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
