INNOVATORS OF THE NET: BRENDAN EICH AND JAVASCRIPT

"Brendan's

technical

skills are

so strong,

his vision

so broad,

and his

verbal skills

so highly

developed

that his

voice is a

powerful

one inside

Netscape."

Brendan's technical skills are so strong, his vision so broad, and his verbal skills so highly developed that his voice is a powerful one inside Netscape. The engineers he works with, the developers he interacts with on the Net, and the executives he meets with have the highest regard for Brendan, both as a superlative engineer and as an unassuming, warm individual.

He checks newsgroups with religious zeal, watching what people are doing with and asking about JavaScript. He weighs in on the more important news items and has a wonderful "feel" for what's happening with JavaScript out in the world. Before JavaScript became a standard, new language features often started with customer requests for better control over something. Soon after - sometimes within as short a span as 15 minutes - a brilliant solution would appear full-formed in Brendan's code.

Brendan's a demon in front of his computer and wastes incredibly little time. Stopping by his office to discuss an issue usually results in a conversation with the side of Brendan's head. He continues programming, tending to email, or whatever, and carries on a conversation simultaneously. When the conversation devolves to courtesies, he announces that he's very busy and needs to get back to work.

In what little spare time Brendan finds, he plays excellent classical piano and practices gymnastics. He loves to travel but he must love work even more - he's chronically on the verge of losing vacation time because he has too much accrued.

Introduced in 1995, JavaScript is now an international standard and is helping developers to more easily write cross-browser Dynamic HTML.

Brendan's outstanding accomplishments earned him the Web Innovator of the Year award from c|net's Builder.com in April 1998. Here's Brendan on JavaScript:
 

There were people who argued strongly that Java's fine for programmers who build components, but there's a much larger audience of people who write scripts or maybe copy a script from somebody else and tweak it. These people are less specialized and may be paid to do something other than programming, like administer a network, and they write scripts part-time or on the side. If they're writing small pieces of code, they just want to get their code done with the minimal amount of fuss. Finally, we agreed that this new language should look like Java, but be a scripting language.

Like all languages, it borrowed from others. LiveScript was the official name it was given when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but we rechristened it JavaScript in a joint announcement with Sun on December 4, 1995.

JavaScript attracted a lot of developer attention, because what people wanted back then (and still want) is the ability to go one step beyond HTML and add a little bit of code that makes a web page dynamic - that makes things move, respond to user input, or change color; that makes new windows pop up; or that raises a dialog box to ask a question, with an answer necessary to proceed - things that HTML cannot express. That's really where you need a programming language, but something simpler than Java or C++.

Content creation should not be recondite. It should not be this bizarre arcana that only experts and gold-plated computer science gurus can do. There are economic advantages to lowering the entry costs in creating web content and in sharing it or aggregating it, like Netscape is doing in Web Building.

Calling JavaScript "the glue that holds web pages together" is short and easy to use, but doesn't do justice to what's going on. Glue sets and hardens, but JavaScript is more dynamic than glue. It can create a reaction and make things keep going, like a catalyst.

A NEW INTERNET STANDARD
Because JavaScript took off so well on the web after the beta of Navigator 2.0, Microsoft had to implement compatible language support, to keep up. That created demand for a standards body to say, "Here's how it should work," so that software companies could meet the standard and authors could be sure that their pages would work with the widest possible number of browsers. Right after Navigator 3.0 was released, in August 1996, we went to work on submitting a draft standard based on JavaScript to the European Computer Manufacturers' Association (ECMA), the international communications standards body, based in Geneva, Switzerland. ECMA adopted it in June 1997, and it has also just been approved as an ISO standard.

The standard is now officially called ECMAScript. At Netscape, we use the term "JavaScript" as the brand name for our value-added implementation of the ECMA standard. This includes a set of extensions that are not in conflict with anything, but add value, so it's a way for Netscape to innovate ahead of the standard. I think that's the right way to drive standards. The design-by-committee process where everyone gets together and has a big, political tug-of-war and comes up with a Rube Goldberg compromise that satisfies everyone equally poorly is not the way to do it. The way to do it is by creating a prototype, and seeing how well it flies.

ECMA is now meeting to work on ECMAScript 2.0, which will include exception handling (a cleaner way of handling errors) and a few other language features. That will make it more like a full-strength programming language - a little more like Java, but I don't think it's falling off the cliff, where it becomes too hard to use.

BRIDGING THE DOM GAP
The ECMAScript standard is designed to standardize the core language wherever it turns up: in the server, in the client, in an authoring tool. But when you put it in the web browser, there's another layer around that, which has to do with HTML and browser windows and dialogs. That is not all standardized. The HTML part, the Document Object Model (DOM), is now being standardized by the W3C. They're not really basing it on anybody's implementation, which may be for the best. They're going in a more general, abstract direction. Level 1 of that standard is supposed to be out sometime this year.

Content authors are complaining, "I can't stand writing for one Document Object Model for Netscape Navigator and for another one for Internet Explorer." They have a right to grouse, and I agree with them. Developers have pointed out that if they can't use a feature or function on both browsers, they often won't use it at all. They're hoping this W3C standard will become the one true way to do Dynamic HTML that will work with the next releases of both browsers.

In the interim, once you have JavaScript in the browser and some level of HTML capability in competing browsers, you can write extra JavaScript - a pretty thin layer - that papers over the differences between the browsers. That universal layer of JavaScript figures out which browser it's running on and uses its available facilities. So JavaScript can play a big role in bridging the gap until the DOM standard is set.

For example, Dynamic HTML includes support for two W3C standards, Cascading Style Sheets, level 1 (CSS1), which allows you to format HTML elements, and Cascading Style Sheets Positioning (CSSP), which allows you to position, stack, and hide or show HTML elements. Right now, developers have to use one DOM to set those properties on Netscape Navigator, and another DOM to set them on Internet Explorer. But the Document Object Model lets you set CSS1 and CSSP properties from JavaScript. If you write a thin layer of functions that take an element and a property value, check the current browser, and then use the correct DOM for the current browser, this layer of functions becomes a high-level Application Programming Interface (API) that your code can call without worrying about which browser it's running on.

To save developers time, we're providing documentation and a basic layer of cross-browser JavaScript code this week to help solve the problem. A document on cross-browser JavaScript and DHTML gives an overview of browser compatibility issues and how to solve them. A second document explains how to set CSS1 properties from JavaScript on both browsers and provides a code generator that automatically writes the necessary JavaScript code for you. A third document explains how to set CSSP properties from JavaScript on both browsers and provides a cross-browser API layer. As a practical example of how this works, we've updated our Dynamic HTML presentation template to support both Navigator 4.x and Internet Explorer 4.x and used it to create a presentation on cross-browser DHTML that anyone can use to teach others. Another example is the Web Building home page, which uses cross-browser DHTML and object-oriented JavaScript to create a floating menu; an article explains how it works and provides code samples.

In the spirit of open source code development, we're encouraging developers to submit their enhancements to this code for incorporation into future versions. In fact, part of the code for the cross-browser API layer was itself derived from a cross-browser API layer written by an independent developer who put it on the web as open source code.

COMMUNICATOR SOURCE CODE
Now that Netscape has made the Communicator source code available, the whole open source software community can work on moving JavaScript forward. I'm currently part of mozilla.org. It's a great team, and a lot of very able people are working on JavaScript. Now I can look at the big picture and facilitate people getting together to make the right things happen with the open source code. That's really great, because I can say, "Somebody wants to use JavaScript to automate something in the browser that wasn't formerly scriptable, and somebody else wants to do a similar sort of automation over here. What's our unified theory of automation or hooks or scriptability?" Then I can help make it happen. I'll try to make sure there's no duplication of effort and that the language is minimal and doesn't get encrusted with features that aren't strictly necessary or that overlap each other in some way.

I think the success of mozilla.org is crucial. Not just for Netscape, but to the open source software community and to the world. Feedback's crucial. Eric Raymond, an open source software expert who wrote a widely discussed paper called "The Cathedral and the Bazaar," makes an excellent point: Software is mostly about getting peer review on your code - not just QA, which is an auditing process at the end. More eyes help. That actually makes better software in many cases. So quality will go up.

That's what I like doing: something that reaches a larger audience, something creative, something that helps people get things done. JavaScript fills a real need, and it's showing up in other places. Adobe has put it in Acrobat, for instance.

At my last job, we never shipped product. It was all very intellectually challenging and stimulating cross-disciplinary research. But unless products get into people's hands, that seems sterile to me.

"Content creation

should not be

recondite. It

should not be

this bizarre

arcana that only

experts and

gold-plated

computer science

gurus can do."