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

Chapter 5

[SpanishInquisition]

23 ways to annoy people with pop-up ads.

Use Addall instead...

[MajorBurrito]

Instead of paying too much to Barnes and Noble, you can get it from AddAll for quite a bit cheaper.

Install Mozilla

[brunes69]

Edit -> Preferences -> Advanced -> Scripts and Plugins -> Open Unrequested Windows. Uncheck. Done.

Problem solved.

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.

[Pfhreakaz0id]

agreed. We get guys on my project who immediately want to go to a server side solution on everything (oh, let's do a round-trip to the server every time they pick a new selection! That won't be annoying or anything!). When I suggest we use client-side they say "oh that's too hard". Then I whip up the script and they are amazed. I'd rather write Javascript then a SQL procedure any day of the week!

Re:Strengths of Javascript.

[Mirk]

I agree 100%. We should do more on the client side.

Wait a minute ... why doesn't your site work in my browser?

What's that you say? My site doesn't work in your browser either?

How very strange.

Moderation totals: +1 funny, -1 gratuitously sarcastic.

Re:Strengths of Javascript.

[Ravagin]

I certainly do not agree with you. Web development is principly about information architecture - the HTML. That's what really, really matters. Then you can get fancy with CSS and graphics - and javscript for the really fancy or for complex applications. But like mitchener said , JS is too often used merely for flashy effects, and while those can be cool, they are in no way important to an effective website. Javascript has its place and uses - one can make some great interfaces with it if one needs to - but I don't think it's nearly as important as you say it is.

Cheers,

Re:Strengths of Javascript.

[Captain Large Face]

The only problem with JavaScript is as you cite:

... when most people hear the word JavaScript they immediately think of how annoying window.open() is.

I've enjoyed using JavaScript for almost as long as I've been using HTML (4/5 years), and believe it can genuinely help to reduce server load (think of all those validation scripts), yet JavaScript is steadily becoming less applicable due to the ability to disable it in the client.

A lot of ordinary web users, in an effort to block pop-ups, have disabled JavaScript in their browsers, and all other applications which could easily make use of this technology suffer as a result. Personally, I couldn't blame them for this, as I find pop-ups as irritating as the next person.

Until ordinary web-users come to trust web sites not to thrust adverts down their throats using pop-ups, pop-unders or whatever, then this valuable technology will remain unusable on the vast proportion of (mainstream) web sites.

Of course, the odds of marketing-types not pressing developers to use any technology in an immoral way are extremely remote.

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.

my opinion (3rd edition)

[larry bagina]

I own the third edition of this book, and bought it when I was starting to write a web-based decision support system for a very large beverage company. I can safely say that this book, and the HTML Definitive Guide (also by O'Reilly) were critical to the success of the system.

I have seldom had a question about JavaScript for which I could not find the answer in this book. I referred to it so frequently during the development of our system that it is now the most dog-eared book in my collection. I'm going to order the fourth edition simply because this baby is ready for retirement.

If you are learning client-side JavaScript, by all means purchase this book. The first half of the book is a guided introduction to the language and does a wonderful job of explaining the syntax of the language, the underlying object model, and virtually every pertinent feature of the language. The real value, though, is in the reference, which documents every object, method, property and event of standard JavaScript.

Non-conformists who wish to exploit features unique to Internet Explorer will find some reference material here, but the book does try to focus on the "standard" features of the language, which I think is a good thing.

You just can't go wrong with this book.

Re:if you use JavaScript, you're a tool

[cmdr_beeftaco]

I have mastered HTML and I wish to learn javascript. Once I learn some tricks in javascript will be well on my way to becoming a highly paid software engineer. All you Engineers make this stuff sound hard but all you need to remember is begin tag, end tag, unless you are using a p tag.

<strong><i>mad skillz</i></strong>

Re:Javascript not dead

[Pfhreakaz0id]

Dead? Heck no... Even most IE-only Intranet projects (like the one I work on) use Javascript as the client-side scripting lagnuage. Why? Almost ALL example code/books on client-side scripting are in Javascript. Heck, it's even the default in MS Visual Interdev (select "insert client side script" and you get a Javascript block).

Plus, I know an increasingly large number of ASP developers who use Jscript (microsoft's Javascript, they just can't use the name) as the scripting language for the Server-Side ASP code (rather than the VBScript mose use). Why? It just makes more sense. It's annoying to "switch mental gears" when going from the client-side code blocks in Javascript and the server-side VBScript blocks. Also, many are in the boat we're in where we do some Java stuff as well. Syntax is fairly consistent between Java and JavaScript.

Great book..

[Pfhreakaz0id]

but it has been out a while. I have an old second edition that is heavily thumbed. I recently inquired and for those that don't know, O'Reily has an upgrade program where for a small fee (I think it was $10 plus shipping, but don't quote me.) you get an upgraded edition. sweet. Look on their website for info.

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?

Alternate titles

[eyepeepackets]

1. How to Annoy Anyone on the Planet in 3 seconds (Or less!)
2. Breeding Cookies for Fun and Profit
3. Learn Browser Crashing in 21 Days
4. Fantasy Pretend Programming for Beginners
5. Make Everyone Hate the Web in Five Easy Steps

Oy, I'm getting to be so cynical in my old age.

Note to the humor impared: This is a joke. Don't take it seriously because this is a joke. Don't be offended and flame me because this is a joke. Don't get all huffy and defend java and java script to your last dying finger twitch because this is a joke.
Here it is, the definitive statement on this post: THIS IS A JOKE!

Good thing for Mozilla

[colmore]

I like seeing non-IE browsers getting coverage in the mainstream technical press. IE has something like a 95% market share, and many people use this to justify making websites that only work in IE. If *I* were running a web business then that statistic would tell me:

"Hey, 1 out of 20 of our potential customers can't use our website!"

And I think that IT should be pitching that same line to the suits.

Anyway, until someone develops intellegent JS filtering that works, I just turn it off.

Can you give some examples?

[avdi]

I can't think of an O'Reilly book I own which isn't excellent. True, some of them are old classics like "UNIX Power Tools", and "Managing Projects with make". But their most recent books have been just as exemplary - the latest edition of the Camel book simply improves on the earlier editions. The "CVS Pocket Reference" is exactly what I needed for day-to-day CVS work. The latest edition of "Web Designer in a Nutshell" has a permanent spot on my desk now that I have a website.

So - what titles would you warn against?

Re:Can you give some examples?

[bunratty]

The editing of O'Reilly books has for some reason suffered over the past few years. The most obvious symptom is that O'Reilly used to correct mistakes with nearly every new printing, about twice a year for an average O'Reilly book. However, now I cannot find a single O'Reilly title that has corrected printings for the last year. For example, compare the printings of JS: TNG3 (10 reprints in 3 years) vs. JS: TNG3 (0 reprints in 9 months). Another example is HTML: The Definitive Guide, 3rd edition (4 reprints in 2 years) vs. HTML: The Definitive Guide, 4th edition (2 reprints in 2 years). Can you find a corrected reprint that has happened within the past year?

Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!

It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.

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

Learn the tricks the Pros use

[Waffle Iron]

You too can learn to replace any simple, small table of hyperlinks with an annoying pseudo-GUI menubar that takes 5 minutes of mousing to see the possible options, and doesn't even work 20% of the time.

Once you've mastered that, you can go on to advanced topics like a "browser detection script", that refuses to show users any of the website unless they happen to have the same version of IE that you are using right now!

The best type of technology is not a means to an end, it is an end in itself. Javascript is one of them.

Re:Compatibility Question

[kubrick]

Speaking as a web developer here -- it usually means that they've special-cased their code for IE and NS4 and the scripts they've written break on any browser which doesn't identify itself as one of those (especially as the netscape 4 test involves something to do with layers). Decent web developers write to the spec, and then and only then put in fixes for broken browsers that they know of.

Mozilla doesn't support a few DOM access methods that IE does, because they're not in the W3 specs... they use alternative methods that IE also supports, but this leads some people to say that Mozilla's scripting support is 'broken'.

(Tangentially, I was reading on Bugzilla about some performance problems with Mozilla's JavaScript & DHTML, but that was more speed-related than functionality-related, I think.)