JavaScript Is More Than You Might Think

After completing this chapter, you will be able to

• Understand the history of JavaScript.

• Recognize the parts of a JavaScript program.

• Use the javascript pseudo-protocol.

• Understand where JavaScript fits within a webpage.

• Understand what JavaScript can and cannot do.

• Understand how JavaScript is used in Windows 8.

A brief history of JavaScript

JavaScript isn’t Java. There! With that clarification out of the way, you can move on to bigger, more important learning, like how to make cool sliders. In all seriousness, JavaScript is one implementation of a specification known as ECMAScript. You’ll learn more about ECMAScript later in this chapter.

Where did JavaScript come from? You might not know the rich and storied history of JavaScript—and you might not really care much about it, either. If that’s the case, you might be tempted to jump ahead to the next chapter and begin coding JavaScript. Doing so, of course, would be a mistake—you’d miss all the wonderful information that follows in this chapter. And understanding a bit about the history of JavaScript is important to understanding how the language is implemented in various environments today.

JavaScript was originally developed by Brendan Eich at Netscape sometime in 1995–1996. Back then, the language was called LiveScript. That was a great name for a new language—and the story could have ended there. However, in an unfortunate decision, the folks in marketing had their way, and the language was renamed to JavaScript. Confusion soon ensued. You see, Java was the exciting new language at the time, and someone decided to try to capitalize on Java’s popularity by using its name. As a result, JavaScript found itself associated with the Java language. This was a disadvantage for JavaScript, because Java, although popular in the sense that it was frequently used, was also unpopular because it had earned a fairly bad reputation—developers used Java in websites to present data or to add useless enhancements (such as annoying scrolling text). The user experience suffered because Java required a plug-in to load into the web browser, slowing down the browsing process and causing grief for visitors and accessibility problems. Only in recent years has JavaScript begun to separate from this negative Java association, but, almost weekly, I still hear people confuse Java and JavaScript. You’ll hopefully no longer do that!

JavaScript is not a compiled language, which makes it look and feel like a language that lacks power. But programmers new to JavaScript soon came to realize its strengths and usefulness for both simulating and creating interactivity on the World Wide Web. Up until that realization, programmers developed many websites using only simple Hypertext Markup Language (HTML) and graphics that often lacked both visual appeal and the ability to interact with the site’s content. With Microsoft Windows 8, JavaScript now has an avenue for creating full-fledged applications that don’t rely on the web browser.

Early JavaScript concentrated on client-side form validation and working with images on webpages to provide rudimentary, although helpful, interactivity and feedback to the visitor. When a visitor to a website filled in a form, JavaScript instantly validated the contents of the web form rather than making a round-trip to the server. Especially in the days before broadband was pervasive, preventing the round-trip to the server was a great way to help applications seem a little quicker and more responsive—and it still is.

Enter Internet Explorer 3.0

With the release of Microsoft Internet Explorer 3.0 in 1996, Microsoft included support for core JavaScript, known in Internet Explorer as JScript, and support for another scripting language called Microsoft Visual Basic, Scripting Edition, or VBScript. Although JavaScript and JScript were similar, their implementations weren’t exactly the same. Therefore, methods were developed to detect which browser the website visitor was using and respond with appropriate scripting. This process is known as browser detection, and is discussed in Chapter 11. Although it is considered undesirable for most applications, you’ll still see browser detection used, especially with the advent of mobile devices that have their own special look and feel.

And then came ECMAScript

In mid-1997, Microsoft and Netscape worked with the European Computer Manufacturers Association (ECMA) to release the first version of a language specification known as ECMAScript, more formally known as ECMA-262. Since that time, all browsers from Microsoft have implemented versions of the ECMAScript standard. Other popular browsers, such as Firefox, Safari, and Opera, have also implemented the ECMAScript standard.

ECMA-262 edition 3 was released in 1999. The good news is that browsers such as Microsoft Internet Explorer 5.5 and Netscape 6 supported the edition 3 standard, and every major browser since then has supported the version of JavaScript formalized in the ECMA-262 edition 3 standard. The bad news is that each browser applies this standard in a slightly different way, so incompatibilities still plague developers who use JavaScript.

The latest version of ECMAScript, as formalized in the standard known as ECMA-262, was released in late 2009 and is known as ECMA-262 edition 5. Version 4 of the specification was skipped for a variety of reasons and to avoid confusion among competing proposals for the standard. ECMA-262 edition 5.1 is becoming more widely supported as of this writing and will likely (I’m hopeful) be in versions of popular browsers such as Internet Explorer, Chrome, Firefox, Opera, and Safari by the time you read this book.

It’s important to note that as a developer who is incorporating JavaScript into web applications, you need to account for the differences among the versions of ECMA-262, and among the many implementations of JavaScript. Accounting for these differences might mean implementing a script in slightly different ways, and testing, testing, and testing again in various browsers and on various platforms. On today’s Internet, users have little tolerance for poorly designed applications that work in only one browser.

Accounting for those differences has become much easier in the last few years, and there are two primary reasons. First, web browsers have consolidated around the specifications for HTML, CSS, and JavaScript, and the vendors have worked to bring their interpretation of the specifications closer to one another. The second reason that accounting for differences has become easier is that JavaScript libraries have become more popular. Throughout the book, I’ll show the use of the jQuery library to make JavaScript easier.

So many standards...

If you think the standards of JavaScript programming are loosely defined, you’re right. Each browser supports JavaScript slightly differently, making your job—and my job—that much more difficult. Trying to write about all these nuances is more challenging than writing about a language that is implemented by a single, specific entity, like a certain version of Microsoft Visual Basic or Perl. Your job (and mine) is to keep track of these differences and account for them as necessary, and to try to find common ground among them as much as possible.

The DOM

Another evolving standard relevant to the JavaScript programmer is the Document Object Model (DOM) standard developed by the World Wide Web Consortium (W3C). The W3C defines the DOM as “a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of documents.” What this means for you is that you can work with a specification to which web browsers adhere to develop a webpage in a dynamic manner. The DOM creates a tree structure of objects for HTML and Extensible Markup Language (XML) documents and enables scripting of those objects. JavaScript interacts heavily with the DOM for many important functions.

Like JavaScript, the DOM is interpreted differently by every browser, making life for a JavaScript programmer more interesting. Internet Explorer 4.0 and earlier versions of Netscape included support for an early DOM, known as Level 0. If you use the Level 0 DOM, you can be pretty sure that you’ll find support for the DOM in those browsers and in all the browsers that came after.

Microsoft Internet Explorer 5.0 and Internet Explorer 5.5 included some support for the Level 1 DOM, whereas Windows Internet Explorer 6.0 and later versions include some support for the Level 2 DOM. The latest versions of Internet Explorer, Chrome, Firefox, Safari, and Opera support the Level 3 DOM in some form. Safari provides a representation of the WebKit rendering engine. The WebKit rendering engine is also used as the basis for the browser on devices such as the iPhone and iPad and on Android-based devices.

If there’s one lesson that you should take away while learning about JavaScript standards and the related DOM standards, it’s that you need to pay particular attention to the code that you write (no surprise there) and the syntax used to implement that code. If you don’t, JavaScript can fail miserably and prevent your page from rendering in a given browser. Chapter 12, covers the DOM in much greater detail.