[wp-hackers] Re: Packing JavaScript

[Alex Günsche]

On Wed, 2007-09-19 at 10:42 -0500, Otto wrote:
> Consider that almost all of these files are 
> libraries acquired from elsewhere. If they offer a packed version
> directly, fine, use that.

Why? If they don't offer packed versions, why can't we pack it ourselves?

>  However, packing them ourselves will a)
> probably break things and b) require us to repack and retest them
> every time we upgrade to a new version. It's not worth it.

Here, my friend, it's you failing to understand previous discussion
entries:
a) It was mentioned a couple of times in this discussion that there are
save packers like YUI.
b) Packing is a matter of a few seconds, and it can be automated.
Switching can be done at code level with a little global variable or
constant attached to the file name to include.

> If you want to pack your own JS, do it. If you want to make a plugin
> to pack the JS files for users, do that. But this is outside the scope
> of the core code.

I disagree.

The fact is, as I already mentioned, that a large part of WP users has
not the ability to use gzip or similar technologies. And we saw during
this discussion so far that fat bandwidth is by no means a standard
these days. I also agree that JS is rather an issue of the admin area,
but especially for multi-user communities based on WPMU, it could be
nice to try some optimization.

To summarize the discussion a bit, there are various possible methods to
improve the performance of JS transmission to the client:

- compression (mod_gzip, php_gzip or similar)
  * advantages: smaller amount of data to transfer
  * disadvantages:
    - slight overhead of packing and unpacking,
    - not available on many hosts
- packing (D.E.'s packer, YUI, others)
  * advantages: smaller amount of data to transfer, especially where
    real compression is not an option
  * disadvantages: bad packers can break JS syntax and API
  * countermeasures:
    - use a save packer
    - fix JS with a packer in mind
    - fix the packed JS
    - apply packing only to some files
- merging into one file
  * advantages:
    - reduce number of HTTP requests
    - allows even better compressing as well as packing
  * disadvantages: needs remodeling of the core JS management
  * contermeasures: evalutate if it's worth it; if so, do it

Apart from that, we have:
- selecting only required JS
  * is mostly done already, at least in the newer series
- Avoid inline JS
  * deliver JS in dedicated files
- support proper client-side caching
  * mostly an issue of HTTP headers, the appended version string is
    useless until the server sends the proper headers
  * related to merging all JS into one file, because JS must run through
    WP before output

I agree that not *everything* of this must be core features. However,
you won't accomplish most of these features if you don't have the proper
interfaces in the core.

And, Otto, just because something is beyond your imagination, you don't
have to oppose it.


Kind regards,
Alex

-- 
Alex Günsche, Zirona OpenSource-Consulting
Blogs: http://www.zirona.com/ | http://www.regularimpressions.net
PubKey for this address: http://www.zirona.com/misc/ag.ml2007.asc