Back to description
When JavaScript first appeared in 1995, its main purpose was to handle some of the input validation that had previously been... more
When JavaScript first appeared in 1995, its main purpose was to handle some of the input validation that had previously been left to server-side languages such as Perl. Prior to that time, a round-trip to the server was needed to determine if a required field had been left blank or an entered value was invalid. Netscape Navigator sought to change that with the introduction of JavaScript. The capability to handle some basic validation on the client was an exciting new feature at a time when use of telephone modems was widespread. The associated slow speeds turned every trip to the server into an exercise in patience.
Since that time, JavaScript has grown into an important feature of every major web browser on the market. No longer bound to simple data validation, JavaScript now interacts with nearly all aspects of the browser window and its contents. JavaScript is recognized as a full programming language, capable of complex calculations and interactions, including closures, anonymous (lambda) functions, and even metaprogramming. JavaScript has become such an important part of the Web that even alternative browsers, including those on mobile phones and those designed for users with disabilities, support it. Even Microsoft, with its own client-side scripting language called VBScript, ended up including its own JavaScript implementation in Internet Explorer from its very earliest version.
The rise of JavaScript from a simple input validator to a powerful programming language could not have been predicted. JavaScript is at once a very simple and very complicated language that takes minutes to learn but years to master. To begin down the path to using JavaScript's full potential, it is important to understand its nature, history, and limitations.
... less
The introduction of JavaScript into web pages immediately ran into the Web’s predominant language, HTML. As part of its original... more
The introduction of JavaScript into web pages immediately ran into the Web’s predominant language, HTML. As part of its original work on JavaScript, Netscape tried to figure out how to make JavaScript coexist in HTML pages without breaking those pages’ rendering in other browsers. Through trial, error, and controversy, several decisions were finally made and agreed upon to bring universal scripting support to the Web. Much of the work done in these early days of the Web has survived and become formalized in the HTML specification.
At the core of any language is a description of how it should work at the most basic level. This description typically defines... more
At the core of any language is a description of how it should work at the most basic level. This description typically defines syntax, operators, data types, and built-in functionality upon which complex solutions can be built. As previously mentioned, ECMA-262 defines all of this information for JavaScript in the form of a pseudolanguage called ECMAScript (often pronounced as "ek-ma-script").
ECMAScript as defined in ECMA-262, Third Edition, is the most-implemented version among web browsers. The Fourth Edition introduced new syntax, operators, objects, and concepts that dramatically alter how JavaScript works. For this reason, and due to a lack of support, the following information is based only on ECMAScript as defined in the Third Edition (see Chapter 22 for information on the Fourth Edition and JavaScript 2.0).
The nature of variables in JavaScript, as defined in ECMA-262 Third Edition, is quite unique compared to other languages.... more
The nature of variables in JavaScript, as defined in ECMA-262 Third Edition, is quite unique compared to other languages. Being loosely typed, a variable is literally just a name for a particular value at a particular time. Since there are no rules defining the type of data that a variable must hold, a variable’s value and data type can change during the lifetime of a script. Though this is an interesting, powerful, and problematic feature, there are many more complexities related to variables.
A reference value (object) is an instance of a specific reference type. In ECMAScript, reference types are structures used... more
A reference value (object) is an instance of a specific reference type. In ECMAScript, reference types are structures used to group data and functionality together and are often incorrectly called classes. Although technically an object-oriented language, ECMAScript lacks some basic constructs that have traditionally been associated with object-oriented programming, including classes and interfaces. Reference types are also sometimes called object definitions, since they describe the properties and methods objects should have.
Object-oriented (OO) languages typically are identified through their use of classes to create multiple objects that have... more
Object-oriented (OO) languages typically are identified through their use of classes to create multiple objects that have the same properties and methods. As mentioned previously, ECMAScript has no concept of classes, and therefore objects are different than in class-based languages.
ECMA-262 defines an object as an “unordered collection of properties each of which contains a primitive value, object, or function.” Strictly speaking, this means that an object is an array of values in no particular order. Each property or method is identified by a name that is mapped to a value. For this reason (and others yet to be discussed), it helps to think of ECMAScript objects as hash tables: nothing more than a grouping of name-value pairs where the value may be data or a function.
Each object is created based on a reference type, either one of the native types discussed in the previous chapter or a developer-defined type.
An anonymous function is any function that doesn’t have a name; these are also sometimes referred to as lambda functions.... more
An anonymous function is any function that doesn’t have a name; these are also sometimes referred to as lambda functions. Anonymous functions are incredibly powerful programming tools and can be used in any number of ways. Consider a typical function declaration:
function functionName(arg0, arg1, arg2) {
//function body
}
As discussed earlier in the book, functions can be declared in this manner or defined as a function expression such as the following:
var functionName = function(arg0, arg1, arg2) {
};
Even though this example is logically equivalent to the previous one, there are some slight differences. The primary difference between function declarations and function expressions, of course, is that the former is loaded into the scope before code execution while the latter is unavailable until that particular line has been evaluated during code execution (discussed in Chapter 5). Another important distinction is that function declarations assign a name to the function, whereas function expressions actually create anonymous functions and assign them to a variable. This means the second example creates an anonymous function with three arguments and assigns it to the variable functionName, but the function itself doesn’t have a name assigned.
It’s also possible to write an anonymous function like this:
function (arg0, arg1, arg2){
This code is completely valid. Of course, the function can never be called because there is no pointer to it. Anonymous functions are typically defined in this way when passing a function into another function as an argument or when returning a function from a function. Recall createComparisonFunction() from Chapter 5:
function createComparisonFunction(propertyName) {
return function(object1, object2){
var value1 = object1[propertyName];
var value2 = object2[propertyName];
if (value1 < value2){
return –1;
} else if (value1 > value2){
return 1;
} else {
return 0;
createComparisonFunction() returns an anonymous function. The returned function will, presumably, be either assigned to a variable or otherwise called, but within createComparisonFunction() it is anonymous. Any time a function is being used as a value, it is being treated as an anonymous function. However, these are not the only uses for anonymous functions.
Though ECMAScript describes the core of JavaScript, the Browser Object Model (BOM) is really the core of using JavaScript... more
Though ECMAScript describes the core of JavaScript, the Browser Object Model (BOM) is really the core of using JavaScript on the Web. The BOM provides objects that expose browser functionality independent of any web page content. A lack of any real specification makes the BOM both interesting and problematic, as browser vendors are free to augment it as they see fit. The commonalities between browsers are de facto standards that have survived browser development mostly for the purpose of interoperability. There is no such thing as a standard BOM implementation or standard BOM interfaces.
Although browser vendors have made a concerted effort to implement common interfaces, the fact remains that each browser... more
Although browser vendors have made a concerted effort to implement common interfaces, the fact remains that each browser presents its own capabilities and flaws. Browsers that are available cross-platform often have different issues even though they are technically the same version. These differences force web developers to either design for the lowest common denominator or, more commonly, use various methods of client detection to work with or around limitations.
Client detection remains one of the most controversial topics in web development. The idea that browsers should support a common set of functionality pervades most conversations on the topic. In an ideal world, this would be the case. In reality, however, there are enough browser differences and quirks that client detection becomes not just an afterthought, but also a vital part of the development strategy.
There are several approaches to determine the web client being used, and each has advantages and disadvantages. It’s important to understand that client detection should be the very last step in solving a problem; whenever a more common solution is available, that solution should be used. Design for the most common solution first and then augment it with browser-specific solutions later.
The Document Object Model (DOM) is an application programming interface (API) for HTML and XML documents. The DOM represents... more
The Document Object Model (DOM) is an application programming interface (API) for HTML and XML documents. The DOM represents a document as a hierarchical tree of nodes, allowing developers to add, remove, and modify individual parts of the page. Evolving out of early Dynamic HTML (DHTML) innovations from Netscape and Microsoft, the DOM is now a truly cross-platform, language-independent way of representing and manipulating pages for markup.
DOM Level 1 became a W3C recommendation in October 1998, providing interfaces for basic document structure and querying. This chapter focuses on the features and uses of DOM Level 1 as it relates to HTML pages in the browser and its implementation in JavaScript. The browsers that have mostly complete implementations of DOM Level 1 are Internet Explorer 6+ (IE 5.5 has several missing features), Firefox, Safari, Chrome, and Opera 7.5+.
The first level of the DOM focuses on defining the underlying structure of HTML and XML documents; DOM Levels 2 and 3 build... more
The first level of the DOM focuses on defining the underlying structure of HTML and XML documents; DOM Levels 2 and 3 build upon this structure to introduce more interactivity and support for more advanced XML features. As a result, DOM Levels 2 and 3 actually consist of several modules that, while related, describe very specific subsets of the DOM:
DOM CoreBuilds upon the level 1 core adding additional methods and properties to nodes
DOM ViewsDefines different views for a document based on stylistic information
DOM EventsExplains how to tie interactivity to DOM documents using events
DOM StyleDefines how to programmatically access and change CSS styling information
DOM Traversal and RangeIntroduces new interfaces for traversing a DOM document and selecting specific parts of it
DOM HTMLBuilds upon the level 1 HTML, adding properties, methods, and new interfaces
This chapter explores each of these modules except for DOM Events, which are covered fully in Chapter 12.
JavaScript’s interaction with HTML is handled through events, which indicate when particular moments of interest occur in... more
JavaScript’s interaction with HTML is handled through events, which indicate when particular moments of interest occur in the document or browser window. Events can be subscribed to using listeners (also called handlers) that execute only when an event occurs. This model, called the observer pattern in traditional software engineering, allows a loose coupling between the behavior of a page (defined in JavaScript) and the appearance of the page (defined in HTML and CSS).
Events first appeared in Internet Explorer 3 and Netscape Navigator 3 as a way to offload some form processing from the server onto the browser. Each browser delivered similar but different APIs that continued for several generations. DOM Level 2 was the first attempt to standardize the DOM events API in a logical way. Firefox, Opera, Safari, and Chrome all have implemented the core parts of DOM Level 2 Events, while Internet Explorer is the only major browser to still use a proprietary event system.
The browser event system is a complex one. Even though three of the four major browsers have implemented DOM Level 2 Events, the specification doesn’t cover all event types. The BOM also supports events and the relationship between these and the DOM events is unclear, as it is not defined by any specification. Further complicating matters is the augmentation of the DOM events API by DOM Level 3. Working with events can be relatively simple or very complex, depending upon your requirements. Still, there are some core concepts that are important to understand.
One of the original uses of JavaScript was to offload some form-processing responsibilities onto the browser instead of relying... more
One of the original uses of JavaScript was to offload some form-processing responsibilities onto the browser instead of relying on the server to do it all. Although the Web and JavaScript have evolved since that time, web forms remain more or less unchanged. The failure of web forms to provide out-of-the-box solutions for common problems led developers to use JavaScript not just for form validation, but also to augment the default behavior of standard form controls.
JavaScript has traditionally been known as one of the most difficult programming languages to debug due to its dynamic nature... more
JavaScript has traditionally been known as one of the most difficult programming languages to debug due to its dynamic nature and years without proper development tools. Errors typically resulted in confusing browser messages such as "object expected" that provided little or no contextual information. The third edition of ECMAScript aimed to improve this situation, introducing the try-catch and throw statements, along with various error types to help developers deal with errors when they occur. A few years later, JavaScript debuggers and debugging tools began appearing for web browsers. By 2008, most web browsers support some JavaScript debugging capabilities.
Armed with the proper language support and development tools, web developers are now empowered to implement proper error-handling processes and figure out the cause of problems.
At one point in time, XML was the standard for structured data storage and transmission over the Internet. The evolution... more
At one point in time, XML was the standard for structured data storage and transmission over the Internet. The evolution of XML closely mirrored the evolution of the web technologies as the DOM was developed for use not just in web browsers but also in desktop and server applications for dealing with XML data structures. Many developers started writing their own XML parsers in JavaScript to deal with the lack of built-in solutions. Since that time, all browsers have introduced native support for XML, the XML DOM, and many related technologies.
In 2002, a group of companies led by BEA Systems proposed an extension to ECMAScript to add native XML support to the language... more
In 2002, a group of companies led by BEA Systems proposed an extension to ECMAScript to add native XML support to the language. In June 2004, ECMAScript for XML (E4X) was released as ECMA-357, which was revised in December 2005. E4X is not its own language; rather, it is an optional extension to the ECMAScript language. As such, E4X introduces new syntax for dealing with XML, as well as for XML-specific objects.
Though browser adoption has been slow, Firefox 1.5 and higher supports almost the entire E4X standard. This chapter focuses on Firefox’s implementation.
In 2005, Jesse James Garrett penned an online article entitled, “Ajax: A New Approach to Web Applications”... more
In 2005, Jesse James Garrett penned an online article entitled, “Ajax: A New Approach to Web Applications” (http://www.adaptivepath.com/ideas/essays/archives/000385.php). This article outlined a technique that he referred to as Ajax, short for Asynchronous JavaScript + XML. The technique consisted of making server requests for additional data without unloading the web page, resulting in a better user experience. Garrett explained how this technique could be used to change the traditional click-and-wait paradigm that the Web had been stuck in since its inception.
The key technology pushing Ajax forward was the XMLHttpRequest (XHR) object, first invented by Microsoft and then duplicated by other browser vendors. Prior to the introduction of XHR, Ajax-style communication had to be accomplished through a number of hacks, mostly using hidden frames or iframes. XHR introduced a streamlined interface for making server requests and evaluating the responses. This allowed for asynchronous retrieval of additional information from the server, meaning that a user click didn’t have to refresh the page to retrieve more data. Instead, an XHR object could be used to retrieve the data and then the data could be inserted into the page using the DOM. And despite the mention of XML in the name, Ajax communication is format-agnostic; the technique is about retrieving data from the server without refreshing a page, not necessarily about XML.
The technique that Garrett referred to as Ajax had, in fact, been around for some time. Typically called remote scripting prior to Garrett’s article, such browser-server communication has been possible since 1998 using different techniques. Early on, server requests could be made from JavaScript through an intermediary such as a Java applet or Flash movie. The XHR object brought native browser communication capabilities to developers, reducing the amount of work necessary to achieve the result.
Renamed as Ajax, the popularity of browser-server communication exploded in late 2005 and early 2006. A renewed interest in JavaScript and the Web in general brought new techniques and patterns for using these capabilities. Therefore, the XHR object is now a necessary tool in every web developer’s toolkit.
JavaScript is an incredibly flexible language that can be used in a variety of styles. Typically, JavaScript is used either... more
JavaScript is an incredibly flexible language that can be used in a variety of styles. Typically, JavaScript is used either in a procedural manner or an object-oriented one. The language, however, is capable of much more intricate and interesting patterns because of its dynamic nature. These techniques make use of ECMAScript language features, BOM extensions, and DOM functionality to achieve powerful results.
Along with the emergence of web applications came a call for the ability to store user information directly on the client... more
Along with the emergence of web applications came a call for the ability to store user information directly on the client. The idea is logical: information pertaining to a specific user should live on that user’s machine. Whether that is login information, preferences, or other data, web application providers found themselves searching for ways to store data on the client. The first solution to this problem came in the form of cookies, a creation of the old Netscape Communications Corporation and described in a specification entitled Persistent Client State – HTTP Cookies (still available at http://cgi.netscape.com/newsref/std/cookie_spec.html). Today, cookies are just one option available for storing data on the client.
The discipline of web development has grown at an extraordinary rate since 2000. What used to be a virtual Wild West, where... more
The discipline of web development has grown at an extraordinary rate since 2000. What used to be a virtual Wild West, where anything went, has evolved into a complete discipline with research and established best practices. As simple web sites grew into more complex web applications, and web hobbyists became paid professionals, the world of web development was filled with information about the latest techniques and development approaches. JavaScript, in particular, was the beneficiary of a lot of research and conjecture. Best practices for JavaScript fall into several categories and are handled at different points in the development process.
With the flurry of interest that Ajax brought back to web development also came a call to restart the browser evolution.... more
With the flurry of interest that Ajax brought back to web development also came a call to restart the browser evolution. As part of this movement, a number of new APIs began to take shape. Some were based on things that browsers had already implemented, some on ideas of how to fix things that were broken, and some were born out of developer demand. The result was a number of specifications describing ways to extend JavaScript in the browser so that it becomes more compatible with how developers are using it.
With the renewed interest in web development since 2004, conversations began taking place among browser vendors and other... more
With the renewed interest in web development since 2004, conversations began taking place among browser vendors and other interested parties as to how JavaScript should evolve. Work on the fourth edition of ECMA-262 began based largely on two competing proposals, one for Netscape?s JavaScript 2.0 and the other for Microsoft?s JScript.NET. Instead of competing in the browser realm, the parties converged back into ECMA to hammer out a proposal for a new language based on JavaScript. Initially, work began on a proposal called ECMAScript 4, and for a long time, this seemed like the next evolutionary step for JavaScript. When a counterproposal called ECMAScript 3.1 was later introduced, it threw the future of JavaScript into question. After much debate, it was determined that ECMAScript 3.1 would be the next step for JavaScript and that a further effort, code named Harmony, would seek to reconcile some features from ECMAScript 4 into ECMAScript 3.1. To understand how this will affect JavaScript in the future, it's important to take a look at all of the steps along this process.
JavaScript libraries help to bridge the gap between browser differences and provide easier access to complex browser features... more
JavaScript libraries help to bridge the gap between browser differences and provide easier access to complex browser features. Libraries come in two forms: general and specialty. General JavaScript libraries provide access to common browser functionality and can be used as the basis for a web site or web application. Specialty libraries do only specific things and are intended to be used for only parts of a web site or web application. This appendix provides an overview of these libraries and some of their functionality, along with web sites that you can use as additional resources.
Writing JavaScript is a lot like writing in any other programming language except that until recently there were fewer tools... more
Writing JavaScript is a lot like writing in any other programming language except that until recently there were fewer tools. Since 2000, the number of tools available for JavaScript developers has exploded, making it much easier to locate problems, optimize, and deploy JavaScript-based solutions. Some of the tools are designed to be used from JavaScript whereas others can be run outside the browser. This appendix provides and overview of some of these tools, as well as additional resources for more information.
Purchase Before purchasing this product, please be sure you have met all software and system requirements, and that you understand any limits placed upon its use.
Return Policy Wrox Chapters on Demand are non-returnable and non-refundable.
Watermarking Wrox Chapters on Demand are sold with a small unique watermark at the bottom of each page identifying the purchaser name, email address, and order number.
Reader Software Wrox Chapters on Demand are offered as PDFs, and they can be viewed using the Adobe Reader, ADE, or a compatible PDF reader. If you do not have the Reader installed, it can be downloaded for free at Adobe.com.
Test Download As Wrox Chapters on Demand purchases are non-returnable, it is advisable that you test your system and software configurations with a free sample download before you place an order.
Usage Rights for a Wrox Chapters on Demand File Any Wrox Chapters on Demand product you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:
If you have any questions about these restrictions or need any further assistance please refer to Technical Support (www.wiley.com/techsupport) or call (877) 762-2974 (8 a.m. - 5 p.m. EST, Monday - Friday).
Related Books