JAVASCRIPT(ID:2133/jav008)

Now ECMASCRIPT

Brendan Eich Netscape 1995

a scripting language developed by Netscape to enable Web authors to design interactive sites. Although it shares many of the features and structures of the full JAVA language, it was developed separately. JAVASCRIPT can interact with HTML source code, enabling Web authors to spice their sites with dynamic content. JAVASCRIPT is endorsed by a number of software companies, and it is an Open Source product that anyone can use without purchasing a license. It is supported by recent browsers from Netscape and MS; although IE supports a subset, which MS calls JSCRIPT.  "Within HTML, JAVASCRIPT reigns supreme and is the default script. It has C++ and JAVA like structures and can port some of the C/C++ and JAVA code. JAVASCRIPT basically extends the HTML language, but it's scope seems confined to the browser".  http://javascript.com  http://javascript.internet.com
Related languages
LiveScript => JAVASCRIPT   Renaming
JAVASCRIPT => ECMASCRIPT   Evolution of

Samples:
References:
  • Eichs, Brendan "Making Web Pages Come Alive" TechVision column (June 24 1998) at NS website view details Extract: Anecdote
    I came to Netscape in April 1995, after seven years at Silicon Graphics and three years at MicroUnity Systems Engineering. Netscape was about a year old then and was looking for someone to work on a scripting language or some kind of language inside the browser that could be used to automate parts of a web page or make a web page more dynamic. Java had been around for five years at First Person and Sun, and had been retooled for the web in late 1994. Netscape was the first Java licensee, so the issue became: Can we do just Java, or do we need another language?
    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.

  • Marc Andreessen "Innovators of the Net: Brendan Eich and Javascript" TechVision column (June 24 1998) at NS website view details
  • Danny Goodman, Brendan Eich "JavaScript Bible, Gold Edition" John Wiley & Sons NY 2001 view details Extract: LiveScript becomes JavaScript
    LiveScript becomes JavaScript
    In early December 1995, Netscape and Sun jointly announced that the scripting language would thereafter be known as JavaScript. Though Netscape had several good marketing reasons for adopting this name, the changeover may have contributed more confusion to both the Java and HTML scripting worlds than anyone had expected.

    Before the announcement, the language was already related to Java in some ways. Many of the basic syntax elements of the language were reminiscent of the C and C++ style of Java. For client-side scripting, the language was intended for very different purposes than Java — essentially, to function as a programming language integrated into HTML documents, rather than as a language for writing applets that occupy a fixed rectangular area on the page (and that are oblivious to whatever else may be on the page). Instead of Java’s full-blown programming language vocabulary (and conceptually difficult object-oriented approach), JavaScript had a small vocabulary and more easily digestible programming model.

    The true difficulty, it turned out, was making the distinction between Java and JavaScript clear to the world. Many computer journalists made major blunders when they said or implied that JavaScript was a simpler way of building Java applets. To this day, many programmers believe JavaScript to be synonymous with the Java language: They post Java queries to JavaScript-specific Internet newsgroups and mailing lists.

    The fact remains today that Java and JavaScript are more different than they are similar. Java support in a browser or operating system does not automatically imply JavaScript support. The two languages require entirely different interpreter engines to execute their lines of code. Whereas JavaScript support shipped in every platform-specific version of Navigator 2 in February 1996, Java was not available for Windows 3.1 users until late in the life of Navigator 3. (Many squirrelly technical issues make it difficult for this modern language to work in an “ancient” MS-DOS operating system.) Extract: JavaScript: A Language for All
    JavaScript: A Language for All
    The Java language is derived from C and C++, but it is a distinct language. Its main audience is the experienced programmer. That leaves out many Web page authors. I was dismayed at this situation when I first read about Java’s specifications. I would have preferred a language that casual programmers and scripters who use authoring tools such as ToolBook, HyperCard, and even Visual Basic could adopt quickly. As these accessible development platforms have shown, nonprofessional authors can dream up many creative applications, often for very specific tasks that no programmer would have the inclination to work on. Personal needs often drive development in the classroom, office, den, or garage. But Java was not going to be that kind of inclusive language.
    My spirits lifted several months later, in November 1995, when I heard of a scripting language project brewing at Netscape. Initially born under the name LiveScript, this language was developed in parallel with Netscape’s Web server'software. The language was to serve two purposes with the same syntax. One purpose was as a scripting language that Web server administrators could use to manage the server and connect its pages to other services, such as back-end databases and search engines for users looking up information. Extending the “Live” brand name further, Netscape assigned the name LiveWire to the database connectivity usage of JavaScript on the server.
    On the client side — in HTML documents — these scripts could be used to enhance Web pages in a number of ways. For example, an author could use LiveScript to make sure that the information a user entered into a form would be of the proper type. Instead of forcing the server or database to do the data validation (requiring data exchanges between the client browser and the server), the user's computer handles all the calculation work — putting some of that otherwise wasted horsepower to work. In essence, LiveScript could provide HTML-level interaction for the user.
    As the intensity of industry interest in Java grew, Netscape saw another opportunity for LiveScript: as a way for HTML documents (and their users) to communicate with Java applets. For example, a user might make some preference selections from checkboxes and pop-up selection lists located at the top of a Web page. Scrolling down to the next screenful, the user'sees text in the Java applet scrolling banner on the page that is customized to the settings made above. In this case, the LiveScript script sends the text that is to appear in the scrolling banner to the applet (and perhaps a new color to use for the banner’s background and text). While this is happening, the server doesn’t have to worry a bit about it, and the user hasn’t had to wait for communication between the browser and the server. As great an idea as this was initially, this connectivity feature didn’t make it into Navigator 2 when JavaScript first became available.
  • Brockmeier, Joe "The Problem with JavaScript" NewsFactor Network Report December 17, 2002 view details
  • Library of Congress Subject Headings J39 view details
    Resources
    • BLog on JS
      With DHTML and AJAX hot (or hot again; we've been here before, and I don't like either acronym), I am asked frequently these days about JavaScript, past and future. In spite of the fact that JS was misnamed (I will call it JS in the rest of this entry), standardized prematurely, then ignored and stagnated during most of its life, its primitives are strong enough that whole ecologies of toolkit and web-app code have emerged on top of it. (I don't agree with everything Doug Crockford writes at the last two links, but most of his arrows hit their targets.)

      Too many of the JS/DHTML toolkits have the "you must use our APIs for everything, including how you manipulate strings" disease. Some are cool, for example TIBET, which looks a lot like Smalltalk. Some have real value, e.g. Oddpost, which Yahoo! acquired perhaps as much for its DHTML toolkit as for the mail client built on that toolkit.

      Yet no JS toolkit has taken off in a big way on the web, probably more on account of the costs of learning and bundling any given API, than because of the "you must use our APIs and only our APIs" problem. So people keep inventing their own toolkits.

      Inventing toolkits and extension systems on top of JS is cool. I hoped that would happen, because during Netscape 2 and 3 days I was under great pressure to minimize JS-the-language, implement JS-the-DOM, and defer to Java for "real programming" (this was a mistake, but until Netscape hired more than temporary intern or loaner help, around the time Netscape 4 work began, I was the entire "JS team" -- so delegating to Java seemed like a good idea at the time). Therefore in minimizing JS-the-language, I added explicit prototype-based delegation, allowing users to supplement built-in methods with their own in the same given single-prototype namespace.

      In listening to user feedback, participating in ECMA TG1 (back during Edition 1 days, and again recently for E4X and the revived Edition 4 work), and all the while watching how the several major "JS" implementors have maintained and evolved their implementations, I've come to some conclusions about what JS does and does not need.


      JS is not going away, so it ought to evolve. As with sharks (and relationships, see Annie Hall), a programming language is either moving forward, or it's dead. Now dead languages (natural and programming) have their uses; fixed denotation and grammar, and in general a lack of "versionitis", are virtues. You could argue that JS's stagnation, along with HTML's, was beneficial for the "Web 1.0" build-out of the last decade. But given all the ferment on the web today, in XUL and its stepchildren, and with user scripting, there should be a JS2, and even a JS1.6 on the way toward JS2.
      JS does not need to become Java, or C#, or any other language.
      JS does need some of its sharp corners rounded safely. See the table below for details.
      Beyond fixing what was broken in JS1, JS should evolve to solve problems that users face today in the domains where JS lives: web page and application content (including Flash), server-side scripting (whether Rhino or .NET), VXML and similar embeddings, and games.
      For example, it should be trivial in a future version of JS to produce or consume a "package" of useful script that presents a consistent interface to consumers, even as its implementation details and new interfaces evolve to better meet existing requirements, and to meet entirely new requirements. In no case should internal methods or properties be exposed by default.
      It's clear to me that some users want obfuscated source code, but I am not in favor of standardizing an obfuscator. Mozilla products could support the IE obfuscator, if someone wants to fix bug 125525. A standard obfuscator is that much less obscure, besides being unlikely to be adopted by those who have already invented their own (who appear to be the only users truly motivated by a need for obfuscation at this point).
      A more intuitive numeric type or type tower would help many users, although to be effective it would have to be enabled via a new compile-time option of some sort. Numeric type improvements, together with Edition 4's extensible operator and unit proposals, would address many user requests for enhancement I've heard over the years.
      Too much JS, in almost every embedding I've seen, suffers from an execution model that appears single-threaded (which is good for most users) yet lacks coroutining or more specific forms of it such as generators (Boo has particularly nice forms, building on Python with a cleanup or two). So users end up writing lots of creepy callbacks, setTimeout chains, and explicit control block state machines, instead of simply writing loops and similar constructs that can deliver results one by one, suspending after each delivery until called again.
      That's my "do and don't" list for any future JS, and I will say more, with more specifics, about what to add to the language. What to fix is easier to identify, provided we can fix compatibly without making a mess of old and new.
      external link