Re: [Wikitech-l] Skin JS cleanup and jQuery
On 4/17/09 6:45 PM, Marco Schuster wrote: On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibberbr...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
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 br...@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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
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 br...@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 so 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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
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 br...@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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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.min...@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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
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 md...@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 br...@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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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:
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 md...@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 br...@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
Re: [Wikitech-l] Skin JS cleanup and jQuery
On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster ma...@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? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
On Fri, Apr 17, 2009 at 1:38 PM, Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster ma...@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 -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
On Fri, Apr 17, 2009 at 3:11 PM, Marco Schuster ma...@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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibber br...@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
--
VMSoft GbR
Nabburger Str. 15
81737 München
Geschäftsführer: Marco Schuster, Volker Hemmert
http://vmsoft-gbr.de
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
On Thu, Apr 16, 2009 at 2:35 PM, Sergey Chernyshev sergey.chernys...@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) hus...@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.chernys...@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 md...@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-wikimediaorg/ 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 so 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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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) hus...@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.chernys...@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 md...@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-wikimediaorg/
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
so 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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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 md...@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-wikimediaorg/ 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 so 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
Re: [Wikitech-l] Skin JS cleanup and jQuery
On Wed, Apr 15, 2009 at 11:05 PM, Brion Vibber br...@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 -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin JS cleanup and jQuery
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 so 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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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-wikimediaorg/ 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 so 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
Re: [Wikitech-l] Skin JS cleanup and jQuery
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.chernys...@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 md...@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-wikimediaorg/ 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 so 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
