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 request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- brion
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 <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky"
Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about scriptLoader: http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default )
I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard: http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wik...
peace, michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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@wikimedia.org wrote:
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 <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky"
Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about scriptLoader: http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default )
I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wik...
peace, michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net
savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- 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
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 built into the core could mean it might get a little bit more simple to do visually cool things, which might make the UI more intuitive.
-- Hay
On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev sergey.chernyshev@gmail.com wrote:
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@wikimedia.org wrote:
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 <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky"
Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about scriptLoader: http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default )
I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wik...
peace, michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net
savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- 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
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@gmail.com wrote:
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 built into the core could mean it might get a little bit more simple to do visually cool things, which might make the UI more intuitive.
-- Hay
On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev sergey.chernyshev@gmail.com wrote:
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@wikimedia.org
wrote:
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 <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky"
Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about
scriptLoader:
http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default )
I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wik...
peace, michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS
code
significantly so we can likely chop down wikibits.js, mwsuggest.js,
and
the site-customized Monobook.js files by a large margin for a net
savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- 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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Apr 16, 2009 at 2:35 PM, Sergey Chernyshev sergey.chernyshev@gmail.com 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@gmail.com wrote:
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 built into the core could mean it might get a little bit more simple to do visually cool things, which might make the UI more intuitive.
-- Hay
On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev sergey.chernyshev@gmail.com wrote:
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@wikimedia.org
wrote:
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 <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky"
Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about
scriptLoader:
http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default )
I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wik...
peace, michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS
code
significantly so we can likely chop down wikibits.js, mwsuggest.js,
and
the site-customized Monobook.js files by a large margin for a net
savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- 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
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
FWIW, if jQuery or any other JS libraries are being bundled into core software, extensions in SVN should be updated to not load them anymore, as they library will already be at their disposal.
Same goes for other non-JS bundled code, if any exists.
-Chad
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:
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@gmail.com wrote:
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 built into the core could mean it might get a little bit more simple to do visually cool things, which might make the UI more intuitive.
-- Hay
On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev sergey.chernyshev@gmail.com wrote:
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@wikimedia.org
wrote:
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 <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky"
Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about
scriptLoader:
http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default )
I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wik...
peace, michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS
code
significantly so we can likely chop down wikibits.js, mwsuggest.js,
and
the site-customized Monobook.js files by a large margin for a net
savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- 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
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
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,
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@wikimedia.org wrote:
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 <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky"
Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about scriptLoader: http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default )
I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wik...
peace, michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net
savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- 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
On Wed, Apr 15, 2009 at 11:05 PM, Brion Vibber brion@wikimedia.org 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 loader so we can serve more JS together in a single compressed request.
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).
Marco
On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster marco@harddisk.is-a-geek.org 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 Google Gears? Would HTML5's localStorage also be suitable?
On Fri, Apr 17, 2009 at 1:38 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster marco@harddisk.is-a-geek.org 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 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
On Fri, Apr 17, 2009 at 3:11 PM, Marco Schuster marco@harddisk.is-a-geek.org 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 support localStorage *now*, btw?)?
IE8 does, albeit maybe with a few quirks. I'm pretty sure the most recent Safari does, although Google is unhelpful on this point. Firefox 3.5 betas do. I don't know about Opera.
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.
All of those things should already be cached by clients. On stock Firefox 3, the only things my browser actually sends requests for (checking using the Firebug Net tab) on a typical page view is the page itself, and images specific to that page.
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).
That would be unreliable. The article might have changed, so you'd have to do an HTTP request anyway to get the 304. And in that case, again, the browser will have the HTML page cached already.
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 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 Fri, Apr 17, 2009 at 11:42 PM, Brion Vibber brion@wikimedia.org 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 interface.
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 reach multiple recipients - that's a PITA if you want send mails to multiple users.
- 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).
That sounds kinda interesting, even if the accuracy on non-GPS-enabled devices isn't that high... can this in any way be joined with the OSM integration?
Marco
On 4/17/09 6:45 PM, Marco Schuster wrote:
On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibberbrion@wikimedia.org 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 reach multiple recipients - that's a PITA if you want send mails to multiple users.
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.)
- Geolocation services
That sounds kinda interesting, even if the accuracy on non-GPS-enabled devices isn't that high... can this in any way be joined with the OSM integration?
It sure could! :)
-- brion
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 to uses).
I have worked on an AJAX application that sends email using a Javascript application and it turns out that the server was denying the JS requests because it went beyond the allowed limit of connections from a single host.
A better approach might be to start the task at the client side and save it ina queue at the server side for another process (server side) to take care of it later on in FIFO mode.
On Wed, Apr 22, 2009 at 12:18 PM, Brion Vibber brion@wikimedia.org 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.
On 4/17/09 6:45 PM, Marco Schuster wrote:
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 reach multiple recipients - that's a PITA if you want send mails to multiple users.
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 will just rely on bumping the $wgStyleVersion up global var to clear caches as not many projects besides mine are using JavaScript msg packing system yet ;) ... and there are other issues with the language packaging that need to be addressed. But I do check the latest revision id for every wiki page that is included via the scriptLoader. This has the nice benefit of once you save a gadget preference or update a user javascript page you don't have to "shift reload" as a new unique javascript request id is automatically generated.
2) Style sheet grouping is a bit tricky cuz you have to rewrite all the relative paths to a different relative position since its being served from the script server location. There is a library that handles this: http://code.google.com/p/minify/source/browse/trunk/min/lib/Minify/CSS.php but i have not integrated that yet...so style sheets are still individually requested. If we really want all the style sheets grouped I can bump that on the priority list to right after the upload api stuff that I have to finish up ;)
--michael
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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 brion@wikimedia.org 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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 Brian.Mingus@colorado.edu wrote:
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 brion@wikimedia.org 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 loader so we can serve more JS together in a single compressed request.
Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net
savings.
If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :)
-- 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
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
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
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
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
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 #2 or #3 loading... We already have the importScriptURI function which script use for loading when not using #1.
I do suggest we move away from importScriptURI to something like the doLoad function in mv_embed ... that way we can load multiple js files in a single request using the mediaWiki scriptServer (if its enabled). Right now all the importScriptURI stuff works non-blocking and included scripts need to include code to execute anything they want to run. To make things more maintainable and modular we should transition to objects/classes providing methods which can be extended and autoloaded rather than lots of single files doing lots of actions on the page in a less structured fashion. But there is no rush to transition as the scripts are "working" as is and the new infrastructure will "work" with the scripts as they are.
But the idea of the new infrastructure is to support that functionality in the future...
--michael
Sergey Chernyshev wrote:
No, my link is about 3 ways of loading:
- Normal script tags (current style)
- 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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 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
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 Brian.Mingus@colorado.edu wrote:
Many extensions are now using the Yahoo User Interface library. It would be nice if mediawiki included it by default.
wikitech-l@lists.wikimedia.org