2010/9/6 Maciej Jaros <e...@wp.pl>: > At 2010-09-04 05:59, Trevor Parscal wrote: >> * Allows minification of JavaScript and CSS. > > Will JS/CSS developers/testers be able to disable this in preferences? > Like I said in my previous reply to Aryeh, you can use debug mode. This is a feature we probably should've mentioned in the OP.
>> * Allows deployment changes to all pages for all users within minutes, >> without purging any HTML. ResourceLoader provides a short-expiry >> start-up script which then decides to continue loading more JavaScript >> or not, and if so has a complete manifest of all scripts and styles on >> the server and their most recent versions, Also, this startup script >> will be able to be inlined using ESI (see >> http://en.wikipedia.org/wiki/Edge_Side_Includes ) when using Squid or >> Varnish, reducing requests and improving performance even further. > > So any change to MediaWiki:Common.js will refresh all script that are > minified? > We currently serve site JS (Common.js and skinname.js combined; this combining was done before RL too) separately because it needs to run at the very end. This is because it assumes it runs in the global scope, so it can't be wrapped in a closure. We also can't concatenate unwrapped site JS to the end of wrapped modules, because that will result in the site JS being executed before e.g. wikibits, which will also break. The only reliable way at this time is to include site JS separately after the mediaWiki.loader.go(); call. This means it's currently not combined with anything else, so invalidations of the site scripts won't invalidate anything else. Treating site JS like a normal module is only possible once site scripts have been ported to act like modules so they won't explode when wrapped in a closure. Depending on wikibits is fine as we already have dependency handling. >> * Help writing new code! While wikibits.js is now also known as the >> "mediawiki.legacy.wikibits" module, the functionality that it and >> basically all other existing MediaWiki JavaScript code provide is being >> deprecated, in favor of new modules which take advantage of jQuery and >> can be written using a lot less code while eliminating the current >> dependence on a large number of globally accessible variables and >> functions (see >> http://www.mediawiki.org/wiki/ResourceLoader/JavaScript_Deprecations ) > > Will jQuery be available for older skins too? If so won't it cause > problems for mobile browsers? AFAIK mobile jQuery will not be ready for > at least next few years. > Yes, jQuery will be served on every page load. However, the (short) startup script that contains the module registration information and loads the jquery and mediawiki modules checks the browser version for compatibility before doing the latter. Currently the only browser it considers incompatible is IE <6, but this list should probably be extended to include other stone age browsers and mobile browsers. For the latter, we can even do the redirect to the mobile site in that place so we don't load a ton of JS before deciding to redirect people. OTOH, it might be nice to put a mobile redirect script in the <head> so the browser doesn't have to render the entire page before it hits the redirect script. > I'm asking here because those that make gadgets (well me at least ;-)) > still try to make them work on Vector and Monobook. > That's one of the objectives here: to provide a common base library that everything in MW can build on, regardless of skin or whatever. To that end, we started serving jQuery on every page on Wikimedia wikis last week, and we already did so in trunk ($wgJQueryOnEveryPage) for a few months IIRC. > Sorry for not being very enthusiastic ;-). I see this as solving some > problems but creating new ones too. Not really complaining here, I think > minification is really needed now to get Wikimedia sites loading faster. > Which problems would this introduce? The ones you mentioned in this post have either already been solved or are trivially solvable. Roan Kattouw (Catrope) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
