Spurned by Prototype
Category rants
As work continues on XIDED (the next beta release, which will add support for views and folders, will be ready soon), I've been looking into additional ways to reduce the page weight. The entirety of the application's JavaScript - which includes Prototype, portions of the YUI, yui-ext, and XMLJS in addition to the application-specific code - weighs in at 970 KB, when combined into a single .js file with no minification. Basic minification (removal of tabs and line breaks) drops this to 645 KB. Running that through Packer further reduces it to 336 KB. Finally, gzip drops this to a measly 124 KB. There's just one problem - in order for the browser to decompress gzip, the server must include a Content-Encoding header... and there's no way to do that in Domino on a per-file basis. Actually, there might be a way, but it'd be ugly: put the .gz somewhere the server can find it (on the file system, attached to a document or design element, etc.), then point the script URL to an agent that loads the file as a stream, sets the appropriate headers, then streams the content to the browser. That would probably do the trick... but that seems like overkill to me. So for now I'm settling for 336. UPDATE: there's a much easier way.
But Prototype 1.5 is out now. The real thing, not 1.5 RCx, and I want to update my build... but Packer gets pissy when packing messy code. Let me be clear: I'm not dogging the innovation in Prototype; I think most people would agree that functionally it's very well-written. But syntactically it's messy. For example (randomly selected from a multitude of similar snippets):
if (--count < 0) return match[0];
Now, I'm not saying it absolutely has to be this:
if (--count < 0) {
return match[0];
}
But why not this:
if (--count < 0) {return match[0];}
Not as readable without the extra whitespace, but at least it's not brittle. It takes almost no extra time to do if the formal syntax is adhered to when the code is originally being written, but is very time-consuming to identify and correct later on. Another example:
String.interpret = function(value){
return value == null ? '' : String(value);
}
This should be:
String.interpret = function(value){
return value == null ? '' : String(value);
};
Tiny little miniscule difference, but that creates just one of many line breaks that can't go away without breaking the entire script. This limits the ability to minimize the file size, which impacts the user experience. Assuming I must not be the only developer out there who would like to see a syntactically correct version of Prototype, I entered a ticket requesting that the formal syntax be used going forward, and received a response from one of the developers, who, despite being described in his bio as being a standardista, stated that the primary reason similar requests have been rejected in the past is that "our code is valid JavaScript and we don't feel like changing style" (emphasis his). Well, window.open is valid JavaScript, but we're seeing less and less of that these days, at least among the conscientious.
Four hours after the original response, another arrived:
So I'll wait and see if they decide that "changing style" (read: adhering to JavaScript syntax standards) is worthwhile. In the meantime, I'm going to gauge the scope of effort involved in replacing all calls to Prototype in XIDED with the mootools equivalent; like YUI and yui-ext, mootools is separated into functional components, allowing you to download only what you need. At first glance, it appears that the portion of mootools that XIDED would need compresses to 14 KB, compared to Prototype's uncompressed 70 KB.
As work continues on XIDED (the next beta release, which will add support for views and folders, will be ready soon), I've been looking into additional ways to reduce the page weight. The entirety of the application's JavaScript - which includes Prototype, portions of the YUI, yui-ext, and XMLJS in addition to the application-specific code - weighs in at 970 KB, when combined into a single .js file with no minification. Basic minification (removal of tabs and line breaks) drops this to 645 KB. Running that through Packer further reduces it to 336 KB. Finally, gzip drops this to a measly 124 KB. There's just one problem - in order for the browser to decompress gzip, the server must include a Content-Encoding header... and there's no way to do that in Domino on a per-file basis. Actually, there might be a way, but it'd be ugly: put the .gz somewhere the server can find it (on the file system, attached to a document or design element, etc.), then point the script URL to an agent that loads the file as a stream, sets the appropriate headers, then streams the content to the browser. That would probably do the trick... but that seems like overkill to me. So for now I'm settling for 336. UPDATE: there's a much easier way.
But Prototype 1.5 is out now. The real thing, not 1.5 RCx, and I want to update my build... but Packer gets pissy when packing messy code. Let me be clear: I'm not dogging the innovation in Prototype; I think most people would agree that functionally it's very well-written. But syntactically it's messy. For example (randomly selected from a multitude of similar snippets):
if (--count < 0) return match[0];
Now, I'm not saying it absolutely has to be this:
if (--count < 0) {
return match[0];
}
But why not this:
if (--count < 0) {return match[0];}
Not as readable without the extra whitespace, but at least it's not brittle. It takes almost no extra time to do if the formal syntax is adhered to when the code is originally being written, but is very time-consuming to identify and correct later on. Another example:
String.interpret = function(value){
return value == null ? '' : String(value);
}
This should be:
String.interpret = function(value){
return value == null ? '' : String(value);
};
Tiny little miniscule difference, but that creates just one of many line breaks that can't go away without breaking the entire script. This limits the ability to minimize the file size, which impacts the user experience. Assuming I must not be the only developer out there who would like to see a syntactically correct version of Prototype, I entered a ticket requesting that the formal syntax be used going forward, and received a response from one of the developers, who, despite being described in his bio as being a standardista, stated that the primary reason similar requests have been rejected in the past is that "our code is valid JavaScript and we don't feel like changing style" (emphasis his). Well, window.open is valid JavaScript, but we're seeing less and less of that these days, at least among the conscientious.
Four hours after the original response, another arrived:
| Adding #7201 (patch to make Prototype lint-safe) to the above list ... This is getting out of hand. We will have an internal discussion about this. I'm not closing these tickets anymore until the matter is resolved properly. |
So I'll wait and see if they decide that "changing style" (read: adhering to JavaScript syntax standards) is worthwhile. In the meantime, I'm going to gauge the scope of effort involved in replacing all calls to Prototype in XIDED with the mootools equivalent; like YUI and yui-ext, mootools is separated into functional components, allowing you to download only what you need. At first glance, it appears that the portion of mootools that XIDED would need compresses to 14 KB, compared to Prototype's uncompressed 70 KB.
Comments
Posted by Tim Tripcony At 00:36:15 On 02/08/2007 | - Website - |
I used to like prototype but after a few months studying what YUI and YUI-Ext has been doing, I find that I prefer their style of Javascript (putting everything under the YAHOO namespace) over prototype's (tons of global functions). For my Domino Web Tools project I think I'm going to just use the yui-ext stuff. Perhaps we can share tips and tricks with working with yui-ext in domino.
Jack
Posted by Jack Ratcliff At 22:52:11 On 02/07/2007 | - Website - |