Recently in JavaScript Category
Who cares about syntax?
The ECMAScript discussion list (es-discuss) has a thread(s) running on future proposals for lambda syntax with several hundred posts. A similar thread on class syntax has, by comparison, gone largely ignored.
Some others have noted the potential significance of this. Does it demonstrate a trend in JavaScript? Is it indicative of where programming languages in general are headed?
As Guy Steele has put it:
A closure is an object that supports exactly one method: “apply”.
On the other hand, there’s this, usually attributed to Norman Adams:
Objects are a poor man’s closures.
Still, there really isn’t that much distance from one to the other… granted, that is relative to context.
From my point of view, classical OO has sometimes trended towards being overbearing, particularly for UI development. This is probably why everybody is excited about finding a more elegant lambda syntax for JavaScript and less interested in class syntax, which simultaneously feels more like bookkeeping and also is likely to have a mental association with an heavy-feeling ontology that many JavaScript coders would want to avoid.
JavaFX script... yawn
Sun Microsystems have just announced the 1.0 version of JavaFX, one of the main components being JavaFX Script.
Let me get this straight. After twelve years Sun have finally admitted that writing UI’s in Swing blows goats and their solution is to release something that lets you create a swing UI using code that borrows heavily from JavaScript.
What’s it got? First-class functions, declarative syntax, list-comprehensions…
I’m going to repeat the name because I think it bears repeating. JavaFX Script. I guess the only name bad enough was already taken so they threw an FX in the middle.
If it weren’t for my horse… I wouldn’t have spent that year in college.
Here’s a JavaFX Script code sample (excuse the code formatter from getting confused with the indenting):
import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.shape.Rectangle;
import javafx.scene.paint.Color;
import javafx.scene.shape.Circle;
Stage {
title: "Declaring Is Easy!"
width: 249
height: 251
visible: true
scene: Scene {
content: [
Rectangle {
x: 45 y: 35
width: 150 height: 150
arcWidth: 15 arcHeight: 15
fill: Color.GREEN
},
Circle {
centerX: 118
centerY: 110
radius: 83
fill: Color.WHITE
stroke: Color.RED
}
]
}
}
Looking at it, I don’t think I need to talk about where the inspiration for that comes from. Still… haven’t the GWT proponents been telling everybody for a long time that scripting languages are evil? Will GWT one day allow people to write JavaFX Script and have it compile to JavaScript? I don’t know and honestly I don’t care.
JavaScript is far from perfect but I think the current Ajax “stack” works for (at least) three reasons:
1 - Some of the constraints have, by accident, improved many UI’s. I mentioned that before.
2 - The open web.
3 - JavaScript actually has some features that are really good for creating UI’s. Homoiconicity, lambda and a prototypal object oriented system.
JavaScript won’t last forever but I haven’t seen anything yet that is better on those three points.
Casual ontology
There is a short text written by Poul Anderson entitled Uncleftish Beholding which shows, to some extent, what English would have looked like in the absence of loanwords. It’s interesting to see the number of phrasings that somebody speaking English now would find awkward. English is something of a mixed-breed.
If we multiply the number of language speakers by the number of documents on the web in that language then English is far-and-away the winner in those popularity rankings. I don’t know how important that is but I don’t think English is emerging as the single human language of the web.
How about programming languages? Peter Van Roy thinks that there is evidence that one true programming language is emerging. Some disagree. Esperanto anyone?
Programming languages have something resembling native speakers at least from a “how many users do we have” aspect because, as Yegge points out, most programmers only know one language. In other words, secondary languages are rare… at least for a substantial proportion of the community.
There are plenty of programmers who know how to do the same thing in several languages and try to impose that where they can. JavaScript consistently fell victim to that where people were constantly conceiving ways of doing things that didn’t suit the language. Many people did that when they moved from a training in Java to JavaScript, jumping through hoops to get JavaScript to work like Java because, you know, it looks like it can.
There’s a difference between trying to impose unsuitable syntactic sugar on a language (classes in JavaScript) and liberating the language by demonstrating how patterns from other languages might translate more naturally (Crockford’s module pattern.) It’s good to bring ideas and techniques to a language, not so good to try hammering in conventions.
Of course, programming languages are not like-for-like comparable with human languages. Still, in the way that it has taken influence from other languages - for better or worse - JavaScript is kinda like English.
Guy Steele talks about growing a language (video, pdf) indicating a desire to make a language flexible enough so that the people using it can build on the language provided. The programming language provides the rules - and hence limitations - around which programs can be created. The things people do in a programming language creates the dialogue.
Java has been successful on that level at least partly because it makes it easy for those one language people to create a dialogue or use an existing dialogue.
The thing is, a programming language can be restrictive in a way that a human language typically can not.
Programming languages are used by world builders and the type of language determines the effectiveness with which people can construct universes. Programming languages have philosophical ramifications because the construction of the programming language impacts on the types of dialogue that can happen. A human working in the regular world can invent new rules of discourse and moreover may actually invent a new language (with words or symbols) with which to describe or talk about the world.
The can be achieved in a programming language but the restrictiveness of a programming language can make constructing a new domain-specific language difficult enough that it’s almost never attempted in that language. On the JVM the rigidness of Java and an understandable resilience to change looks like it will lead to increased popularity of new languages running on the JVM at the expense of the Java programming language. As the language of discourse, Java looks like it will soon fade instead of grow.
Languages need to evolve, JavaScript managed to do that mostly by accident and in a different sense to that in which Java grew. The point though is that if JavaScript had not been able to grow at all then despite any luck it would probably now be dead.
Still, as Eich and Crockford both say, popularity doesn’t usually have much to do with the design of the language except perhaps where the design seems familiar… though familiarity itself is a double-edged sword.
In the end though JavaScript like all languages needs to evolve or die… with care.
An infinitely flexible programming language would be infinitely extensible and, most likely, infinitely useless. On the other hand, a language too heavy on restrictions will be useful… but for a sufficiently small problem set that it too would ultimately be useless.
The growth of a language really happens in the community.
Just like HTML, many of the programming languages already in existence today are trying to evolve inside the constraints of standards committees… occasionally this may prove midly successful but I think the best you can hope for when doing that is a Bonsai.
Picking the time
There’s been a bit of interest in a time picker control from Maxime Haineault. Nice piece of work but I for one hope this particular interaction style doesn’t catch on.
As a user I have to move my mouse halfway across the screen aiming at little boxes in order to input the time. If I decide to change that time then I need to go back across the screen aiming at other boxes. Hello carpal tunnel. Further, I could be alone in this but I don’t find the control simple or intuitive at all. I’d probably rather be typing.
Not wanting to simply disagree with the merit of that format for a time picker and leave it there, I thought it would be sensible to provide something of an alternative. So, in the spirit of shamelessly ripping-off a UI convention from elsewhere I’ve coded up the standard OS time selector (with the exception of the little up/down arrows on the right-hand-side.)
Have a look at the example time picker. Click on the hours, minutes, seconds or AM/PM and use your scroll wheel.
Sure, I could probably get roughly the same result using four select boxes (scroll wheel worked on a select box last time I checked) but what would be the fun in that?
Constraints
In the physical world designs are bound by the constraints of space, time, money and the laws of physics.
The impact of the physical laws on creating an object is inversely proportional to the technological advancements available to the designer. Leonardo may have been able to conceive of a flying machine but the actual flying machine, that people could use, took some four-hundred years appear.
In some ways this is a good thing.The required investment and risks associated with the physical world means that, for example, most people will not try to fly a helicopter with no training. It also used to mean that objects were made by people who knew how to make those objects because they did that for a living. You know, cobblers, carpenters, tailors… engineers. Now though, we live in an age of empowerment where any monkey can go to the local hardware store and purchase the means to create a real disaster. We also live in a time where the requirements on the things we create can sometimes have little bearing on their intended use so we end up with things like beer with added vitamins and a nine button mouse. Luckily, the constraints of space, time, money and the laws of physics still prevent Average Joe from going ot the local hardware store and purchasing the means to destroy the solar system.
These physical constraints do not not apply to software… well, they do (things such as memory and processor limits), but not with anything near the same degree of impact. This added a degree of importance to the degree of training that professional programmers required. Most people would fear for their lives if attempting to fly a helicopter without adequate training. If somebody is writing software for the helicopter though, that connection is not so easy to make.
It’s also easy for anybody to design the user interface for software without knowing anything about user interface design. Visual development environments made it easier to create ridiculously complicated desktop applications. The investment in creating a user interface is small and often the thinking is that easy-to-do equates to should-do.
Java Swing provides an environment for creating a user interface that is intended to make sense to Java programmers. As it turns out, Java programmers (and indeed Java language designers) are not the best people to be deciding on the design of the user interface and moreover are probably not the best people to be deciding on the programming model for writing them at all.
Java failed on the client. Instead the ragamuffin collection of HTML, CSS and JavaScript used for the web succeeded. There were good reasons for this.
The web as HTML over HTTP has always been strong for document delivery and interlinking between those documents. It is good for text content delivery, albeit in a paged, one-large-chunk-of-text-at-a-time, manner. With JavaScript, the content chunking can be controlled so that content delivery can be more finely controlled and more reactive (or proactive) to the needs of the user.
I think the content-oriented nature of the web is leading us to better user interfaces.
Programmers who do not know JavaScript complain that the language sucks. Programmers who do know JavaScript compain that whilst the language is elegant and powerful (warts aside) the API for controlling the UI (the DOM) sucks.
Yes, the DOM sucks. However, the suckiness of the DOM has actually imposed a useful constraint on programmers. If the web had from the start been really good for creating applications then there’s a good chance we would have had more applications and less content. Further, despite its shortcomings, CSS has helped to shift custodianship of the presentation layer away from application programmers and GUI toolkit developers.
So… much as I might bemoan the weaknesses of the DOM I actually think that the difficulties that it has imposed may have actually played a part in reducing the amount of administrative debris attributable to JavaScript on many websites.
With that said, as the emphasis on good usability on the web increases I think we’re all about due for some unshackling. My only request would be that people actually learn how to fly before jumping into that helicopter.
Script loading
There’s been a fair amount of interest lately in non-blocking script downloads and various ways to load multiple scripts for which the current script has dependancies with a callback onready.
This can be a tricky problem to solve for really old browsers but if we’re only worried about modern browsers (you know, no Netscape 4.7) then the solution is fairly straightforward. I’ve supplied the code here in a library free version for those of you who don’t have their own solution, don’t want to use any of the library solutions and don’t feel the need to unwind one of those solutions to see how it works.
You can get the script from nolib.load.js.
You can call this like so:
nolib.loadAll("http://example.com/script1.js,http://example.com/script2.js").oncomplete(function() {
alert("all scripts loaded");
});
There are also nolib.load() and nolib.insx() functions which some people may find useful. As the code is (deliberately) stripped of comments you’ll have to figure out how to use them yourself.
Dear Gmail, please stop stealing my focus
I’m as much of a Gmail junkie as anybody, to the point where I rarely bother running mail servers anymore but instead opt for using Gmail via Google Apps.
Not that I think Gmail is perfect, just that all the webmail clients I’d used before gmail slow and annoying to the point of being practically useless.
I do have one annoyance with Gmail though and that is that frequently when I go to login, the focus is removed from the Username field and placed on the Password field halfway through me trying my user name. Like this:
It doesn’t happen all the time and I haven’t looked into the exact circumstances (connection speeds, browser, plugins, etc) under which it happens but it’s definitely annoying. In terms of how the page is coded, what happens is that I start typing my username as soon as the page comes up, then the window.onload() event fires, then the focus is moved to the password field because there is already something in the username field. The code is there to make it quicker for people who have the username already populated by their browser. In my case though, with my fingers on autopilot as soon as the page loads this intended convenience turns into an inconvenient annoyance.
In my last post about intentionality & adverse effects I wrote about the dangers of making unrefined guesses about what the user wants. I think that is going on here - for me at least.
I know that a similar trick on the Google homepage has been called the Billion dollar line of JavaScript but in the case of this one, I don’t see why Google haven’t done something about it (assuming that I’m not the only person in the Googleverse getting annoyed by this one.)
The reason I don’t see why Google haven’t done something is that the fix looks pretty simple. I know it is a bit presumptuous of me to think that I can look at this and solve the problem in a matter of minutes so read the following suggestion with that disclaimer in mind.
This is definitely not how I would recommend they code it but instead just demonstrates very roughly what could be done to the existing code (my additions are indicated by the comments):
// global flag allowing focus switch or not
// I wouldn't normally use a global variable, this is only to
// demonstrate the potential change in the simplest way
var gaia_allowFocusSwitch = true;
// Set the global flag to disallow if the user types into the Username field
// This would need to be attached before the onload event fires so the exact
// placement of it, and any capability or element checks would also need to be done here
document.getElementById("gaia_loginform").Email.onkeypress = function() {
gaia_allowFocusSwitch = false;
};
function gaia_setFocus() {
var f = null;
if (document.getElementById) {
f = document.getElementById("gaia_loginform");
} else if (window.gaia_loginform) {
f = window.gaia_loginform;
}
if (f) {
if (f.Email && (f.Email.value == null || f.Email.value == "")) {
f.Email.focus();
// add a check on the global flag to the password focus switch
} else if (f.Passwd && gaia_allowFocusSwitch) {
f.Passwd.focus();
f.Email.onfocus = function() {
gaia_allowFocusSwitch = false;
};
}
}
}
//
//
If the user has started typing into the Username field, then don’t move the focus to the Password field.
Could it be that simple? Given the expertise that Google has in these things there’s a decent chance that there is a very good reason why it isn’t already setup to do something along those lines.
I’m certainly happy to hear from anyone who knows.
Intentionality & adverse effects
After my post on perceived speed the question was posed to me as to whether it was possible for a response to a user action to happen too quickly.
The classic example given here is a CSS and/or JavaScript powered dropdown menu which triggers immediately onhover or onmouseover causing problems for users as they move their mouse past the menu - triggering it to open unintentionally. The solution occasionally offered is to place a delay on the menu opening.
The user does not want a delay on the menu any more than they want their computer to take a long time to boot up or to have a slow internet connection. I’m happy to be proved wrong by some actual user testing on this but I don’t think it would make any difference to the point I’m trying to illustrate. The user has not asked for a delay. No matter how cute the transition, there is ultimately no pleasure in waiting for a menu to appear, time and time again.
The delay on the menu in such an instance is put in place to avoid having the UI respond to a user action in a way that the user did not intend. It is imperfect in that it does not actually try to decide whether the user wants the menu to open or not but instead says “if the user keeps the mouse of the menu for more than this amount of time then we assume that they intend for the menu to open.”
In technical terms - a guess.
The problem with an unrefined guess is that it’s a shotgun approach. It might hit the target but there’s likely to be collateral damage or, as they call them in pharmaceuticals, adverse effects.
This happens too often on the web. Users have been slipped roofies by way of popup windows, broken URL’s, back button trickery, slow pages and a plethora of other embarrasments that were dreamt up by people thinking that they were only solving the problem at hand when in fact they were simultaneously creating other problems. All too often, JavaScript has been one of the tools used to do so.
The problem for JavaScript runs deeper too, with the programming environment (the DOM) inflicting pain on programmers at the other end. Here’s a cute one from IE that you may have seen:
document.body.onbeforeunload = function() {
alert("about to unload");
}
The onbeforeunload event will actually fire in IE if a pseudo-protocol link href="javascript:" is clicked or one is pasted into the address bar. The problem with this, and with too many DOM quirks in various browser is that it goes against how the programmer rightly thinks what they do influences the universe. It goes against intentionality - just like the exampes inflicted on website users. Links lead to content - having the browser open a popup window is a side-effect, introducing effects on the user that they did not ask for. Any JavaScript developer can feel a real sense of empathy for their users on that point alone.
So, back to the dropdown menu, what’s a better alternative than a delay?
One option is to poll the mouse position to determine mouse velocity. Something like this:
(function() {
var nav = document.getElementById("nav"),
vector = [],
lvector = [],
velocity = 0,
t,
interval = 25,
threshold = 0.5,
fire = function() {
// display the dropdown
},
load = function() {
vector = [];
lvector = [];
// remove the dropdown
return function() {
fire();
trigger = function() {};
};
},
trigger = load(),
sample = function() {
velocity = vector[2]/interval;
if (lvector.length == 3) {
if (lvector[2] === vector[2] || threshold>= velocity) {
trigger();
}
}
lvector = [].concat(vector);
};
//
nav.onmouseover = function(e) {
document.onmousemove = function(e) {
vector[0] = (e || window.event).clientX - (lvector[0] || 0);
vector[1] = (e || window.event).clientY - (lvector[1] || 0);
vector[2] = Math.sqrt(Math.pow(vector[0], 2) + Math.pow(vector[1], 2));
};
t = window.setTimeout(function() {
sample();
t = window.setTimeout(arguments.callee, interval);
}, interval);
};
//
nav.onmouseout = function() {
document.onmousemove = null;
clearTimeout(t);
// re-cock the trigger
trigger = load();
};
});
The example above helps to reduce a “delay when the user doesn’t want a delay” effect at the expense of introducing more work for the CPU. The reader may, or many not, find this an acceptable trade-off in individual circumstances.
Note that this code currently handles the mouse velocity only. It would need to be extended to correctly handle a dropdown menu completely. I may provide an update when I get time.
This example is provided in a slightly altered form as a download: nolib.velocitor.js.
Perceived speed
Ten years ago my most commonly used operating system was BeOS (with *nix second and windows third). I’ll try not to wax nostalgic about that particular OS (as much as I’d like to) but I vaguely remember a quote from the Be CEO Jean-Louis Gassée that it was not so much the actual speed of the OS that mattered but the perceived speed of the OS to the user. Of course, research into thresholds for computer responsiveness goes back at least to Robert Miller’s 1968 paper Response Time in Man-Computer Conversational Transactions but the quote from Gassée was more about the way that the BeOS had been built to in such a way that the UI responsiveness was maintained regardless of what other processes were running at the time.
Still, whilst responsiveness thresholds have been known for a long time, it took my first dual processor system for me to be able to use Windows without the frustration of random processes temporarily locking-up the UI. Anybody who ever used Windows 95 will surely remember the dreaded “floppy drive selected UI lockup.” Usually what would happen is that if the floppy drive was accidentally selected in the drive dropdown then the UI would lockup whilst some other part of the OS did the disk seek. Not a good user experience.
The same problem is still apparent today in devices ranging from expensive LCD and plasma televisions, mobile phones and set top boxes to ATM’s… given a selection of ATM’s my choice is always the one that isn’t St George. Whilst this aversion could partly be attributed to some other quirks in the UI, I think the primary reason is that these St George ATM’s respond to my key presses slow enough that I’m often never sure if it’s registered my input or not. Not a good user experience. Trying to use one of these ATM’s is not only slow but also annoying in the same sense that a poorly dubbed movie is annoying.
Web browsers have usually been reasonably good at feeling responsive even though it often takes a long time for them to fetch the actual UI and content of the site I’m trying to visit. It’s been a long time since I’ve used mosaic so I can’t be sure but every browser I can remember using has usually kept the UI responsive and provided feedback to me for what it was doing. There have been exceptions to this in most browsers I’ve used but in general, one of the aspects I’ve liked in every browser I’ve used is that if a website is loading too slow, I can hit stop, refresh, or simply leave the site and go elsewhere.
So, browsers have usually done this stuff pretty well by default. The websites they serve have varied wildly in how they handle things internally though. Hidden PDF downloads, Flash loaders that bear no relevance to how long things will actually take and poorly implemented iframes (the browser says something is loading but nothing is happening) are some of the offenders. JavaScript code has been another offender, not due to the nature of the language itself but simply because it gives the power to create interaction other than page loads, which means that good UI responsiveness and feedback of the browsers can be subverted.
So, to JavaScript then. What are some things that a UI developer working in JavaScript and interacting with the DOM can and should do to maintain UI responsiveness? I’m going to look at this in terms of the three basic thresholds from Miller’s paper.
One tenth of a second is the limit for the user to think the system is responding immediately.
This generally means that ajax requests will usually not feel instantaneous unless you are caching, memoising or predictively prefetching the responses.
Ajax requests aside, if a JavaScript event handler has to do some processing you should handle the processing after providing feedback to the user. So, instead of this:
something.onclick = function() {
// do some intensive processing
alert("UI response");
}
It’s better to do this where possible
something.onclick = function() {
alert("UI response");
// do some intensive processing
}
Of course, processing can often be done well in advance of the event hander being fired in many instances, which is also good. Additionally, whilst JavaScript is single threaded, functional techniques (and setTimeout) can be used to fork processing in terms of how the user perceives the UI.
Selecting the most appropriate event to fire on is also important. In many cases it’s better to use onmousedown than onclick due to the former firing earlier than the latter by something like 80 milliseconds.
Another point is to avoid querying the DOM repeatedly to determine state of the UI. In many cases the current state can be modelled in code - many UI responses are based on simple mathematical formulas (or can be approximated) which means it’s possible to avoid repeatedly, and expensively, querying DOM elements for their current state. In Gang of Four terms we’re basically talking about a mediator.
1.0 second is about the limit for the user’s flow of thought to stay uninterrupted
If the UI is responding to user action somewhere between one tenth of a second and one second then the user’s flow will not be interrupted, but they will not feel that they are acting directly on the system. For many UI controls like tabs and accordions I’ve found it important to have the response right down near one tenth of a second important. This also applies to image galleries - whilst a cross fade can be cute, it is cutting into the time for the user getting the response action they want - a long transition for user initiated switches will diminish the user feel for acting directly on the system. Transitions longer than one second should be avoided for anything user initiated.
Personally, I tend towards user initiated actions responding within one tenth of a second and either completing immediately or transitioning to completion in under one second.
10 seconds is about the limit for keeping the user’s attention focused on the dialogue
For anything above one second, the user needs to know that the UI has registered their input and is doing something. This applies whether the delay is caused by processing or by the fetching of data in some ajaxy fashion. I personally find that one second doesn’t feel quite zippy enough to make a loading indicator of some sort useful but the specified time would need to be tested for a given application. For the purposes here I will be using half a second.
One way to approach the crossover into loading-message-required territory would be something along the lines of this (incomplete) code fragment:
(function() {
var showLoader = function() {
// some code to show the user that something is happening
};
var hideLoader = function() {
// some code to hide that same loader
};
something.onclick = function() {
var t = setTimeout(showLoader, 500);
// a call to some myapp.doProcessing function that
// accepts a callback for when it completes
var myCallback = function() {
// just in case we return immediately,
// stop the loader from appearing
clearTimeout(t);
// remove the loader in case it was there.
hideLoader();
};
myapp.doProcessing({"data": ""}, myCallback);
};
}());
In the example above, we will display a loading message if the UI control hasn’t finished after half a second. If the loader is displayed, it is removed as soon as the UI control returns.
It should be noted that single threading means the accuracy of timers in JavaScript is inversely proportional to the amount of processing that is happening. So, if a transition needs to complete in under one second it’s best to shoot for something less than one second. In addition, it’s important to understand how timers work and the difference between setInterval and setTimeout but instead of also covering that here, I’ll refer to a post from John Resig.
In the example above, adding a further timeout at 10 seconds to handle longer response times (and possible errors) is an exercise left up to the reader.
More than 10 seconds
Anything that takes more than ten seconds will need to allow the user to interact with some other part of the UI whilst the user input is being acted upon. There are a number of ways to achieve a file upload progress bar but if it’s going to take more than ten seconds, the UI should allow the user to get on with it and let them know later when it’s done. Modeling this on browser download managers would be a good start.
Knowing how long it should take to generate a response
There’s a large amount of variation in responsiveness for different users depending on their individual connection and configuration. If you’re profiling the performance of your UI then for any given action, it’s possible to have a baseline responsiveness. From there, you’re able to compare that baseline to something like the page load time for the given user, and adjust the feedback provided by the UI accordingly. Comparing the page load time would be something along these lines:
(function() {
var baselineLoad = 1800,
startTime = (new Date()).getTime(),
diff;
window.onload = function() {
diff = baselineLoad - ((new Date()).getTime() - startTime));
};
}());
The diff will give some indication of the performance of the client relative to tests. In addition to this comparison, an average of response times for specific UI components could be kept throughout the page session. That is also left as an exercise for the reader.
Hopefully there were a few useful tips in there around UI performance and applying responsiveness thresholds to JavaScript powered UI’s.
Web directions government presentation
I presented a talk on JavaScript at Web Directions Government on the 19th of May.
The title of the presentation was “One paper clip, a box of matches and some JavaScript” with the focus primarily being on the approach you need to take with the language when working in less than favorable circumstances…
Of course - given browser inconsistencies and a long history of people abusing the bad parts of JavaScript and ignoring the good - “less than favorable” circumstances is another term for “all the time.”
My slides got cropped rather badly when I uploaded to SlideShare so instead they are available as a 2MB PDF.
You can find more details and a podcast of my talk over at the Web Directions site. As a piece of errata, Brendan Eich, of course, was actually working at Netscape. The minor slip of the tongue there was due to me also talking about Self in that section, which at the time was a research project at Sun.
