ppk on JavaScript, 1/e

Book positioning
When I started writing the book I had a pretty good idea where I wanted it to fit into the JavaScript book market. Basically I wanted it to be exactly mid-way between Jeremy Keith's book and David Flanagan's, to sort of bridge the gap between non-programming web designers and hard-core programmers.

Jeremy Keith's DOM Scripting: Web Design with JavaScript and the Document Object Model is aimed at web designers who are fluent in HTML, CSS, and design, but for one reason or another have never made the step to programming JavaScript. Because of this target audience, it explains everything simply and doesn't go into too much technical detail when that's not necessary.

David Flanagan's JavaScript, the Definitive Guide (note: 5th edition now available), on the other hand, is aimed at experienced programmers who come from another language and now have to understand JavaScript. For this reason it is complete: it treats even those aspects of the language that are rarely used in web development.

Both books are exactly what they need to be. Nonetheless, I had the feeling that there is a market for a book that's somewhere in between: a book that explains more of the technical details than Keith's does, but not quite as much as Flanagan's does.

Unfortunately I didn't entirely succeed. Especially during the last round of frantic editing I removed quite a few advanced (hence technically dense) subjects and concentrated on the simpler stuff every JavaScripter needs to know. All in all I abandoned my exact mid-position and moved a few steps away from David Flanagan, towards Jeremy Keith.

Therefore right now the best way to describe my book is as the sequel to Jeremy's. Once you really understand all that he explains, the time has come to immerse yourself in the more advanced features and problems of the language, as well as some nasty browser incompatibilities that can ruin your day (and your hair).

The content
The book page contains the table of contents, and as soon as you gloss over it you'll notice that it differs somewhat from a traditional JavaScript book ToC. The first really technical chapter is chapter 5; the first four treat several non-technical (or less-technical) aspects of JavaScript: its purpose (why use it at all), its context (web standards and accessibility), the browsers and how to herd them, and the preparation phase in which you take fundamental decisions about how your script is going to cooperate with the HTML structural layer.

Only when these theoretical subjects are out of the way, the practical, technical part starts. I divided this part into six chapters, each of which treat one specific subject: Core, BOM, Events, DOM, CSS modification, and data retrieval. This subdivision has been in the making for years and years; when I created my 2001 book proposal (that never came to anything), I was already convinced that many JavaScript books mix up their topics too much. Although I didn't find a solution back then, while writing the 2005 proposal (that has become this book) the simple six-fold subdivision sort of popped into my head.

In fact, ordering your material is one of the most difficult problems of writing a JavaScript book. When you create even the simplest example script, you use Core, Events and DOM at the least; Core because you're writing a program, Events because you wait for the user to do something, and DOM because you need to create some sort of visual feedback.

Does that mean that you should treat these three vastly different topics in the course of one chapter? On the pro side, in order to explain the script well you should explain Core, Events and DOM, because your readers need that knowledge. On the con side, if you keep doing that the book will quickly become a confused jumble of topics and subjects, where Events basics are explained in one chapter, a few more basics in another, and some advanced topics in yet another.

My solution is to strictly separate all these subjects, and to make every chapter treat all the important aspects of its topic. However, to be able to do so I had to do some serious thinking on the example scripts themselves. As I said, even the tiniest example script uses Core, Events, and DOM. How can the reader understand the entire script when the chapter he's reading only explains the Core features, but not Events and DOM?

The short answer is: he can't. However, the level of incomprehension really depends on how you use the example scripts. It was only when I came up with a new idea for using example scripts in a JavaScript book that the strict subdivision by subject began to make sense. I'll explain this idea in a next entry.