... I was looking at commons upload form JavaScript load profile is like a long waterfall or rather a steep river :( http://metavid.org/promo/round_trips.png
Would be much nicer do 1 or 2 request instead of 27 ... true... a lot are gadgets and what not.. but even on a not logged in Main page visit on En we hit 6 scripts all loading one after another...
The patch to switch over to the script loader involves a lot of conditionals in a lot of skins... the majority of the scripts get piped through page serving so a fix to import & group js per wikiTitles would be added ... (and we would pass along their revision id in the url for caching support)... all the existing code would run "as is" where the scriptLoader config var is turned off. While I am touch all of those parts of the code I might as well pass the css loading to a loader/grouper as well.
if we are going this way... I will take a pass at making a patch since it would make other pieces I am working on a lot easier to integrate with localization.
comments in-line:
Brion Vibber wrote:
On the other hand we don't want to delay those interactions; it's probably cheaper to load 15 messages in one chunk after showing the wizard rather than waiting until each tab click to load them 5 at a time.
But that can be up to the individual component how to arrange its loads...
right ... I used the "tab" example since its a natural load point since we have to load the JSON search results for the requested query the interface already displays a little loading animation ... but as Mr. Maxwell points out given latency its better to front load a lot more ... that can easily be tweaked towards more front loading ... but if we have a dozen remote archive integrations maybe not so fun to load them all at initial run time or maybe you don't want to load the video player js code for people just interested in grabbing images...or in video sequences loading all the transitions and all the filters when only fade to black is used.
anyway .... the idea is it gives developers more flexibility in choosing what js classes they want to load at any point in time without inuring HTTP latency request costs for logical modularization of js code into separate files. Likewise we don't want to /have to/ front load all the msg text even if we choose to do that for /most/ cases for performance reasons.
I'm a bit less certain about this; primarily it creates redundant copies of message text between the .js and the .i18n.php files, which is a maintenance problem.
Secondarily, it means you lose localization support if you disable the JS serving. Currently we do JS localization by doing the lookups in PHP and exporting those as JS variables or writing them directly into calls to JS functions in the HTML output. This kinda sucks because of the degree of manual intervention, but a more basic 'list out which vars you need and export them' should be straightforward and avoids the duplication.
I would like to eventually take out the msg from the javascript files and only store a key list in js and the full Msgs only in the php. ... but for now will just have to deal with duplication... yes it makes things a bit bothersome... but retains portability and flexibility while we iron out and standardize the script loader. Once the script loader is solid it should be adaptable to being used in other CMSs so we can retain portability and localization and just require the script loader.
There may also be difficulties with handling the distinction between message lookups which need to go to content language and those which need to be in the UI language... we also would rather not lose the ability to use language-specific features like {{PLURAL:}} and {{GENDER:}} which are needed for proper localization of many languages.
yea these parts are a bit tricky... I imagine we can detect if we ever touch those magic words in the msg key list and then export some additional json keys for a script to use in cases of contextual swapping.... meaning our js will have to parse those magic words mirror their logic and then swap based on additional keys proved in the language packing.
(Note for those who didn't peek at the code -- this is overridable at runtime with ?debug=true on the script load; we'd presumably want to be able to pass that on from web page views as well.)
added debug var check from web page views in r47713 ...
I did not mention it last time but we also include js code to take advantage of the script loader system. It passes along any debug request or unique svn id, auto checks all the libraries as to not request anything that is already loaded, and groups the requests using the script loader. So once you have mv_embed lib in place you can "auto load" libraries with:
mvJsLoader.doLoad({ 'libname' : 'lib_location_in_case_script_loader_is_off', 'lib2' : 'lib2_location'}, function(){ //code to run now that the all the libs are ready });
Like the localization msg system this logic is hampered by the fact the script loader is /optional/. If we required the script loader it could be simpler:
requireOnce( {'list', 'of', 'libs', 'to', 'load'}, function(){ //code to run now that the libs are ready });
peace, --michael