I am aware of the Yslow thread, is that what your referring to? .. it seemed to end with not much resolution or people mentioning its not much of a problem given the current javscript library set... and it seemed to assume that we would lose debug functionality... Just wanted to mention it again since I think it will be a problem shortly and that the solution should be thought about. For example it would be nice if all javascript libraries defined in a common way the set of messages they use so that user-language message text could parse that and package the localized language messages into the request. That way you don't have to issue separate ajax requests for language messages and you only send out the text messages for the associative interface components of the JavaScript libraries that your interacting with. anyway as mentioned earlier I will try to experiment with a solution soonish. (if no one is working on this already) peace, michael Gregory Maxwell wrote:

The debug switch would modify the HTML output to point at the individual files with a GET seed ie myscript.js?<?php= date()?> or something of that nature bypassing the script loader altogether. The bulk of extra content is comments, code documentation and debug statements .. line preservation does not seem worth it. Debug output should be enabled via a GET debug argument, user preference or $wgConfigure variable. --michael Gregory Maxwell wrote:

that just means the minification is broken on their platform no? So we have to debug the minification on their platform not the debug output ... but sure as you mention a hundreds of single character whitespace lines will compress nicely. --michael Gregory Maxwell wrote:

We would have the script_server be passed a unique variable per SVN version of the mediaWiki (like we currently do with the static js includes) If their browser treats a new url with different get parameters as the same as some older version resulting in a cache mismatch then that is bad... Ideally we don't have broken transformations on our back end per our unique urls matched to the svn version of the file. Yes different output of js means different input for the client and yes different input could result in new unforeseen errors client side that don't manifest in the un-minimized code. We would of course want to do lots of testing with the minimized output. --michael Gregory Maxwell wrote:

Erm... so you're saying we should go and turn this: if(fooBar) { var baz = false; var x = 0; while(!baz) { if(x == 260) { baz = true; } if(x == 25) { runThis({ a: 'b', c: 'd' }); } x++; } if(x > 55) andRunThis(fooBar); } Into this: if(fooBar){ var baz=false; var x=0; while(!baz){ if(x==260){ baz=true; } if(x==25){ runThis({ a:'b', c:'d' }); } x++; } if(x>55) andRunThis(fooBar); } Minification killing debugging isn't just because of it destroying newlines. I honestly don't want to pop between places to debug things. Do remember that some of us like to debug within the browser. FireFox with FireBug for one very nicely lets me jump to where an error happened in the code and breakpoint it as well. Trying to do that with a mess like that even if you don't touch newlines is still troublesome to read. You can hardly tell where something starts and where something ends. But not only that, plenty of the optimization that comes from minification is because it completely removes comments. There's little point to minifying if you're only going to minify half way. You get the worst of both worlds. Hard to read code, and your filesize still hasn't changed much. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) ~Profile/Portfolio: http://nadir-seen-fire.com -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com) Aryeh Gregor wrote:

Aryeh Gregor schreef: Why don't we benchmark this on the actual MediaWiki JS? Roan Kattouw (Catrope)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aryeh Gregor wrote: Aye, that's been on my wishlist. :D It will require changes to a few remaining bits of script that do inline scripting assuming wikibits.js is already loaded, such as the ToC and edit toolbar, but that's a good idea anyway. (Attaching some event handlers through script which are currently inline would also be good, to ensure functions aren't called before they've been loaded.) - -- brion

Michael Dale schreef: I suggest we re-evaluate our decision when we actually *reach* that situation in the future (assuming that'll even happen). Introducing minification now because we *might* need it in one *possible* future seems kind of pointless to me. We should base our decision whether or not to minimize on the *current* situation, and re-evaluate when the situation changes significantly. Roan Kattouw (Catrope)

On Mon, Dec 15, 2008 at 2:39 PM, Jared Williams &lt;jared.williams1(a)ntlworld.com&gt; wrote: Link?

Jared Williams wrote: I don't see how it will help. The client still needs to download it. Be it the dictionary or the JS. What could be benefitted from SDCH are is skin. Instead of transmitting the skin, diff borders, etc. all of that would be in the dictionary, decreasing the transfer per page.

On Mon, Dec 15, 2008 at 6:05 PM, Jared Williams &lt;jared.williams1(a)ntlworld.com&gt; wrote: Except that if you can do that, you can fetch the ordinary JS anyway and keep it until it expires. If clients actually did this, you'd be talking about single-digit JS requests per client per week, and further optimization would be pointless. The fact of the matter is that a significant percentage of views have no cached files from Wikipedia, for whatever reason. Those are the ones we're concerned with, and your idea does nothing to help them. It looks to me like you're talking about hugely increasing the size of the first page view on the optimistic assumption that first page views account for only a very small percentage of hits. Why do you think that assumption is warranted? One possible use of SDCH is that it would allow us to refrain from re-transmitting the redundant parts of each response, most of the skin bits. But that's probably under a couple of KB gzipped, so we're not talking about much savings here. It might even take longer to compute and apply the diffs than to transmit the extra data, over typical hardware. On Mon, Dec 15, 2008 at 7:57 PM, Jared Williams &lt;jared.williams1(a)ntlworld.com&gt; wrote: What leads you to believe that the client will actually *keep* it for months? Caches on clients are of finite size and things get evicted. The oldest file I have in Firefox's cache right now is from December 12, three days ago: $ ls -lt /home/aryeh/.mozilla/firefox/7y6zjmhm.default/Cache | tail -rw------- 1 aryeh aryeh 22766 2008-12-12 09:34 14C66B37d01 -rw------- 1 aryeh aryeh 28914 2008-12-12 09:34 20916AFCd01 -rw------- 1 aryeh aryeh 59314 2008-12-12 09:34 57BFF8A6d01 -rw------- 1 aryeh aryeh 39826 2008-12-12 09:34 9EB67039d01 -rw------- 1 aryeh aryeh 52145 2008-12-12 09:34 A2F75899d01 -rw------- 1 aryeh aryeh 18072 2008-12-12 09:34 C11C3B29d01 -rw------- 1 aryeh aryeh 25590 2008-12-12 09:34 C845BED2d01 -rw------- 1 aryeh aryeh 32173 2008-12-12 09:34 D69FA933d01 -rw------- 1 aryeh aryeh 45189 2008-12-12 09:34 F2AD5614d01 -rw------- 1 aryeh aryeh 25164 2008-12-12 09:34 DBA05B7Bd01 A fair percentage of computers might be even worse, like public computers configured to clean cache and other private data when the user logs out. Concatenating the (user-independent) wikibits.js and so on to the (user-dependent) page HTML will prohibit intermediate proxies from caching the user-invariant stuff, too, since the entire thing will need to be marked Cache-Control: private. It will prevent our own Squids from caching the CSS and JS, in fact. What happens if you have parser functions that depend on the value of $1 (allowed in some messages AFAIK)? What if $1 contains wikitext itself (I wouldn't be surprised if that were true somewhere)? How do you plan to do this substitution anyway, JavaScript? What about clients that don't support JavaScript?

Jared Williams wrote: Note that SDCH is expected to be then gzipped, as they fulfill different needs. They aren't incompatible. You would use a dictionary for common skin bits, perhaps also adding some common page features, like the TOC code, 'amp;action=edit&amp;redlink=1" class="new"'... Having a second dictionary for language dependant output could be also interesting, but not all messages should be provided. Simetrical wrote: /Usually/, you don't create the dictionary output by hand, but pass the page to a "dictionary compresser" (or so is expected, this is too much experimental yet). If a parser function changed it completely, they will just be literals. If you have a parametrized block, the vcdiff would see, "this piece up to Foo matches this dictionary section, before $1. And this other matches the text following Foo..." Jared wrote: Please share?