No, my link is about 3 ways of loading:
1. Normal script tags (current style) 2. Asynchronous Script Loading (loading scripts without blocking, but without waiting for onload) 3. Lazyloading (loading script onload).
Number 2 might be usable as well.
In any case changing all MW and Extensions code to work for #2 or #3 might be a hard thing.
Thank you,
Sergey
-- Sergey Chernyshev http://www.sergeychernyshev.com/
On Wed, Apr 22, 2009 at 1:21 PM, Michael Dale mdale@wikimedia.org wrote:
The mv_embed.js includes a doLoad function that matches the autoLoadJS classes listed in mediaWiki php. So you can dynamically "autoload" arbitrary "sets" of classes (js-files in the mediaWiki software) in a single http request and then run something once they are loaded. It can also "autoload" sets of wiki-titles for user-space scripts again in a single request grouping, localizing, gziping and caching all the requested wiki-title js in a single request. This is nifty cuz say your script has localized msg. You can fill these in in user-space MediaWiki:myMsg then put them in the header of your user-script, then have localized msg in user-space javascript ;) .. When I get a chance I will better document this ;) But its basically outlined here: http://www.mediawiki.org/wiki/Extension:ScriptLoader
The link you highlight appears to be about running stuff once the page is ready. jQuery includes a function $(document).ready(function(){ //code to run now that the dom-state is ready }) so your enabled gadget could use that to make sure the dom is ready before executing some functions.
(Depending on the type of js functionality your adding it /may/ be better to load on-demand once a new interface component is invoked rather than front load everything. Looking at the add-media-wizard gadget on testing.wikipedia.org for an idea of how this works.
peace, --michael
Sergey Chernyshev wrote:
Yep, with jQuery in the core it's probably best to just bundle it.
There is another issue with the code loading and stuff - making JS
libraries
call a callback function when they load and all the functionality to be there instead of relying on browser to block everything until library is loaded. This is quite advance thing considering that all the code will
have
to be converted to this model, but it will allow for much better
performance
when implemented. Still it's probably "Phase 5" kind of optimization, but
it
can bring really good results considering JS being the biggest blocker.
More on the topic is on Steve Souders' blog: http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/
Thank you,
Sergey-- Sergey Chernyshev http://www.sergeychernyshev.com/
On Wed, Apr 22, 2009 at 12:42 PM, Brion Vibber brion@wikimedia.org
wrote:
On 4/22/09 9:33 AM, Sergey Chernyshev wrote:
Exactly because this is the kind of requests we're going to get, I
think
it
makes sense not to have any library bundled by default, but have a centralized handling for libraries, e.g. one extension asks for latest jQuery and latest YUI and MW loads them, another extension asks for
jQuery
only and so on.
Considering we want core code to be able to use jQuery, I think the case for bundling it is pretty strong. :)
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l