Friday, December 21st, 2007
Category: Prototype
<
>p
>In the world of client-side development, page size definitely matters and John-David Dalton is doing his best to improve this. Awhile back, he took on the task of trying to determine how to best optimize the 120k+ Prototype and Script.aculo.us libraries and get the best compression out of the files. He’s done an absolutely fabulous job in the past and continues to pack the libraries as new versions are released. He’s just released his new version of his compressed Prototype collection and
released it on Google Code.
This pack contains the following compressed versions of Prototype: 1.4, 1.5, 1.5.1.1, 1.6.0 and Scriptaculous: 1.7.1_beta3, 1.8.0. This release compresses Prototype and Scriptaculous around 10% more than regular gzipping.
Prototype’s lowest weighs in at 20.4kb.
Scriptaculous’ lowest weighs in at: 19.7kb.
Protoculous’ lowest weighs in at: 38.4kb.
Compressed forms of Scriptaculous are segmented to allow for custom builds of Protoculous/Scriptaculous.
He has included a common custom build with the pack, “Prototype+Effects”, which weighs in at around 26kb. That’s smaller than standard Prototype gzipped!
Protoculous also allows the loading of additional js files like Scriptaculous via: protoculous.js?load=one,two
You can download his collection here and included in the download is a readme file providing more details about his build.
- Prototyping Model
The prototyping model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built,...
- prototyping
The prototyping model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built,...
- Effective prototyping for quality software
The authors of "Effective Prototyping for Software Makers" discuss the benefits of prototyping, how anyone can create a helpful prototype, and how the...
- spiral model (spiral lifecycle model)
The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of...
- LUA
Prototype script...
Yay! I love it.
Is his technique manually or it can be done by an application? any blog post or somethin’ from him?
@phpcs – I format the code manually, fixing semi-colons and fixing references to $super. I run them through a compressor with quotes around the $super vars so they aren’t changed then fix their method arguments. I use Dean Edward’s Packer because it creates the smallest files. From there you can use a server side solution to gzip/version/and deploy the file. I use Prado (www.pradosoft.com) and their asset publishing capabilities.
I have a Blog but it’s currently in the early stages, I never have time to work on it.
- Cheers :)
very cool………. Prototype++
I think any article like this needs a big asterisk next to the sizes to note how using a packer like this affects parse time and therefore overall page latency. We experimented with integrating Dean’s Packer into Dojo’s build process but found that the time it takes to unpack the code via regex was nearly 100ms, and if gzipping was employed, the size on the wire wasn’t any different (which we expected). If you’re serving your content right, packing hurts, and if you’re not, it may still be a wash. Oof. As a result, our guidance to folks is to just pull it off of a CDN or a static resource server which is guaranteed to gzip it. Other toolkits (like jquery) have backed off from providing default-packed versions and now provide a choice (I can only assume for similar performance reasons).
Just wondering if we are any closer to a universal CDN for Ajax libs (all versions), or if the desire to minify and link cull means too many combinations to host? Agree with Alex on gzip over packing.
/be
@slightlyoff
I cannot agree more! See this article for more details:
http://www.julienlecomte.net/blog/2007/08/13/
Cheers!
You all will be pleasantly surprised to notice that Dean Edward’s Packer 3 has a “shrink variables” option that produces NO parse time delay because nothing is encoded. In fact if you were to read the readme_first.txt in my package you would also notice that I don’t recommend using JavaScript compression that encodes the source because of the delay you mentioned.
The file sizes in this post are of the “var shrunk†versions that were gzipped.
No asterisk is necessary because there is No parse delay.
:P
@jdalton
Packer still uses eval().
@MezZzeR – Dean Edward’s Packer 3 only uses eval() when compressing with the “Base 62 encode” option checked. If you just use “Shrink variables” then there is no use of the eval().
As a result, our guidance to folks is to just pull it off