Guys, It's great to see that you're working in this direction - I'm thinking about working on this for a while, but didn't have a gut to undertake such ambitious project alone ;) Do you have a working instance of ScriptLoader anywhere so I can aim some performance tools at it? Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale <mdale(a)wikimedia.org> wrote:

Speaking of libraries and all, I think it's worth merging libraries in general and figuring out a way for skin and extension developers to include libraries in the way that system can only: - include a library once - include latest library unless absolutely necessary - maybe even load parts of the library on demand ( http://developer.yahoo.com/yui/yuiloader/ is an example of what I'm talking about). Maybe it's also worth adding some JS bundles functionality where main bundle is global JS to be loaded on all page and there can be more bundles to load the rest of the code on pages that need them. My point is that this decision could be made in MW and not in the extensions - system should know what is bundled where and ignore inclusion request on the page if, let's say, YUI is already loaded in main bundle. Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 15, 2009 at 6:53 PM, Hay (Husky) <huskyr(a)gmail.com> wrote:

mv_embed has some functions for doing exactly that. You can run something like: doLoad({list, of, classes, that, i need}, function(){ //code to run now that all those components have been included. } It plays well with the script loader and loads it all the requested components in a single scriptLoader request. If you have already loaded some of those libraries it skips the classes it already has available. and is a bit simpler than the YUI framework I think ;) --michael Sergey Chernyshev wrote:

On Fri, Apr 17, 2009 at 1:38 PM, Aryeh Gregor <Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com> > On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster > &lt;marco(a)harddisk.is-a-geek.org> > Are there any plans to use Google Gears for storage on clients? Okay, > people > > have to enable it by hand, but it shoulda speed up page loads for people > > very much (at least for those who use it). > > What, specifically, would be stored in Google Gears? Would HTML5's > localStorage also be suitable? > Isn't GG supposed to be an implementation of localStorage for browsers who don't support it yet (does any browser support localStorage *now*, btw?)? What could be stored is JS bits likely not to change THAT often, i.e. if Wikipedia is ever going to make a WYSIWYG editor available (Wikia has it!!!) its JS files could be cached, same for those tiny little flag icons , the wikipedia ball, the background of the page... maybe even some parts of the sitewide CSS. Actually, it could be expanded to store whole articles (then simply copy over or enhance http://code.google.com/intl/de-DE/apis/gears/articles/gearsmonkey.html - I'm gonna modify it for german Wikipedia when i've got some time). Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de

On 4/16/09 3:35 PM, Marco Schuster wrote: For those not familiar with it, Google Gears provides a few distinct capabilities to client-side JavaScript code. Equivalents of these features are being standardized in HTML 5 / WHATWG work, and some of them are already available in some production browsers without installing a separate extension. (Note that the first usage of Gears services on a site requires user interaction -- the user must click through a permission dialog -- so while you can make use of them for 'progressive enhancement' you can't do so transparently. The same isn't necessarily true of browsers implementing them natively.) * Caching static files locally under application control ('LocalServer') Most of the time not a huge win over simply setting decent caching headers. Main advantage is if you want to provide an offline mode for your application, you're more likely to actually have the resources you need since you can pre-fetch them and control expiration. Note there has been some experimental work on hacking some offline viewing/editing with Gears into MediaWiki: http://wiki.yobi.be/wiki/Mediawiki_LocalServer but a really full implementation would be hard to hack into our architecture. * Client-side SQLite database Local database storage can be useful for various things like local edit drafts, storage of data for offline viewing, etc. Note that anything stored client-side is *not* automatically replicated to other browsers, so it's not always a good choice for user-specific data since people may hop between multiple computers/devices/browsers. * Background JavaScript worker threads Not super high-priority for our largely client-server site. Can be useful if you're doing some heavy work in JS, though, since you can have it run in background without freezing the user interface. * Geolocation services Also available in a standardized form in upcoming Firefox 3.5. Could be useful for geographic-based search ('show me interesting articles on places near me') and 'social'-type things like letting people know about local meetups (like the experimental 'geonotice' that's been running sometimes on the watchlist page). -- brion

On 4/17/09 6:45 PM, Marco Schuster wrote: Perhaps... but note that the i/o for XMLHTTPRequest is asynchronous to begin with -- it's really only if you're doing heavy client-side _processing_ that you're likely to benefit from a background worker thread. (Background threads also cannot directly touch the DOM or any objects in your foreground thread. You need to pass stuff in and out through indirect messages.) It sure could! :) -- brion

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. It can be similar or simply using Google lib loader: http://code.google.com/apis/ajaxlibs/documentation/ Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 22, 2009 at 12:28 PM, Brian &lt;Brian.Mingus(a)colorado.edu&gt; 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 &lt;brion(a)wikimedia.org&gt; wrote:

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 &lt;mdale(a)wikimedia.org&gt; wrote:

On 4/22/09 9:28 AM, Brian wrote: Rather than bundling multiple separate libraries we aren't going to use in core code, I'd rather just make sure we've got a consistent interface for loading them. That might include, say, bundling up a YUI loader as an extension and having that marked as a dependency for automatic installation when you install your YUI-needing extensions. -- brion