Earlier this year, JavaWorld's JavaScript columnist Rawn Shah conducted a virtual interview (via e-mail) with Brendan Eich, a technical staff member of Netscape Communications who has been working on the Navigator 2.0 project and was hired to do "the scripting language," which has evolved into what is now known as JavaScript.
JW: How long have you been on the Navigator 2.0 project?
BE: I joined 2.0 a little late, coming from some next-generation protocol work for the server group, followed by some early Java investigation.
JW: What got you interested in this work?
BE: I actually was hired to do what was called "the scripting language," but by the time I joined, Java was getting big. However, it became clear over much arguing, and with prodding from Marc Andreessen, that Java was not a scripting language in the following sense: You can't write hunks of code with loosely-typed variables to glue together components that you don't write -- every Java program must have a class containing a method, and you have to run a compiler to get Java bytecode.
So we saw a need for an interpreted-from-source, dynamically typed language with which one could orchestrate the interactions among HTML form elements and links, Java applets, plug-ins, and other components. The audience for this language, we hoped, would consist of HTML authors who had some programming experience, but did not need a lot in order to write a script. Java is great for component writers and should prove useful for applications platform programming; some day, I hope, with the right extensions and native compilers, [it will be great] even for systems programming.
But you shouldn't have to write a Java applet to make a click on an HTML button open a new window containing the URL typed into a nearby text input. Moreover, we'd like to let script writers integrate Java and plug-in components that they don't know how to write, and then author HTML pages that compose these elements. This approach lets HTML play to its strengths, and Java to its strengths, and frees the scripters from having to over-specialize. It helps users find the best tool tradeoffs.
JW: How do you like it at Netscape now that the company is on top of the world?
BE: I'm very happy to be at Netscape, and pleased with our continued success. After years of systems programming, compiler hacking, and network tool building, I find it very rewarding to contribute to the application platform we're building. The long-anticipated "next layer" of networked portable runtimes and machine-independent object file formats finally is commercially viable, thanks to the Internet.
JW: Who else in the Netscape team is avidly working with the JavaScript language?
BE: A lot of our content people are getting into JavaScript and Frames -- you can see their work at http://proto.netscape.com. I have many customers internal to our product development organization, including new server projects, the LiveWire team, and client folks who are helping to make Navigator more scriptable in future releases.
JW: What do you hope will become of the JavaScript language?
BE: I hope it will be implemented by other vendors, based on the spec that Bill Joy and I are working on. I'd like to see it remain small, but become ubiquitous on the web as the favored way of gluing HTML elements and actions on them together with Java applets and other components.
JW: How do you see the language used most often?
BE: There are a lot of users hacking on JavaScript and Frames, to make more dynamic multi-window HTML applications. A common approach is to put a form in one Frame with JavaScript event handlers for its inputs, which then control the loading or even generation of documents in other Frames and top-level windows.
But I haven't studied JavaScript usage rigorously. For all I know, the most common use is to make pages a little smarter and more live -- for instance, make a click on a link load a different URL depending on the time of day.
JW: There have been quite a few revisions since December of 2.0 betas. Is there light at the end of the tunnel soon? (Editor's note: This question was asked and answered prior to the commercial release of Navigator 2.0)
BE: There is light at the end of the tunnel, although because JavaScript was too much of a one-man show, 2.0 will contain numerous annoying little bugs. My hope is that all big bugs have workarounds, and I've spent a lot of time working with developers to find bugs and workarounds.
I'm following through for 2.1 by fixing bugs, adding features, and trying to make JavaScript consistent across all our platforms. I don't know when 2.1 will ship, but would wager it'll be out well before next fall -- we move fast here.
JW: JavaScript holds many elements that are undefined currently but hold a lot of interest in future applications such as the API to Java applets. When will these elements be defined?
Both Java reflection, as we call it, and plug-in scriptability are on the list for 2.1, and I have some much-needed help for this work, so it ought to happen.
JW: The document object right now is primarily a one-time rendered window or frame; Yet many people are trying things like modifying text within an already rendered window causing their browsers to crash. This is not a bug really, but the need for a dynamically rerendering window or frame would allow different text to appear within the same window/frame depending upon events triggered earlier in the document. Right now the way to actuate something like that is to use multiple frames. Do you think that in the future, we might be able to do this in the same window/frame?
BE: Yes, and it's even possible now to work around bugs and overwrite the current document, but you must generate an entirely new one, unfortunately. Our goal for future releases is to increase the degree of editability and make the "dynamic update" of already-rendered HTML elements, images, and applets/plug-ins possible and fully general.
JW: The developers already are begging for new objects like accessing the MIME types, information about plug-ins available on the browser, access to local directory info, etc. You've mentioned the answers to this on and off in the Netscape developer program newsgroups. Can you tell us what will be added so that we have a list of things to look forward to?
BE: Netscape 2.0 is out of my hands, and basically done. For 2.1, I think plug-in reflection will get done, so you'll be able to find equipped plug-ins by their MIME types, as well as enumerate plug-ins embedded in a document and interact with them.
Another thing I hope to get into 2.1 is "data tainting," to use Perl's jargon, although the rules are a bit different for JavaScript. This technique should enable us to re-expose session history in a way that can't be communicated, no matter how a script encodes it, back to a bad guy's server.
JW: Are the numerous discussions on the JavaScript secure newsgroups helping you in your work? If not, are they helping developers clear up some of their concerns and ambiguities?
BE: The secure newsgroup (snews://secnews.netscape.com/netscape.devs-javascript) has been invaluable. I could not have done 2.0 without it. I hope developers are getting a lot out of it too -- I've received much favorable and supportive mail from them, which is appreciated.
JW: You've answered lots of questions on the newsgroup along with some of the other staff members and developers who have caught up. It is very helpful for novices. Will this continue in the future?
BE: Yes, and you will see more Netscape e-mail addresses as time goes on and we build up our developer support group.
JW: What is the best example of a JavaScript that you have seen so far? Who wrote it?
BE: I hate to have to pick just one, but Bill Dortch's Color Center is impressive (http://www.hidaho.com/colorcenter/), both for what you see and for what you don't (an inter-frame function registry to make function calling independent of the frame in which a function is defined).
I think Achille Hui's brave experiments deserve mention also (see http://drizzle.stanford.edu/~achille/html/hack3/bgcolor.html, among others; also http://drizzle.stanford.edu/~achille/test/mocha/ising.shtml for a wild use of checkboxes and pseudo-threading to demonstrate a physics problem).
JW: In some press releases with the initial announcement of JavaScript, a number of representatives from very prominent software firms have said that they are working on creating interfaces to commercial databases through JavaScript. I, for one, do not know of any such JS database object to allow access to a database table through the JS environment. Is there one being worked on or was it simply marketing spiel on their part?
BE: Actually, our LiveWire product includes an NSAPI server extension that runs JavaScripts on the server side, where they can access databases and documents via different objects and methods from the ones I've defined for client HTML.
My hope is that with the standardization of JavaScript by Sun, other companies will incorporate it into server/database applications as well as client web browsers. For this to happen, I'll be working with Sun to get out a reference implementation that implements the forthcoming spec.
This story, "Bending over backward to make JavaScript work on 14 platforms" was originally published by JavaWorld.