Comments on: A Technique For Lazy Script Loading

By: herringtown

herringtown — Tue, 12 Jan 2010 18:32:50 +0000

Methinks prototype should incorporate this natively, ala jQuery’s jQuery.getScript(…), as @cancelbubble pointed out above. I haven’t poked around with the source of it, but I assume it handles re-load checking, etc.

By: davidchambers

davidchambers — Sat, 18 Jul 2009 02:09:39 +0000

I’ve been using your browser sniffing code to lazily load scripts on my site. I’ve just discovered one change that should be made…

Prototype.Browser.WebKit && !navigator.userAgent.match(/Version\/3/)

should be replaced with…

Prototype.Browser.WebKit && navigator.userAgent.match(/Version\/[12]/)

This will ensure that Safari 4 is treated the same way as Safari 3.

By: cancelbubble

cancelbubble — Fri, 03 Apr 2009 00:57:24 +0000

jQuery can dynamically load scripts into a page with $.getScript(url, callback)

By: FrankThuerigen

FrankThuerigen — Wed, 30 Jul 2008 11:13:16 +0000

@micmath: twoBirds can do it, but this is rather a js file naming issue for application code. I don´t think there is a general out-of-the-box solution for system library code like jQuery and EXT, unless functionality is provided by the authors of these libs. BTW, jQuery can handle it, about the others I don´t know.

By: micmath

micmath — Fri, 13 Jun 2008 10:45:34 +0000

I’m researching a solution that does all of this (dependencies, cross domain loading, callbacks) and one more thing: it must allow multiple versions of the same JavaScript modules to be loaded on the same page without overwriting each other. Any one know of an existing application?

By: BjornGoransson

BjornGoransson — Tue, 10 Jun 2008 08:10:15 +0000

Nice article…

I’m thinking… a lazy Java class loader along with the JVM that was made in JS… or something…

By: temsa

temsa — Sat, 07 Jun 2008 12:41:04 +0000

Archetype JS provides this kind of loading, a logging interface and a configuration that handles the script and file in a java package manner with it’s dependencies, giving you the ability to alias some file and load whatever it needs to work.

http://archetypejs.org

By: FrankThuerigen

FrankThuerigen — Sat, 07 Jun 2008 10:22:02 +0000

@PeterMichaux I second that… IÂ´d advise to get rid of browser sniffing as much as possible, because it causes a constant need of redesign as new browsers come up – especially if large portions of library code rely on it.

By: PeterMichaux

PeterMichaux — Sat, 07 Jun 2008 05:18:03 +0000

Browser sniffing is bad! It is not necessary to user a browser sniff to load some script into a browser.

By: aheckmann

aheckmann — Fri, 06 Jun 2008 21:15:39 +0000

He said, she said, I did it first, who cares. Let’s just learn from each other shall we?

By: uize

uize — Fri, 06 Jun 2008 21:02:12 +0000

@bobmatnyc
Thanks for chiming in. It’s great that you’re investing in this exploration and keeping us updated with your findings.

By: bobmatnyc

bobmatnyc — Fri, 06 Jun 2008 20:13:40 +0000

@Harald

I’m not as big a fan of CSS loading, particularly because I don’t think CSS lends itself as well to this type of functionally-specific segmentation. I think a better approach with CSS is to combine GZIP w/ content expiration.

By: bobmatnyc

bobmatnyc — Fri, 06 Jun 2008 20:10:52 +0000

@uize
The logic in this is entirely my own, though I’ve obviously built on the work of others. In fact, this article was meant to extend a previous one that only discussed script injection by adding callbacks, intervals, and script tracking. I assumed others have done the same, but I hadn’t seen them.

One other addendum. While Safari 3 does support DOM tracking of script injection, it seems a bit flakey. I went back to internal testing and it seems more reliable.

I should also point out that I use lazy loading in conjunction with declarative binding for best results (add custom attributes to a form and look for those attributes on page load to inject script and bind to that form. If Dion is gracious enough, I’ll post a follow-up describing that technique).

By: uize

uize — Fri, 06 Jun 2008 19:52:39 +0000

@ttrenka
Thanks for the historical info.

By: uize

uize — Fri, 06 Jun 2008 19:19:16 +0000

@Tr0y
Sorry… I wasn’t suggesting for a second that any code or idea was *ripped*. There’s obviously been a ton of great thought on this subject by a number of smart people, such that it’s futile trying to claim, suggest, or even hint at ownership. This is a great forum for us all to learn from one another’s advances.

By: ttrenka

ttrenka — Fri, 06 Jun 2008 18:59:30 +0000

I should add that reading the articles can be an invaluable resource for anyone interested in JS techniques, such as this one.

By: ttrenka

ttrenka — Fri, 06 Jun 2008 18:54:29 +0000

First version was written by Dan Pupius (now of Gmail) back in 2001, adopted by me later on in the f(m) toolkit (2002-ish), and has been a staple of Dojo since the get-go.

Before that, library loading was done in JS by Dan Steinmann with the DynAPI, which was aimed at Netscape layers and IE divs.

I have to agree with Tr0y: it gets a little old when commenters see a decent implementation of a particular technique, jump on it with a less-than-friendly-tone, and then attempt to plug their own work in the process. It makes it so that its almost not worth reading the comments here anymore.

Almost.

By: Les

Les — Fri, 06 Jun 2008 18:50:56 +0000

Also, dojo.require can load a Javascript module from the appropriate URI. They had this feature available for a long time.

By: Tr0y

Tr0y — Fri, 06 Jun 2008 18:41:34 +0000

@uize, and @polterguy you guys are constantly plugging your frameworks, it is ridiculously obvious.

@uize Unless you know it is ripped and can provide a link other than plugging your own framework, say so… otherwise don’t even hint at the fact that it isn’t their code, because you don’t even know.

Also, “LazyLoading” has been around forever, so claiming that you were the first is silly. I’d bet the first implementation was even before your framework was even written.

By: polterguy

polterguy — Fri, 06 Jun 2008 18:23:18 +0000

Great work, we’ve had this natively in Gaia for more than a year though. It works completely abstracted away too so when you show or create a widget on the Server Side the widget itself will track which JS files to include and every piece of code that references that widget in the return value back to the client will wait until the JS files included in that callback are finished loading. But I guess this is good news for those not using Gaia ;)