JavaScript : The Definitive Guide, 4th Edition

briandonovan writes "A new edition? Given all of the changes in the web programming landscape since the 1998 publication of the previous edition, David Flanagan's JavaScript : The Definitive Guide (JS:TDG4), 4th Edition was overdue. Flanagan delivers a book that more than measures up to its predecessor - JS:TDG4 includes a substantial amount of new material and, as a whole, has been extensively updated. The crushing gain in browser market share by Microsoft's Internet Explorer offering, the maturation of the Netscape 6.x,7.x / Mozilla browser suite and its entry into the fray along with a slew of other Gecko-based browsers, promulgation of newer versions of the ECMAScript specification (accompanied by new implementations in JavaScript and JScript), and the publication of successive W3C DOM Recommendations are all reflected in this edition." JavaScript : The Definitive Guide, 4th Edition author David Flanagan pages 916 publisher O'Reilly rating 9 reviewer Brian Donovan ISBN 0596000480 summary The latest edition of JavaScript : The Definitive Guide brings the popular reference up to date with extensive coverage of W3C DOM Level 1 and 2 and a much-improved and expanded set of appendices.

The Book in a Nutshell

Although much of the core of the language, addressed in Part I, has changed relatively little since JS:TDG3, Flanagan has added coverage of new issues that have emerged in the past several years, like the discussion of ASCII, Latin-1, and 16-bit Unicode in the beginning of Chapter 2 (ECMA-262 Edition 1, the spec that defined ECMAScript, included Unicode support for il8n purposes, so ECMAScript compliance requires Unicode support), and pruned away quite a bit of material related to NS 4.x-proprietary features, like the explanation of import and export (previously found in Chapter 6), that are naturally of increasingly less interest to developers as that line of browsers recedes into history. Much of Part II, which considers client-side JavaScript and DOM in all its glory, is entirely new or has been completely re-written. Where the chapter on the Document Object model in the 3rd edition only covered the "Level 0" DOM (the objects, properties, and methods first exposed by the 4.0 browsers), JS:TDG4 tackles the Level 0 DOM and the W3C DOM Recommendations through level 1 Core and HTML and touches on some DOM Level 2 topics, including the Range and Traversal APIs. "Cascading Style Sheets and Dynamic HTML" and "Events and Event Handling" are two other chapters in the Client-Side JavaScript section that have really come into their own in this edition.

The large (more than 300 pages), but somewhat muddled "JavaScript Reference" in the 3rd edition (it had commingled the objects, properties, and methods included in the core of the JavaScript language with those of the Level 0 DOM) has been split into 4 discrete appendices ("Core JavaScript Reference", "Client-Side JavaScript Reference", "W3C DOM Reference", and "Class, Property, Method, and Event Handler Index") that, taken together, comprise more than 400 more pages of information. NS 4.x fans can take comfort from the fact that, while much NS 4.x-specific information has been culled from the body of the text, Netscape 4.x still shows up in some screen captures (along with Microsoft Internet Explorer and Netscape 6).

What was Great

Exception handling (using throw and try/catch/finally) is covered in greater detail. In Chapter 15, "Forms and Form Elements", JavaScript interactions with buttons, toggle buttons (checkbox and radio elements), text fields, hidden elements, and fieldset elements are addressed individually in new sections not present in the corresponding chapter in JS:TDG3 and the section on select and option elements goes into more detail than in the previous edition. Throughout the book, improvements have been made to figures and tables - like the addition of the "Supported by" column in Table 19-1 : "Event handlers and the HTML elements that support them", which now helpfully lists the elements for which the event handlers can be triggered after identifiers for the versions of Netscape and Internet Explorer in which the behavior is observed. Finally, the book as a whole is significantly more readable. The type used for the text of the code examples and tables was too "light" in the 3rd edition (at least in my copy), and I was glad to see that it's a bit heavier in the 4th.

What was Not so Great

I nearly came up empty-handed in my search for defects in this book, but noticed that, in tables 11-1 and 11-3, "Automatic data type conversions" and "Data type manipulation in JavaScript" respectively, information relating to the treatment of arrays and functions present in the corresponding tables in the 3rd edition has been removed. That's really my only gripe. Some might wish that Flanagan had included more compatibility information, but, realistically, the task of fully documenting the intricacies of what's supported by which browser (or, in the case of Win MSIE, which JScript dll is installed) could probably fill a separate book all of its own. Moreover, Chapter 20 ("Compatibility Techniques"), may be brief at only 11 pages, but it does a good job of tackling best practices in dealing with JavaScript and DOM cross-browser compatibility challenges.

To Buy or Not to Buy

If you're in the market for a good JavaScript (or JavaScript+DOM) book, then JavaScript : The Definitive Guide should undoubtedly be your first choice. Although my 3rd edition was so tattered from long use that I really had no choice but to upgrade, even owners of the 3rd edition who've managed to keep their copies in near-mint condition will probably still want to get their hands on the 4th edition if they haven't already done so - for the meatier and updated reference appendices if for no other reason.

Table of Contents

Preface

• Chapter 1. Introduction to JavaScript

Part I : Core JavaScript

• Chapter 2. Lexical Structure
• Chapter 3. Data Types and Values
• Chapter 4. Variables
• Chapter 5. Expressions and Operators
• Chapter 6. Statements
• Chapter 7. Functions
• Chapter 8. Objects
• Chapter 9. Arrays
• Chapter 10. Pattern Matching with Regular Expressions
• Chapter 11. Further Topics in JavaScript

Part II : Client-Side JavaScript

• Chapter 12. JavaScript in Web Browsers
• Chapter 13. Windows and Frames
• Chapter 14. The Document Object
• Chapter 15. Forms and Form Elements
• Chapter 16. Scripting Cookies
• Chapter 17. The Document Object Model
• Chapter 18. Cascading Style Sheets and Dynamic HTML
• Chapter 19. Events and Event Handling
• Chapter 20. Compatibility Techniques
• Chapter 21. JavaScript Security
• Chapter 22. Using Java with JavaScript

Part III : Core JavaScript Reference

Part IV : Client-Side JavaScript Reference

Part V : W3C DOM Reference

Part VI : Class, Property, Method, and Event Handler Index

Index

You can purchase JavaScript: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Strengths of Javascript.

[taeric]

I own a copy of this book and have thus far fully appreciated having it.

Unfortunately, when most people hear the word JavaScript they immediately think of how annoying window.open() is. It is a shame, really, as a lot of interesting things can be done using JavaScript. Especially when combined with the DOM and all the options that opens up.

My question, then, is simple. How many people have noticed that true knowledge in JavaScript is severely lacking in many people who do web developement? I've met lots of people who claim to know JavaScript well, but they can barely write the examples provided in most books. I think that for a web developer, knowledge in client side scripting should be moved up on the priority notches. Am I alone in this?

Re:Strengths of Javascript.

[mitchner]

You might not be alone, but I don't agree. Certainly Javascript can do some cool stuff, but you can't count on it working for all your users. Do your processing on the server and you don't have this worry. I use Javascript if I'm doing Intranet development where I don't have to worry (as much) about people disabling JS, and I know every user is on the same broswer and version, but I stay away from it for Internet development. Also, people interested in creating eye-candy use flash instead of JS. So it's in a no-mans land where creative folks don't like it much, and most developers would rather use server-side processing anyway.

Re:Strengths of Javascript.

[sporty]

Until someone breaks your site because htey have that one particular javascript setting off.

Seriously. I dont' go to some sites because it requires a seperate window to open automagically, while I have that setting in mozilla off. It's not a matter of protest -- it's a matter of preference. I don't like it, and got annoyed turning it back on for the site in general. So.. I've stopped going there.

The bigger problem, is it is hard to worry about it client side. If I turn off JS, bam, your site becomes broken. Depending on the use of JS, it can either be a security issue, to db integrety (data validation) to site navigation that becomes broken.

Re:Strengths of Javascript.

[Doomdark]

I agree. Many of my co-workers who do claim they know Javascript say they never create new Javascript code, just cut'n paste. What is weird is that it would be fairly easy to actually learn the basics, and that usually programmers are not all that proud about "not knowing how to do XXX but being able to copy stuff others have done". At least not the more ambitious ones. I actully spent just one week reading a JS book and trying out things. Since then I have written couple of tree components (for browsing files on server) and a simple spreadsheet-like web app, mostly for fun. Neither is rocket science once you know the basics. Plus, knowing basics it's also much easier to write JS code that is portable and doesn't really on features (or defects) of any single browser.

Also, most people don't seem to realize that question between server/client side validation (or functionality) is not all-or-nothing. They are pretty much complementary. Client-side is really good at making web apps much more responsive and interactive. Server-side is a must for secure stuff; anything on client-side can be manipulated at will.

For example, I do think that it's much better do (parts of) simple syntax / completeness validation on client-side. Instead of having to wait for server to output "You didn't fill 'foo'" page, you could get an alert dialog telling you the same, and:

• Server-side load would be reduced, not so much because of having to do check but only because of the need to output complete replica of original page with filled-in values. For individual user load is not huge, but for big sites this does add up.
• Response time would be decimated (ie. validation is immediate, no round-trip to potentially congested server)

More complicated checks should be done on server-side (not all data may even be available at client), but for (pre-)validation JS makes things much easier.

No joking, Javascript is evil.

[SpanishInquisition]

The language I mean, not what it can do. It was hacked together by Netscape to somewhat resemble C++ but with the feature set of GWBASIC, so you really get the worst of two world.

Variables can be declared or not, line termination is optional, it's supposed to be object-oriented but there's no way to decalare class or methods, some construct are really horrible:

value =selectBox[selectdBox.selectedIndex].value

Scripting language for HTML should be easy,simple and have the right features (who needs the C++ binary operators anyway >>, Any project going to implement different scripting language for mozilla?

Forget popups

[thelexx]

It's really obvious that the people posting derisive comments about Javascript have never had to develop a site that actually does anything useful. Try creating some pages that accept a credit application without using Javascript (and MS-only shit need not apply). If/when you even get basic DOB validation done, show it to us.

LEXX

Re:Good thing for Mozilla

[altgrr]

In order to ensure that the web pages my browser receives are entirely standards-compliant, I use WebWasher and set the browser tag to "Don'tYouSnoopMyBrowserTag-Bitch!" - of course, that's neither IE nor Netscape/Mozilla. It weeds out all the evil sites that chuck code in that they think specific browsers can handle, and it means that I don't have to view sites where they say "Ah - your browser's too old".

There's nothing wrong with building features in, as long as they're supplementary to the browsing experience - anything critical to browsing must be done in HTML. IMHO window.open() should be categorically banned from all browsers - there is no need for popups to open on page load or close, and, if a page needs to be opened in a new window, you can always use <A HREF="whatever" TARGET="_new"> - of course, if the browser doesn't support the TARGET attribute, you get to view the page anyway, just in the same window.

Re:Compatibility Question

[aWalrus]

IE keeps on supporting things they did that weren't int the spec (since ie 4) like document.all for referencing elements. Mozilla doesn't (actually, that is a good way to sniff browsers, by detecting the referencing and functions they support). Both ie5+ and mozilla support most of the DOM well (document.getElementById() being the most standardized of the functions defined in the DOM).

I find Mozilla's javascript implementation to be better than explorer's actually. The behavior is more consistent and well defined. The event bubbling (which most developers won't use consciously) is fully up to spec, whereas ie support is still a bit flaky in some of those things.

Personally I prefer Mozilla, but it is more a matter of good png support, tabbed browsing and other features ie is still behind on. Also, I HATE the new (as of ie 6 I think) image management "features" in Internet Explorer (the annoying toolbar that shows up when you mouse over images, and automatically resizes jpegs to fit the screen) yes, it can be turned off, but it annoys the hell out of me when the browser modifies in any non standard way the look of a page without asking.
--