Mini review of “JavaScript: The Definitive Guide, 5th Edition”

Dietrich Kappe, Thursday, August 31, 2006 @ 10:53 am

The latest edition of the venerable tome JavaScript: The Definitive Guide is a sorely needed update. I guess it took Ajax, Web 2.0, and an intervening five years to revive interest in in this quirky client-side language. The fourth edition, while still providing a good formal specification of the language, had fallen woefully out of date both with some of the new features introduced in the browser versions and in terms of practical examples of how JavaScript is being used to enable Ajax and Web 2.0 applications.

I don't mean to give a full review of a thousand plus page book here. Rather, I just want to focus on the chapter that covers client-side persistence. In the fourth edition, the corresponding chapter only discussed "cookie scripting." While this chapter does talk about cookies, it delves into a number of other options for persisting data on the client.

Unfortunately, for a book that describes itself as the "definitive guide", it only discusses three options for persistence: cookies, IE userData persistence and Flash SharedObjects. This coverage is far from definitive. In fact, Brad Neuberg in his discussion of dojo.storage enumerates seven different client-side storage mechanisms:

1. Cookie Storage Provider - uses cookies to persist the hash table
2. Flash Storage Provider - uses Flash's SharedObjects to persist data
3. ActiveX Storage Provider - uses COM's File APIs to persist data
4. XPCOM Storage Provider - uses XPCOM's File APIs to persist data
5. Form Storage Provider - uses the text autosave features of a hidden form to save transient data (the Really Simple History library uses this trick)
6. WHAT WG Storage Provider - uses native browser persistence to store data, as defined by the WHAT Working Group.
7. IE Storage Provider - uses IE's proprietary abilities to store up to 60K of data.

Maybe this is just a sign that the use of JavaScript has grown so far beyond what was common or even thinkable in 2001 that it is simply isn't possible to write a definitive guide, at least not in a thousand pages. Would you buy a book called "Java: The Definitive Guide?" Probably not.

What is there -- the discussion of Flash SharedObjectsand IE userData persistence -- is pretty brief in comparison to the exhaustive treatment of cookie persistence. It does give you a basic description and enough code samples to get you started, but a cookbook it is not. The section on persistence alternatives has the feeling of an afterthought -- something shoehorned into the book relatively late to address Ajax and Web 2.0. In fact, many parts of the client-side portion of the book have that feel.

I think the book is still worth buying as a language reference, if only for its treatment of closures and object creation, but for now you'll have to look online for more detailed, exhaustive, and "definitive" treatment of many topics.

Technorati : ajax, book review, javascript

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Thanks for the review of my book!

   I think it is unfair to expect this book to cover every possible persistence solution, however!

   I cover 3 of the 7 you list. Of the remaining four, one (forms) isn’t really persistence, since it doesn’t work across browser sessions. Another (COM) is redundant with IE’s userData mechanism. Another (XPCOM) is not (or should not be: it is not one I’m familar with) available to untrusted code. And the final one (the WHAT-WG API) is not yet widely enough implemented to be worth documenting. When it has been adopted, this will be an important API and I will cover it.

   You are correct that my coverage of client-side persistance is not a cookbook: that is not the goal of this book. And you are also correct that the coverage of flash-based and userData-based persistence are kind of tacked on to the discussion of cookies. Cookies are universal, and are sufficient for most application’s persistence needs. None of the alternatives are standard or robust enough to be worth spending much time on in this book. Again, the WHATWG API may well change that, and I expect it will receive heavy coverage in the next edition of the book.

   Comment by David Flanagan, Thursday, August 31, 2006 @ 1:49 pm

Leave a comment