Perhaps you could get around this by using SSIs to include the javascript libs in the data sent to the browser rather than "<script src=...">? That would also speed up loading (although only marginally, but you did say modem, didn't you? :-) times as it would reduce the number of requests the browser has to send, so less headers send & received and less delays connecting.

Well, thats an excellent point.. and if SSIs wouldn't do, I could always use something like HTML::Template's TMPL_INCLUDE system to do the same thing.

However, there is an advantage to using the <script src=...> -- When you use it, you are allowed to include a host other then the one the original HTML file was loaded from. So if you're browser requests
http://www.foo.com/pizza.html

And thats actually legal. Now, it maybe possible to do something similar with SSI. However, you could use those script lines to load JavaScript after the original document had been loaded.. dynamicly choosing which document to load. Lets say, in our pizza example, that the user has three buttons -- one labeled pepperoni, one sausage, and one pinapples. By clicking one of them, you can use a hidden frame to have the browser go out and grab that JavaScript file -- whatever site it may be on, without making the browser reload any content.

I hope that made sense :-) I have a project that makes use of this sort of thing, called OpenThought. It's all about delivering content to a web browser without making the pages reload. The code will be in CVS within a day, and you can read the current documentation at the website.
-Eric