[wp-hackers] Packing JavaScript

[Otto]

On 9/18/07, Alex Günsche <ag.ml2007 at zirona.com> wrote:
> If the code is already packed so much, how could I come out with
> reducing the size by 50% with that other packer? ;-)

That's easy: you failed to pay attention to what I actually said.

jQuery is JS-packed already. The rest are not, but I was pointing out
the lack of benefit to packing most of it.

> Not exactly. Mod_gzip and others deflate the file, while they do not
> reassemble the code itself.

Okay...
1) It's not "assembled" in any sense in the first place, because it's
*scripted code*.
2) You missed my point here as well. The *only* point of packing
javascript is to reduce filesize and thus reduce bandwidth usage. You
can sometimes also do that by gzipping the files and serving them that
way.
3) I was drawing a comparison here and making a statement about what's
best for WordPress, not suggesting this method as a course of action.

> Have a look at one of the packed files (e.g.
> at the MooTools download page) to see what is meant by packing the JS
> code.

I know what packed JS code is. I'm not new at this, thanks.

> It is possible to combine compression and packing to get even
> better results.

Not by much. And it only makes page rendering that much slower.
Admittedly, packed JS code reduces page rendering time by a *lot* more
than mere compression does, but both is still worse than either one.

> I think that if a WordPress-based packaging turns out to be efficient,
> secure (in the sense of code integrity) and easy maintainable,
> WP-internal packing should really be considered.

Well, I don't, for the reasons I gave before. Perhaps you missed those
reasons, so I'll try again:
1) Rolling your own packing makes no sense from a maintainability
standpoint, as you are packing 3rd party libraries and it would make a
lot more sense to use their pre-packed versions, where available.
2) It is not possible to create a packing system that works on all
javascript code all the time, so any packing systems you make may
break in the future when the library changes.
3) Bandwidth reduction is often better achieved by compression, and
this is arguably a server side thing to do.
4) The amount of bandwidth reduction produced by JS packing is
arguably not worth it in some cases, as it adds a significant amount
of processing overhead to the client side of the equation.

> The standard libs would still be provided as source. And plugins will
> still be able to use the packed libraries, as the function names and
> public variables are preserved. If they weren't, the compression would
> be completely senseless in the first place.

Argh...
a) You cannot guarantee that any given approach of JS-packing will
work for all libraries and all cases unless you have a test suite for
all those cases.
b) Even if it works with the WordPress code, WordPress is not the only
piece of code using those javascripts that you propose to pack.
c) Providing them as source is not what I was getting at, although I'm
against providing both source and packed versions in the distribution
in any case as it's needlessly making the distribution larger.

> However, maybe it would be possible to provide the WP admins the option
> to chose whether they want the JS compressed or not. If they don't want,
> the src file will be delivered.

Yet more useless admin options is not what we need in WordPress. Pack
or don't, but don't give an option.