You can already achieve most of what you're asking for by taking advantage of HTTP caching on the javascript file(s), using urls for the javascript files that contain your version number (eg http://mysite.com/myjsframework/v1.3/myframework.js) and something like the following in the web server response headers:
Cache-Control: public, max-age=<some large number of seconds> or Expires: <some date far in the future> (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13 ) This helps eliminate the latency of fetching the javascript from the network, but doesn't address a second part of the cost which is the time to parse the code. I've wondered if there is some efficient binary representation of parsed javascript that we might serialize in the cache, but am not aware of any work to actually do this (or whether it would be a substantial performance win - presumably it would depend on the size and complexity the javascript code in question). On Tue, Jan 6, 2009 at 8:46 PM, Carlos J. López <[email protected]> wrote: > > Hi there, > > Since January 2007 I've been using and developing my own JavaScript > framework only adding the functionality needed in my projects, so that > i would get a minimum amount of code for the client browsers to > download, i have even created a mid-position file between the client > and the server pages that compiles the info sent to the clients > removing the "new line", "more than one space" and the "tab" > characters, receiving the client one line of content. I got great > results out of it. > > But even after all those efforts I'd like to take it further and make > it work faster, then for a while I've been thinking how if I could > save my JavaScript framework into a browser variable, cookie, or some > sort of domain-restricted-virtual-file saving me and the client time, > resources and bandwidth increasing that the benefits of a rich-fast- > framework-enabled website. > > When a user opens my web site for the first time, my server side pages > would be getting a header or cookie telling me the version of my > JavaScript framework, as a first time use it would have an empty > value. On my server pages i would send the framework on a script tag > like: > > <script language="JavaScript" content="framework" version=""> > //all the code goes here > </script> > > Of course the properties "content" and "version" are not standard for > the "script" tag but they would help the purpose. > > The first time the client server pages sends the framework content, as > in normal use, but the next time the user visits my website I would > read the cookie "jsfVersion" (for example) and compare it to my last > uploaded framework version, so that i would only send its content if > the clients version is older than the server one, otherwise, the > browser would receive the empty content script tag and fill it with > the JavaScript framework code previously retrieved. > > As Google team said, chrome was born upon today's users and websites > activities, from where most of web sites have even a small amount of > JavaScript that would be great to avoid sending or some how flash load > it. > > Maybe in US loading a website with a good amount of content isn't the > big deal because client's internet bandwidth isn't a problem when a > basic user downloads at 300Kbps, while here it could be of 30kbps. > > Finally, because of all that is that I'm wondering if my idea or dream > of having a JavaScript framework cache is kind of "too much to ask", > crazy, presents security risks, or if after all it could ever be > implemented in a web browser. > > > Definitely my friends have reported that my site "flies" on Chrome, > but it would be also great with the functionality above described. > > > Thanks for your time and great efforts! :) > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss -~----------~----~----~----~------~----~------~--~---
