What’s that old George Santayana saying? “Those who cannot remember the past are
condemned to repeat it.” There are reasons that you’re forced to take history classes in school, reasons why you value experience, or even reasons why you might ask advice from the elderly.
There is knowledge and great power in knowing the origins of something before diving in head
ptg8286261 first and repeating mistakes of the past unnecessarily. Learning history is the easiest way to plan
for the future. With that in mind, let’s take a brief look at where JavaScript came from; this will also help you when you’re having conversations about the language with other people. Many don’t take the time to learn this stuff—hopefully, you will.
Origins
Most people will tell you that Java and JavaScript are completely unrelated. It’s true that they are very different languages, but their pasts are intertwined quite a bit. Without Java, there would have been no JavaScript (or “LiveScript” as it was originally named). The original purpose fueling JavaScript was to create a language that would give easy control and access of Java Applets in the browser. We don’t use Java Applets anymore, but they were basically inter-active blobs in the middle of an HTML document, sometimes containing an entire application.
It’s like the olden-days version of Flash or HTML5’s canvas element. JavaScript was intended to let designers hook into these applets without having to use a more intense language like Java.
This initiative was championed by a little browser maker called Netscape in late 1995 (parent company, Mozilla), but you probably know them by their current name, Firefox.
Even though the intention of JavaScript was to work with Java Applets, we all know that users never use the things we make in the way we think they should. Designers started heavily using JavaScript to change around HTML, adding some behavior like roll-over effects to Web pages (we mostly do this with CSS now).
The language had great success because of its ease of use and its dynamic nature. You could do a lot of cool stuff relatively quickly, which is a key to the success of any product. The support was poor; there were no real tools to help test code other than the browser, and there was a growing mountain of security holes with the browser implementations of the language, but people loved it. It continued to explode despite being written off by traditional programmers as
“not a real language.” That attitude, to an extent, still exists among the hardcore development community, but I can assure you, JavaScript is indeed a programming language. It becomes more and more evident with every passing year and with every added feature.
With subsequent releases of supporting browsers, many of the security holes in JavaScript were planned for and blocked in various ways. This created a slightly tainted perception of JavaScript with the public. When I was first starting out, the language was thought of as easily exploited, and many people around the community made an active decision to turn off JavaScript as they browsed the Web. This attitude, although fading quickly, still exists in pockets and is the driving reason that it is best practice to be sure all your content is accessible and your applica-tions are usable without JavaScript turned on.
For a long time Internet Explorer did not support JavaScript, but rather used a proprietary language with the same intention of providing interaction with embedding page elements (like the Java Applets). They called this JScript. We all hated it, and it launched the bad practice of browser detection (which is still around in various forms). Designers would have to check the browser for JavaScript support, write the JavaScript, then either ignore Internet Explorer,
ptg8286261 A People’s History of JavaScript 23
or rewrite the functionality in JScript to create a consistent user experience. It was a terrible model, but everyone followed it for lack of a better way.
This time in the front-end scripting world wasn’t all for nothing, though. Through the frustra-tion of browser compatibility problems came a desire to create some form of Web standards and a common language that would work across many browsers. This first attempt at stan-dardization/merging of JavaScript and Jscript was called EMCAScript. This new language was more of a standardized version of JavaScript, but we still called it JavaScript, obviously, or this book would be called Learning EMCAScript . But it did kickstart the conversation about the Web needing some form of standardization.
This conversation also brought to light problems with how browsers were creating the outline for an HTML document, which was JavaScript’s main access to the Web. The browsers’ incon-sistencies this created were the root problem. At this point in history we started to see the power of current-day JavaScript take its form. This agreed-upon universal document outline was eventually called the document object model (DOM). Creating a truly universal DOM led the Web back to its roots where the actual structure of the document was just that—structure, without communicating any information about presentation. This was the first step toward a true separation between structure, presentation, and behavior. As you learned in the previous chapter, it wasn’t until years later that the official term for this was coined for Web and we entered the age of progressive enhancement.
In 1999, Microsoft created the earliest stage of Ajax in the form of an ActiveX control called XMLHTTP, which allowed internal content areas of an HTML document to be updated without refreshing the browser window, wasting valuable bandwidth. This feature was so popular and highly desired that other browser makers adopted it almost immediately under its current (technical) name, the XMLHttpRequest object. It wasn’t until 2005 that the term Ajax was coined, but the underlying technology is still the XMLHttpRequest object in JavaScript.
All these standards, browser wars, and debates that happened throughout the years contributed to what you use today in JavaScript. It is important to know what is going on right now, but it is equally important to learn about the origins, how we got to where we are, and the evolution of the language so you can recognize times when trends seem to be circling back to old ways.
Knowing the history and being able to tell when a new technology is going to fail (because something similar already failed in the past) can save you a lot of frustration in learning tech-nologies that have shortsighted futures.
Progressive Enhancement
As mentioned in the previous chapter, progressive enhancement is the layered approach we take when building for the Web, where the main focus is placed on accessibility of content and the user, rather than the browser (that’s graceful degradation). We use HTML for structure, CSS for presentation, and JavaScript for behavior. But you already knew that from Chapter 1 , “Progressive Enhancement.” There was lot of embedded and inline JavaScript happening throughout the Web. It made sites very difficult to maintain, and this methodology helped
ptg8286261 guide the creation of a Web that was not only more pleasant from a user standpoint, but also
much more maintainable from a developer/designer standpoint. There was no more guessing where an update needed to be made in the code; you knew exactly what layer a change lived on, and it was inevitably separated out into its own cacheable file where the modifications could be isolated from the rest of the site or application.