Nicholas C. Zakas [Nicholas C. Zakas] - Professional: JavaScript® for Web Developers, Third Edition

ABOUT THE AUTHOR

NICHOLAS C. ZAKAS has been working with the web for over a decade. During that time, he has worked both on corporate intranet applications used by some of the largest companies in the world and on large-scale consumer websites such as My Yahoo! and the Yahoo! homepage. As a presentation architect at Yahoo!, Nicholas guided front-end development and standards for some of the most-visited websites in the world. Nicholas is an established speaker and regularly gives talks at companies, conferences, and meetups regarding front-end best practices and new technology. He has authored several books, including Professional Ajax and High Performance JavaScript , and writes regularly on his blog at http://www.nczonline.net/ . Nicholass Twitter handle is @slicknet.

ABOUT THE TECHNICAL EDITOR

JOHN PELOQUIN is a front-end engineer with over ten years of JavaScript experience ranging across applications of all sizes. John earned his B.A. in mathematics from the University of California at Berkeley and is currently a lead developer for a health care startup where he makes use of the latest in front-end technologies. Prior to editing this volume, John edited JavaScript 24-Hour Trainer by Jeremy McPeak (Wiley, 2010). When he is not coding or collecting errata, John is often found engaged in mathematics, philosophy, or juggling.

ACKNOWLEDGMENTS

EVEN THOUGH THE AUTHORS NAME is the one that graces the cover of a book, no book is the result of one persons efforts, and Id like to thank a few of the people involved in this one.

First and foremost, thanks to John Wiley & Sons for continuing to give me opportunities to write. They were the only people willing to take a risk on an unknown author for the first edition of Professional JavaScript for Web Developers , and for that I will be forever grateful.

Thanks to the staff of John Wiley & Sons, specifically Kevin Kent and John Peloquin, who both did an excellent job keeping me honest and dealing with my frequent changes to the book as I was writing.

Id also like to thank everyone who provided feedback on draft chapters of the book: Rob Friesel, Sergey Ilinsky, Dan Kielp, Peter-Paul Koch, Jeremy McPeak, Alex Petrescu, Dmitry Soshnikov, and Juriy Kangax Zaytsev. Your feedback made this book something that Im extremely proud of.

A special thanks to Brendan Eich for his corrections to the history of JavaScript included in Chapter 1.

Last, but certainly not least, thanks to Rey Bango for writing the foreword of this book. I had the pleasure of meeting Rey for the first time in 2010 after conversing online for several years. Hes one of the truly nice guys in the industry, and Im honored that he agreed to lend his time to this book.

A

ECMAScript Harmony

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 Netscapes JavaScript 2.0 and the other for Microsofts 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.

ECMAScript 3.1 was ultimately renamed to ECMAScript 5 and standardized fairly quickly. The details of ECMAScript 5 have been covered throughout this book. As soon as ECMAScript 5 was finalized, work immediately began on Harmony. Harmony tries to keep to the spirit of ECMAScript 5, in making more incremental changes rather than radical language changes. While the details of Harmony, aka ECMAScript 6, are still developing as of 2011, there are several parts of the specification that have been finished. This appendix covers the parts of Harmony that will definitely make it into the final specification, though, keep in mind that the details of the final implementations may change from whats presented here.

GENERAL CHANGES

Harmony introduces several basic changes to ECMAScript. These arent major changes for the language but rather the closing of some of the curiously open gaps in functionality.

Constants

One of the glaring weaknesses of JavaScript is its lack of formal constants. To rectify this, developers added constants as part of Harmony via the const keyword. Used in a manner similar to var , the const declaration lets you define a variable whose value cannot be changed once initialized. Here is the usage:

Constants may be defined anywhere a variable can be defined. Constant names cannot be the same as variable or function names declared in the same scope, so the following causes an error:

Aside from having immutable values, constants can be used just like any other variable. Any attempt to change the value is simply ignored, as shown here:

Constants are supported in Firefox, Safari 3+, Opera 9+, and Chrome. In Safari and Opera, const acts just like var in that values can still be changed.

Block-Level and Other Scopes

One of the constant reminders throughout this book has been that JavaScript has no concept of block-level scope. This means that variables defined inside statement blocks act as if they were defined in the containing function. Harmony introduces the concept of block-level scoping through the introduction of the let keyword.

Similarly to const and var , a let declaration can be used at any point to define a variable and initialize its value. The difference is that the variable defined with let will disappear once execution has moved outside the block in which it was defined. For example, its quite common to use the following construct:

When the variable i is declared in this code, it is declared as local to the function in which the code resides. This means that the variable is still accessible after the for loop has finished executing. If let were used instead of var , the variable i would not exist after the loop completed. Consider the following:

If this code were to be executed, the last line would cause an error since the definition of i is removed as soon as the for loop completes. The result is an error, because you cannot perform any operations on an undeclared variable.

There are other ways to use let as well. You can create a let statement that specifically defines variables that should be used only with the next block of code, as in this example:

In this code, the let statement defines an area within which the num variable is equal to 10 and the multiplier variable is equal to 2. This definition of num overrides the previously declared value using var , so within the let statement the result of multiplying by the multiplier is 20. Outside the let statement, the value of num remains 5. Since each let statement creates its own scope, the variable values inside it have no bearing on the values outside.