Dan Webb - Accelerated DOM Scripting with Ajax, APIs, and Libraries

T his chapter takes a brief walk down memory lane so you can get a sense of how the industry has changed over the last decade, including the rise of Ajax and its influence on the popularity of JavaScript. It then explains how JavaScript gets evaluated in the browser and how to plan for that. You'll learn ways to debug applications and the tools you can use to do so. It's important to understand how your code is working to fix those pesky bugs that haunt you.

JavaScript has come a long way since its inception back in 1995. Initially used for basic image and form interactions, its uses have expanded to include all manner of user interface manipulation. Web sites are no longer static. From form validation, to animation effects, to sites that rival the flexibility and responsiveness traditionally found in desktop applications, JavaScript has come into its own as a respected language. Traditional (and expensive) desktop applications such as word processors, calendars, and e-mail are being replicated in cheaper (and often easier-to-use) Web-based versions such as Writely, 30 Boxes, and Google Mail.

Over the course of 10 years, the popularity of JavaScript has increased and waned; fortunately, it is now making its triumphant return. But why now? One word: ubiquity ("the state of being everywhere at once"). The goal of most developers has been to have the work they produce be available and accessible to everyone. HTML accomplished this goal early on. Much of the format matured before the Internet really took off in the late 1990s. The HTML you produced for one browser would appear mostly the same in all other browsers: Mac, PC, or Linux.

JavaScript was still quite immature, however. Its capability to interact with the HTML document was inconsistent across browsers. Its two main facilitators, Netscape and Internet Explorer (IE), implemented very different approaches, which meant that two completely different implementations were required to complete the same task. People often tried to create helper scripts, or sometimes even full-blown JavaScript libraries, to bridge the gap. Keep in mind that JavaScript libraries weren't that popular back in the day. Most saw them as bloated and unnecessary to achieve what they needed. The libraries certainly eased development, but they were large in comparison with the problems people were trying to solve with JavaScript. Remember that broadband certainly wasn't what it is today. Tack bandwidth concerns onto security concerns and entire companies disabling JavaScript outright, and you have a situation in which JavaScript seemed like a toy language. You had something that seemed the Web could do without.

With IE a clear victor of the "browser wars," Netscape languished. You might have concluded that developers would develop only for IE after it garnered more than 90 percent of the market. And many did (including me). But that ubiquity still didn't exist. Corporate environments and home users continued to use Netscape as a default browser. Clients I worked with still demanded Netscape 4 compliance, even heading into the new millennium. Building any sort of cross-browser functionality was still a hassle except for processes such as form validation.