Just a heads-up --
Michael Dale is working on some cleanup of how the various JavaScript
bits are loaded by the skins to centralize some of the currently
horridly spread-out code and make it easier to integrate in a
centralized loader so we can serve more JS together in a single
compressed req
These changes will probably result in some minor adjustments to existing
skins. (I will try not to completely break compatibility cuz I know
there are many custom skins out in the wild that would be no fun to stop
working once they update medaiWiki)
This consolidation of includes _may_ result
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,
That's great news. I've been programming in JavaScript quite a lot the
last few years and i think i would've probably gone insane if i hadn't
discovered jQuery. Especially for complex and intricate HTML
selections it's pretty amazing what you can do with jQuery.
Also, the fact that animations are
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
On Thu, Apr 16, 2009 at 2:35 PM, Sergey Chernyshev
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 lates
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
I have a branch I have made some initial commits to..
http://svn.wikimedia.org/viewvc/mediawiki/branches/script-loader/
(Its not ready yet)...will be great to have some tests to compare it
with... I will be sure to let you know when it is ready ;)
peace,
michael
Sergey Chernyshev wrote:
> Guys
On Wed, Apr 15, 2009 at 11:05 PM, Brion Vibber wrote:
> Just a heads-up --
>
> Michael Dale is working on some cleanup of how the various JavaScript
> bits are loaded by the skins to centralize some of the currently
> horridly spread-out code and make it easier to integrate in a
> centralized loa
oky... branch /branches/script-loader/ ready for wider testing
after you check out the branch you have to add $wgEnableScriptLoader =
true; to your local settings.
Things I don't tackle in this version of the scriptLoader:
1) checking the version of every msg string packaged in JS (right now I
On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster
wrote:
> 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 Goog
On Fri, Apr 17, 2009 at 1:38 PM, Aryeh Gregor
> wrote:
> On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster
> wrote:
> > 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 leas
On Fri, Apr 17, 2009 at 3:11 PM, Marco Schuster
wrote:
> Isn't GG supposed to be an implementation of localStorage for browsers who
> don't support it yet
I don't think Gears uses the localStorage API. It seems to use its
own APIs. But I've never used either, to be fair.
> (does any browser su
On 4/16/09 3:35 PM, Marco Schuster wrote:
> 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).
For those not familiar with it, Google Gears provides a f
On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibber wrote:
> * 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 interfa
On 4/17/09 6:45 PM, Marco Schuster wrote:
> On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibber wrote:
>> * Background JavaScript worker threads
>
> You mean...stuff like bots written in Javascript, using the XML API?
> I could imagine also sending mails via Special:Emailuser in the background
> to rea
There is an issue with running a foreground JS thread that is super fast and
might send a lot of request to the server. Heavy processing on the client
side would alleviate the load from the server (if possible) but it might
push another load on the server (in the presented example of sending emails
Many extensions are now using the Yahoo User Interface library. It would be
nice if mediawiki included it by default.
On Wed, Apr 15, 2009 at 3:05 PM, Brion Vibber wrote:
> Just a heads-up --
>
> Michael Dale is working on some cleanup of how the various JavaScript
> bits are loaded by the skins
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 s
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 loa
On 4/22/09 9:28 AM, Brian wrote:
> Many extensions are now using the Yahoo User Interface library. It would be
> nice if mediawiki included it by default.
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 interfa
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. T
This would be a great idea as the library is always updated and has a lot of
features for the front end.
On Wed, Apr 22, 2009 at 12:28 PM, Brian wrote:
> Many extensions are now using the Yahoo User Interface library. It would be
> nice if mediawiki included it by default.
__
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"
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 Ex
hmm right...
The idea of the scriptLoader is we get all our #1 included javascript in
a single request. So we don't have round trips that would benefit as
much from lazy loading so no need to rewrite stuff that is included that
way already.
I don't think we are proposing convert all scripts to
26 matches
Mail list logo