Friday, April 4th, 2008

Popularity, History, and SCRIPT SHARED

Category: JavaScript

<p>Brendan Eich has responded to Doug Crockford talking about the popularity of JavaScript, and the hash method for sharing JavaScript, in his post on Popularity.

In in he starts out by discussing the history of JavaScript, warped as it may be:

As I’ve often said, and as others at Netscape can confirm, I was recruited
to Netscape with the promise of “doing
Scheme
in the browser. At least client engineering management including
Tom Paquin,
Michael Toy, and
Rick Schell,
along with some guy named

Marc Andreessen, were convinced that
Netscape should embed a programming language, in source form, in HTML. So it
was hardly a case of me selling a “pointy-haired boss” — more the reverse.

Whether that language should be Scheme was an open question, but Scheme was
the bait I went for in joining Netscape. Previously, at SGI,
Nick Thompson had turned me on to
SICP.

What was needed was a convincing proof of concept, AKA a demo. That, I
delivered, and in too-short order it was a fait accompli.

He continues to talk about how Java came into the equation and the question of “do we need two languages?” came out of that. Scheme with a Java like syntax? That is what won out in the end.

No need to smoke the hash?

Brendan also feels like the hash method has some failings such as security: poisoning attacks and the safety of crypto-hashes. Also, having hash=”some crazy hash” would look a little ugly in your HTML :)

Brendan proposes a shared URL:

  1. <script src="http://my.edge.cached.startup.com/dojo-1.0.0.js" shared="http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js"></script>

Imagine if we had an AOL CDN / YUI CDN that anyone could use? Some people may not like the “centralized” side of it, but I think it would be huge.

Related Content:

Posted by Dion Almaer at 10:48 am
7 Comments

++---
2.9 rating from 16 votes

7 Comments »

Comments feed TrackBack URI

Ahem — some kinda AOL/YUI/GOOGLE CDN. ;) But really, integrate some kinda hash in that so that you can be sure of what you’re getting from the CDN, and why not?

Comment by mdmadph — April 4, 2008

The hash *does* buy us a lot, but the issue for a lot of toolkits these days isn’t CDN-ishness (Dojo, YUI, etc. all have that licked). If you want to pull Dojo from the CDN…well, just pull Dojo from the CDN. The real issue is cache durability. Yahoo’s stats suggest that 50% of visitors to Yahoo.com return with empty caches, and as a result, the design of JS libraries can’t change to assume that they’re “fire and forget”. If we *could* assume that libraries would be (essentially) “installed” into some local share library area which is more durable than the normal cache, we’d have different constraints.

Doug’s hash proposal is good first step at lifting the veil. This is another good step, but I don’t see them as being in opposition.

Regards

Comment by slightlyoff — April 4, 2008

I was unaware of the SHARED attribute, but I have long been proposing a CDN for JavaScript. In fact, that is the main reason I purchased OpenAjax.Com – to allow a Wiki for editing JavaScript on the fly for immediate ‘fixing’ of open source javascript libraries. Of course we could not serve new javascript until it was vetted by the community, but it would exist for your session, and if you wanted for your application using a CNAME.

Comment by OpenAjax — April 4, 2008

Well, you can already use Yahoo!’s CDN if you’re using YUI:
http://developer.yahoo.com/yui/articles/hosting/

Comment by bluesmoon — April 4, 2008

slightlyoff: there are two issues: durability and poisoning. For the first, it would help to know why so many visitors have empty caches — lack of a proper pr0n^H^H^H^Hstealth browsing mode?

Longer term, HTML5 offline support and Google Gears should converge on a cross-browser local store that’s sufficient to hold pinned up-rev copies of most popular libraries in (copious on the desktop, not copious but probably capacious enough on mobile) persistent client memory.

Who will do the loading and pinning, if not the HTML processor? This does suggest elaborating @shared to do more than fill the HTTP cache. Although it would be a shame to overdesign for some unanlyzed hard case — i.e., without more detail on why those 50% of re-visitors return with empty caches.

/be

Comment by BrendanEich — April 4, 2008

Sounds like a great idea, until that main store goes down for some reason (Pakistani telco guy accidentally reroutes all traffic, underwater fibre optic cable snaps, Homer doesn’t press the any key), and every site linked to it goes down with the central storage. There are some benefits to a distributed model, availability being one of them.

Comment by dearsina — April 7, 2008

dearsina: that’s why @shared and @src can and probably should co-exist.

/be

Comment by BrendanEich — April 7, 2008

Leave a comment

You must be logged in to post a comment.