Title: Page 127 – Alex Kirk

---

 * 
   ## 󠀁[Better code downloading with AJAX](https://alex.kirk.at/2005/10/10/better-code-downloading-with-ajax/)󠁿
   
 * October 10, 2005
 * I’ve been playing with Code downloading (or Javascript on Demand) a little more.
 * [Michael Mahemoff](http://www.softwareas.com/ajax-can-improve-performance-too)
   pointed me at his great [Ajaxpatterns](http://www.ajaxpatterns.org/) in which
   he suggests a [different solution](http://ajaxpatterns.org/On-Demand_Javascript):
   `
   if (self.uploadMessages) { // Already exists return; } var head = document.getElementsByTagName("
   head")[0]; var script = document.createElement('script'); script.type = 'text/
   javascript'; script.src = "upload.js"; head.appendChild(script);
 * Via DOM manipulation a new script tag is added to our document, loading the new
   script via the ‘src’ attribute. I have put [a working example here](https://alex.kirk.at/area7/2005/10/10/).
   As you can see this does not even need to do an XmlHttpRequest (XHR later on)
   so it will also work on browsers not supporting that.
 * So why use this approach and not mine? Initially I thought that it was not as
   good as doing it via XHR because you receive a direct feedback (i.e. a function
   call) when the script has been loaded. This is per se not possible with this 
   technique. But as in good ol’ times a simple function call at the end of the 
   script file will do the same job (compare source codes from [the last example](https://alex.kirk.at/area7/2005/10/05/)
   and [this one](https://alex.kirk.at/area7/2005/10/10/) (plus [load.js](https://alex.kirk.at/area7/2005/10/10/load.js))).
 * Using this method to load code later on also provides another “feature” (thanks
   for that hint to [Erik Arvidsson](http://erik.eae.net/)): Unlike XHRs Firefox
   also provides a cache for scripts loaded that way. There seems to be a disagreement
   about whether this is a bug or a feature (people complaining that IE caches such
   requests while it could be quite useful in this scenario).
 * When using dynamically generated javascript code you will also have to keep your
   HTTP headers in mind (scripts don’t send them by default). The headers `Cache-
   Control` and `Last-Modified` will do usually (see [section 6.1.2 of my thesis](https://alex.kirk.at/papers/caching-strategies/diploma_thesisch6.html#x17-730006.1.2))
 * The method above is also the method used by [Dojo](http://www.dojotoolkit.org/),
   a developer ([David Schontzler](http://stilleye.com/)) commented, too. He says
   that Dojo also only loads the stuff the programmer needs, so little overhead 
   can be expected from this project.
 * Also [Alex Russell](http://alex.dojotoolkit.org/) from Dojo left a comment about
   [bloated javascript libraries](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/).
   He has some good points about script size to say ([read for yourself](https://alex.kirk.at/2005/10/03/bloated-ajax-applications-due-to-libraries/#comments)),
   I just want quote the best point of his posting:
 * So yes, large libraries are a problem, but developers need some of the capabilities
   they provide. The best libraries, though, should make you only pay for what you
   use. Hopefully Dojo and JSAN will make this the defacto way of doing things.
 * So hang on for Dojo, they seem to be on a good way (coverage of Dojo to follow).
 * Finally I want to thank you all for your great and insightful comments!
 * ajax, dojo, code downloading, javascript on demand, caching, http headers
 * [Ajax](https://alex.kirk.at/category/code/ajax/), [Code](https://alex.kirk.at/category/code/),
   [PHP](https://alex.kirk.at/category/code/php/)
 * 
   ## 󠀁[No Google Office To Be Expected](https://alex.kirk.at/2005/10/09/no-google-office-to-be-expected/)󠁿
   
 * October 9, 2005
 * According to an [interview of Sergey Brin](http://www.theregister.co.uk/2005/10/08/google_office/)(
   founder of Google) by [John Battelle](http://battellemedia.com/), Google does**
   not** plan to publish a web based office, as rumored before (fueled by a [new partnership between Google and Sun (owner of openoffice.org)](http://news.com.com/Sun+and+Google+shake+hands/2100-1014_3-5888701.html)).
 * “I don’t really think that the thing is to take a previous generation of technology
   and port them directly,” he said. I agree with that. We have to think about new
   tools to be our future web apps. Just porting office apps to the web [won’t work](https://alex.kirk.at/2005/10/08/office-web-apps-are-just-proof-of-concepts/).
 * So what’s this deal about now? Google seems to want a wider distribution of their
   toolbar. According to the [Cnet coverage](http://news.com.com/Google+and+Sun+deal+Thats+it/2100-1012_3-5888798.html)(
   via John Battelle [again](http://battellemedia.com/archives/001914.php)):
 * “Details about what exactly that will entail were vague at best, with the only
   nugget offered being that Sun, in the immediate future, will make Google’s toolbar
   a standard part of the package when users download Sun’s Java Runtime Environment
   from the server seller’s Web site.”
 * Sergey Brin further stated that distributed thin web applications allowed you
   to do “new and better things than the Office package and more.” So further tools
   by Google can be expected.
 * google, office, sun, openoffice, ajax
 * [Code](https://alex.kirk.at/category/code/)

 [Previous Page](https://alex.kirk.at/page/126/?output_format=md&term_id=44043) 
[Next Page](https://alex.kirk.at/page/128/?output_format=md&term_id=44043)