 |
JavaScript: How Did We Get Here?by Steve Champeon04/06/2001 JavaScript. Spawned in 1995 by the need to make Netscape Navigator's newly added support for Java applets more accessible to non-Java programmers and web designers, a powerful scripting language too often described as "simple." Plagued in its early days by security flaws, crippled by a lack of powerful development tools such as integrated development environments, debuggers, and meaningful error messages, extended to contexts that range far beyond the initial intent of its designers, and saddled with the legacy of incompatible browser object models, JavaScript has suffered for years at the hands of those who would criticize it for being too unlike Java, or too much like Perl, or too often used by well-meaning but otherwise ignorant web designers, shoehorned into pages without thought of future compatibility, intelligent abstraction, or code reuse. Yet it is by far the most popular language on the Web, the foundation for the next generation of dynamic client-side Web applications, a solid core with amazing potential and power. So why don't more programmers view JavaScript as an essential part of their toolbox? Let's look at the history of JavaScript (n�e LiveScript) and take a good, hard look at where it came from -- and where it is going. Back to the early days of the webRewind to early 1995. Netscape had just hired Brendan Eich away from MicroUnity Systems Engineering, to take charge of the design and implementation of a new language. Tasked with making Navigator's newly added Java support more accessible to non-Java programmers, Eich eventually decided that a loosely-typed scripting language suited the environment and audience, namely the few thousand web designers and developers who needed to be able to tie into page elements (such as forms, or frames, or images) without a bytecode compiler or knowledge of object-oriented software design.
The language he created was christened "LiveScript," to reflect its dynamic nature, but was quickly (before the end of the Navigator 2.0 beta cycle) renamed JavaScript, a mistake driven by marketing that would plague web designers for years to come, as they confused the two incessantly on mailing lists and on Usenet. Netscape and Sun jointly announced the new language on December 4, 1995, calling it a "complement" to both HTML and Java. JavaScript quickly took on a life of its own, more commonly used to manipulate images and document contents than to control Java applets, perhaps reflecting the then-current trend (driven by typographer David Siegel and others) to bring full interactivity and sophisticated user interface and typography concepts to the formerly static Web. It is telling that a vast majority of the scripts used in the first couple of years simply swapped one image for another in response to user-generated mouse events. The astonishing success of JavaScript as a programming language with a low barrier to entry (no compiler needed, scripts could be copied and pasted into existing HTML pages with little to no editing, seemed tightly bound to the browser) led many experienced programmers to write it off as a toy. Early conflicts between JavaScript's power and the relatively under-powered rendering engine caused early UI experiments such as dynamic, client-side tree widgets and the like to flash annoyingly on the screen. Disdain for a language that apparently required no skill to use, lacked an IDE and a reliable cross-platform debugger, and could only be tested in the context of the actual browser in which the page will be viewed, combined with a few highly publicized security flaws and several books aimed at non-programmers, caused many to write off JavaScript as a "simple" language for beginners and overshadowed its amazing potential. Subsequent releases of Navigator included support for script-driven interaction with plugins, a better, more rigorous security model, and more. Netscape's LiveWire introduced JavaScript as a server-side language capable of performing database queries and other advanced features. However, the server-side scripting never achieved the popularity of ASP or Perl or Cold Fusion, and was mostly neglected by all but Netscape's server customers. JavaScript's destiny was to be the way document authors control and extend the capabilities of the client. Microsoft's response to JavaScriptMicrosoft responded to JavaScript in part by releasing its own VBScript language (itself capable of hooking into embedded components, although initially limited to the platform, Windows, where those components were first implemented). In addition, they released a port of JavaScript called "JScript," on July 16, 1996. Internet Explorer 3.0, otherwise an amazing technical accomplishment from the standpoint of support for new W3C-sanctioned standards like Cascading Stylesheets, was one revision behind Navigator's JavaScript -- which by then allowed for the wildly popular image swapping -- and would remain behind until the release of version 3.02. Many designers simply checked for Navigator in their scripts and ignored IE as a lost cause, just as early CGI programmers checked for "Mozilla" in the user agent environment variable, leading to the ridiculous convention, still followed today, whereby practically all of the major browsers announce themselves as "Mozilla" first, then "(compatible; BrowserName)" second. In short, JavaScript took on a not-entirely-deserved reputation for being yet another roadblock to a truly cross-platform standards-driven Web. ECMAScript: an attempt at standardizationThe introduction of IE3 and its unfortunate lack of support for the document.images array led Netscape and Sun to standardize the language with help from the European Computer Manufacturers Association (ECMA), giving us yet another name for what had by now become a strange hybrid of powerful and universally supported core functionality and often incompatible object models: ECMAScript. Standardization was begun in conjunction with ECMA in November 1996 and adopted in June 1997 by ECMA and by ISO in April 1998. In the meantime, as ECMAScript was being standardized (but unfortunately neglecting everything but the core language), Netscape and Microsoft introduced the 4.0 browser generation, each browser with its own completely proprietary document object model, and "Dynamic HTML" became the next morass into which JavaScript's good heart was dragged. Fiefdoms of functionalityThe nightmarish workarounds and multiple implementations necessary in order to provide cross-browser DHTML applications are legion. Some folks provided libraries that made Navigator act as much like IE as possible. Others provided libraries that made IE act as much like Navigator as possible. Everyone provided libraries that helped programmers wrap incompatible code with a consistent API, but soon found that the lowest common denominator required for truly cross-platform code was a bit too low for all but the most basic applications, and so many deserted Navigator entirely for IE on Windows, further fragmenting the Web into little fiefdoms of functionality. While the browser wars were raging, Microsoft, Netscape, and dozens of other companies worked with the W3C to try to lay the groundwork for a truly universal Document Object Model (DOM), while staying as backwards compatible as possible with the original browser object model (referred to as "Level 0" by the framers of the W3C DOM). The desire to get the Web back on track as an SGML-inspired platform, where document structure encodes semantics but not presentation, fueled by the relative simplicity and power of XML, led to another layer of abstraction and several years of incompatible or partial implementations. The open source Mozilla project took years without a stable or widely distributed public release, while Microsoft tightened its hold on the browser market share. DHTML programmers retrenched, for the most part, in response to the complexity of cross-browser DHTML, a new emphasis on standards support, and the rise of other tools for providing interactive content, such as Flash. Where does this leave us today?Fast forward to 2001. JavaScript's dependence on context-specific object models is both the core of its strength and the fatal flaw in its implementation. Unlike Perl or Java or other languages, JavaScript's capabilities can't be extended or overridden by developers, who are instead utterly dependent on the caprice of the browser vendors. JavaScript is flexible enough to overcome many weaknesses, but not enough to overcome fundamental, context-enslaved object model incompatibilities. Also, the inability to hide source continues to be an obstacle to the development of applications whose code the owners wish to protect as their intellectual property. Continuing lack of an IDE, debugger, and other standard development tools are still considered insurmountable problems by many programmers, who defend their Windows-only applications with the not unreasonable excuse that debugging is too hard on a platform that lacks a debugger. The WYSIWYG tools vendors caught up with some excellent cross-browser JavaScript libraries integrated into their page building tools, only to be caught out by Mozilla's abandonment of the old Netscape document.layers object model. And yet, JavaScript has evolved into an incredibly powerful m�lange of the best features of Perl (associative arrays, loosely typed variables, regular expressions), C/C++ and Java (clean, block-parsed syntax, objects and classes, highly evolved date, math, and string libraries), and TCL (widely ported application control environment), to name a few, with all the power of the W3C DOM in the latest browsers (Mozilla, Netscape 6, IE6/Windows and IE5/Mac). Companies such as Blox, KnowNow, and others are using client-side JavaScript in combination with intelligent server-side tools to deliver the next generation of Web-based applications. Even Microsoft, with all the ballyhoo about C#, seems to have recognized the power of JavaScript: Pick any MSDN sample application or one-off script, and odds are it's written at least partly in JavaScript. Java has suffered at the hands of internecine and highly publicized feuds between Sun and, well, pretty much everyone. VBScript is being abandoned by Microsoft, but the compiled C# can't be expected to fill the ever-needed role of scripting language. JavaScript has conquered the Web. So why don't you know more about it? What is there to know? How should you begin to address your long-standing neglect of this powerful and mature language? We'll address these issues and more in our next article. Steve Champeon is a recognized developer, author, and editor specializing in Web technologies. At his "day job," he serves as the CTO of hesketh.com, a Web services firm in Raleigh, NC. Return to the JavaScript and CSS DevCenter.
Comments on this article
1 to 5 of 5
1 to 5 of 5
|
|
|
|
||||||||
© 2016, O’Reilly Media, Inc. (707) 827-7019 (800) 889-8969 All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. |
||||||||
