John-David Dalton has spent some time compressing Prototype in a couple of ways to keep your download time to a minimum.

His package is a collection of Prototype versions 1.4, 1.5rc0, 1.5rc1, 1.5 final, and it includes original, formatted (proper semicolons, helpful for others who want to compress it), compressed, and ultraCompressed files. There is also a gzipped version of each library.

Yes, as with all compression there is more of an initial (1 time per page load) delay when starting up the script. I did not notice much, but then again my pc is relatively new. I did pack various compression types to give the dev a choice. The gzipped forms of the none compressed versions work well when sent from PHP/Other server side code and should be auto decompressed by the browsers that support it transparently (no lag).

The 14.4kb is actually a gzipped version, the none gzipped version is 19.6kb.

Comment by jdalton — March 9, 2007

Is this the same jd that was chatting with us about compression in jQuery? If so, great job man. 15kb for 1.5 final is really sweet. Any issues in terms of using the file at all?

Thanks Rey! 8). Great job supporting the jQuery dev community. The 14.4kb is the gzipped form and holds the warning of using gzip (gzip compat browser). As with any other gzipped file you have to send it via php or the like.

I really just included the gzipped files as a reference so the devs could see what size it would be when gzipped.

I did mention in the post and the readme that you need to set the charset to iso-8859-1 in the script tag when using the compressed forms. I have tested it working without adding the charset, but I like to be safe.

Included in the package as well is a link to the PHP gzip methods.

Comment by jdalton — March 9, 2007

If you just use the $() and ajax functions, try out moo.fx’s stipped down prototype.js here: moofx.mad4milk.net

Comment by Neato — March 9, 2007

Thanks for the info, I will compress that and include it as part of the package as well 8)

Comment by jdalton — March 9, 2007

what’s the reason for the ‘iso-8859-1’? we all learned happily coding in utf-8, didn’t we? Is there any reason i’m not aware of or is it just a preference of the author(compressing person ;-)). I know it’s no problem to mix the formats in different files anyway but it feels wrong.
and thank you for the work john david

To be honest I just used iso-8859-1 as a precuation. The chars used are printable and most range from charCode 0-255, some though are higher. Like I said I safley tested it without setting the charset to iso-8859-1.

Comment by jdalton — March 9, 2007

finally it can beat jQuery on file size.

“Competition” between jquery and prototype on file size is crazy talk. If you really cared THAT much about your file size, you would hand write all your javascript yourself so it would have only what your app needs. If you want to compare frameworks, lets talk about how productive they are or how easy the code reads.

Its great to see this packaged up and compressed for its own merits, but “beating” jquery is not one of them.

@Rob Danheim, I agree.
I have removed the charset iso-8859-1 from the examples and added the compressed form of prototype.lite from moo.fx

Comment by jdalton — March 9, 2007

@Donald, good point 8). As I mentioned before there may be some lag on startup esp with the ultraCompressed versions. In many cases the ultra Compressed versions are only a few kb smaller than the regularly compressed versions. If you feel the delay is too great try some of the other compressed versions I packaged or uses the formated version and run it through Dean Edwards packer, it will compress nicley (28.5kb) and uncompress fast as well.

OK. version 2a is up. I have included dean edwards packer versions of each Prototype version, as well as my custom version for each. Dean’s packer version of prototype actually comes in at 13.3 gzipped. 8)

Comment by jdalton — March 9, 2007

I’ve never understand why Prootype developers doesn’t write “crunchable or packable” code …. is this so hard to do?

Well done John-David Dalton … and good luck for every future Prototype version …

We did some testing here at CNET and found that startup costs for a compressed lib (such as the Dean Edwards algorithm) can take several hundred milliseconds to decompress. The space savings are impressive, but our problem is that the user must pay this unzip cost on every page load, even if the library is cached. Ultimately, we elected to just delint the file (no extra spaces, comments, line breaks, etc.).

In additional tests we found that the request time was sometimes nearly as expensive as the download (especially if you have numerous js files, which is why we concatenate our libraries together, as Mootools does).

A very nice – high quality – discussion about stuff that really matters – to us and to the experience of our visitors and customers. My compliments to all that are sharing their feedback and experiences. This is exactly the gold I’m digging for in sites like Ajaxian! Thanks!

@Aaron N. – I hear ya. I have done similar things in my projects. I’ve combine several small interface images into one image and use the CSS sprite technique to display them.

Also using multiple sub domains such as img1.mysite.com img2.mysite.com and so on will help open the simultaneous connections up to 6 from the default 2.

Something to note is that the original (none-compressed) prototype.js is 15.8kb gzipped (included in my package). When sending files gzipped the browser decompresses them on the fly transparent to the user (no millisecond delays).

Knowing that you could put all your scripts into a single file and gzip them to the user. When gzipped, however, I hear that they donâ€™t cache.

I had problems with IE while trying to use scriptaculous with it. The gzipped file would not work giving some errors on sortable.create, while switching to original 60kb version turned it back on. Maybe a scriptaculous bug though (in Firefox works fine). Experimented with charsets.

In addition to Andrea Giammarchi points, I found that the compressed version doesn’t work in Safari.

Comment by Stian — March 11, 2007

BIG mistake. I mean Aaron N.

Comment by Stian — March 11, 2007

@Stain – this seems to be an issue with sarafi and the keyword “throw”, Deans Packer removed some semicolons after ex: “throw e}” and it causes an error in safari, while “throw e;}” does not. I am looking into it and seeing if that is the root of the issue.

Comment by jdalton — March 11, 2007

@Artjom Kurapov – which compressed versions are you using with Scriptaculous? This article does mention that you can direct link to the gzipped file and it will work in most browsers (except safari), but you can put a simple browser check for that and feed safari the none-gzipped. The author did all the browser compat for you 8).http://joseph.randomnetworks.com/archives/2006/07/13/compressed-javascript/

Comment by jdalton — March 11, 2007

Useless talk. The size of the library does not mean anything at all. Everybody wants video and huge image everywhere and you dare talking about the file size of a js library ?
pfff useless, let’s talk about productivity, readability, effectiveness and such, shall we ?

Comment by noname — March 11, 2007

@Artjom Kurapov – I think that i would stick to sending gzipped files via php or the like src=”http://www.mysite.com/script.php?s=prototype” and have it read the prototype.js.gz (of the one you want) and have it spit out the proper gzip headers and things with the contents of the gz file.
Andrea Giammarchi has written scripts to do similer things and I am sure if you google around you will find all the “how to”
s to get it done 8).

Comment by jdalton — March 11, 2007

@Stain – I confirmed the “throw e;” semicolon is the issue for safari, i have been able to fix it for all compressed versions of 5.0 final. (will take some time to do it for all of the versions. When its done I will post a comment.

Comment by jdalton — March 11, 2007

Just for kicks I ran prototype-1.5.0.js through jsjuicer and then gzip and came out with a file 89 bytes even smaller than the ones in this post. If you have real compression available then the self-extracting scripts just make gzip’s job harder.

Comment by Adrian — March 11, 2007

Updated Protopress package to v2b. Now all compressed scripts work in Safari and Omniweb. Also I added another compression option “no white-space” and this gives a new smallest Prototype 1.5 final (13.0kb) gzipped. Other than gzip this file is not compressed and should experience no ms delay. There is now a total of 5 compression options per Prototype version + the gzipped versions of all of them, wew.

I am currently working on the new release candidate 1.5.1 and have gotten it to compress via Packer, but not Memtronics yet.

Comment by jdalton001 — March 11, 2007

jdalton,

thanks a lot for such great work!

Is it possible to do the same thing for some files from script.aculo.us?

The all famous effects.js from latest build (1.7.0), for example, is about 37KB

I am have had some people mention that. You can use the “nowhitespace”
js versions still and the gzipped form of it is actually the smallest
at 13kb. I will try to fix the problem asap. I have also compressed
v1.5.1rc2 and its in the Protopressed v2c.

Comment by jdalton — March 16, 2007

@jdalton: I checked your nowhitespace source and I think there are even more compress options to that js file. But at this point it will be nasty and you really should use a pen and a paper to keep track of changed names.

If I remeber correct (slap me if I am wrong) also in JavaScript local defined variables in a function stay local and do not pollute the global namespace. With that in mind you can shorten all local variables to one-letter names. If the function/method name keeps the same, all Prototype functions should be still accessible.

Crap! my full comment is not accepted here. Strange. Anyway long story short: in your ‘nowhitespace’ file you can shorten all local variables to one-letter variables. This should not harm the framework. And this.object or function(arguments) could be shorten to this.O and this(A) etc.