JSAN.use() and x-browser caching strategies

[Rob Kinyon]

First off, I want to apologize for any comments I have made in the
past that sound like I know what I'm talking about vis-a-vis this
topic. While I know JS as a language, I don't know JS as a technology
as well as I need to, especially when it comes to browser-dependent
behavior. In addition, if anyone wants to correct me in anything I
say, please do so without fear that you will hurt my feelings.

Second, this is a LONG email. Before responding, please take the time
to read it all. If you want to respond to one part, please consider
creating another thread (with a different subject) that refers back to
this one. The subject is how GoogleGroups threads responses.

Recently, I've been working with Casey West and Adam Kennedy on
getting JSAN.js to reduce the number of XMLHttpRequests it makes.
Currently, it uses XMLHttpRequest + eval() (hereafter known as the XHR
method) to do the load of a given library. Some browsers, such as IE,
will cache the results of an XMLHttpRequest if the right settings have
the right values. Other browsers, such as Firefox, seem to refuse to
do so, regardless of what's attempted. This means that a single
JSAN.use() statement may result in 3-10 XHRs per pageload, even if the
code in question has already been previously seen in a prior page.

This topic was brought up in the first days of this project, and
various strategies have been suggested and some have been implemented.
However, I cannot find a single document that discusses them, their
strengths and drawbacks, and what's needed to implement them from a
user's perspective. I'd like to remedy that. Hopefully, this thread
will get enough information in one place so that we, as a group, can
make up for the shortcomings in Javascript. (Who designs a dynamic
language in the modern era without making provision for libraries??
COBOL has libraries ... why doesn't Javascript?!?)

There are two caching levels, as I see it.
1) Page-level : this is where the same library is requested only once
per page load.
2) Session-level : this is where the same library is requested only
once per browser session. All session-level strategies are, by
definition, also page-level strategies.

The strategies, as I know them, consist of the following:
1) XHR - this is the strategy currently implemented in JSAN.js v0.10.
It depends completely on whether the browser caches XMLHttpRequests
for its session-level caching. It does provides for something similar
to Perl's %INC, page-level caching is there. This requires nothing
special on the server or client.

2) Serverside strategies - this is epitomized in Dave Rolsky's
JSAN::ServerSide, available on CPAN. Basically, the webserver will
modify the outgoing page so that all the dependencies are in the page
as <script> tags, in the right order. All modern browsers cache the
results of <script> tags, so this provides for session-level caching.
This requires mod_perl on the server.

3) Install-time concatenation - this is where the installer
(JSAN::Shell or JSAN::Shell2) would modify the library so that it
contained all of its dependencies within it. The user would then load
the library in a <script> tag, triggering the browser's session-level
caching. I'm not sure how this would play out, especially if a
dependency is updated or if a dependency is also loaded.

4) JS header files - this is a second file containing the dependencies
would be created, either manually or with some tool. JSAN.use() would
then be rewritten to use either DOM injection or document.write() to
add TWO <script> tags on the fly. The first would be the header (.jsh)
file and the second would be the code (.js) file. This similar in
concept to the bootstrap script that MochiKit uses. This requires
nothing from the user, but it does require some work on the part of
the developer. In addition, some scenarios still don't work, such as:
<script>
JSAN.use('Foo.Bar');
var x = new Foo.Bar();
</script>

If I missed anything, please add it.

I'm not looking for the "One True Way"(tm). Several of these
strategies can be used in tandem. What I am looking for is group
consensus on the "One True Way"(tm) for each of these strategies, and
also if the group feels that a strategy sucks too much, that it should
be dropped. I feel we need to bring the group's talents to bear on a
few good methods, so that we can speed adoption and get this monkey
off the project's back. The first question people ask me is "What's
performance like?" and I have to tell them "It can suck, depending on
the client." At that point, I lose them, and that's a "Bad Thing"(tm).

Thanks,
Rob