I’m working on a JavaScript book these days, titled Modern JavaScript: Develop and Design, to be published by Peachpit Press around the end of the year/beginning of 2012. In all modesty, readers have been asking that I write a JavaScript book for a decade now, as there seems to be a lack of good JavaScript books out there (a JavaScript book recommendation is another common request). I believe I’ve read three JavaScript books in the 12 years since I first started using the language:
- JavaScript: The Definitive Guide, by David Flanagan (O’Reilly)
- JavaScript: The Good Parts, by Doug Crockford (O’Reilly)
- Pro JavaScript Techniques, by John Resig (Apress)
These are all recommendable books, with their own strengths and weaknesses (I always think of O’Reilly books being technically thorough and excellent, but not great to learn from for beginners.) In skimming some other JavaScript books, not to be named, and working on my own, I’ve been thinking more analytically about why there aren’t more good JavaScript books out there. I’ve come up with two reasons.How JavaScript Used to be Used
When JavaScript first started to be used, what was expected of Web pages was thoroughly different than today. The “World Wide Web” was quite new, and people were just starting to get online. As with most new technologies, the emphasis was on cool over useful. JavaScript, and HTML, were used to demonstrate what could be done, more than what should be done. With HTML, this meant things like the hideous blink tag (if you never saw a blink tag in use, consider yourself lucky). With JavaScript, this meant embedding sounds (ugh!), status bar tickers, popup windows, alerts, changing the cursor, and so forth. At best, JavaScript was used for image manipulation (e.g., rollovers) and minor form validation. Books written at the time, therefore, focused on these things. In other words, by comparison, if everyone wants to use paper shredders to make confetti, books about shredders will show how to make confetti!
Besides how JavaScript was used, there was the issue of who used it. Being a client-side language, JavaScript was primarily the domain of client-side developers: graphic design people, generally without formal programming training, ability, or even interest. With that intended audience, JavaScript books written at the time focused more on how to use JavaScript for specific applications, not how to learn JavaScript as a programming language in its own right. Which, you know, it is. Recipe books are fine, of course, but aren’t effective as a way to learn a language outright.
Also, JavaScript is a comparatively easy language to use, albeit not an easy language to use with absolute reliability. Because of this quality, there may have been less incentive to write books that fundamentally teach the language, as opposed to just showing people how to do the little tricks they think they want to do.
I never wrote a JavaScript book in the time period I’m talking about (the first time I formally wrote about JavaScript was in 2003), but my theory is that how JavaScript was used when most books were first being written is partially responsible for the lack of quality titles. This is a theory. Over time, as these writers did new editions, perhaps they didn’t do such a good job of updating the book to reflect how JavaScript usage has changed. It’s hard to make big changes to a book’s organization in subsequent editions, but, on the other hand, that is part of the job of being a writer. As an example, I was just looking at the fifth or sixth edition of a JavaScript book and noticed that it still has separate chapters on image manipulation (i.e., rollovers and such), cookies, and frames, but only one chapter on Ajax. This isn’t reflective of today’s JavaScript. I’m not saying that JavaScript isn’t still used in these ways, but writing a book is largely about making decisions and prioritizing. Spending one-fifth or one-sixth of a book on these subjects means more important content is being shorted.
What One Needs to Know
The second problem I’ve identified is what one needs to know to use JavaScript. This is still a problem today, one I wrestled with in writing my book. Take a relatively simple and common use of modern JavaScript: form validation. In order to perform form validation in JavaScript, one has to know about:
- Browser events and event handlers
- Writing functions
- Grabbing form element values
- Validating data by type
- DOM manipulation
That’s a lot of information, and some of it (specifically involving events) is browser specific. To highlight why this is a problem as a writer, let’s look at how one can write a PHP book:
- This is an HTML page.
- Viola! This is now a PHP page (i.e., file extension and PHP tags).
- Here’s how to print something using PHP.
- Here’s how to create a variable.
- And so forth.
A book on PHP can be written in a linear way because how the language works allows for that. But that’s not possible with a JavaScript book. In fact, in my book, event handling is Chapter 8, writing functions is Chapter 7, form interactions is Chapter 10, and DOM manipulation is part of Chapter 9. But the reader has to be able to do something well before he or she gets to Chapter 10, so what’s the solution?
One option is to encourage use of a browser console to execute bits of JavaScript. I do this in the book, but that’s not an approach that gets relied upon as a teaching tool, as it’s really not how you’ll use JavaScript in the real world. Chapter 3, which is the last chapter before getting into the heart of the language, explains how to use a console to execute a single line or several lines of code, and later chapters use that interface to demonstrate concepts, but the book never relies on that route for you to practice new ideas. The actual JavaScript programming you do won’t be in a console interface.
The other solution I came up with is clearly a cheat, but sometimes one has to cheat. In Chapter 2, I demonstrate and discuss the bare minimum of things:
- Two events: onload and onsubmit
- Creating a simple function
- How to reference a form element
This is enough essential information in order to create forms the user can interact with, and have JavaScript do some teachable and demonstrable stuff in response. Plus, I justify the early introduction with the thinking that: A) most readers have probably dabbled a bit with JavaScript before picking up the book anyway, and, B) it provides a target to work towards.
By comparison, in some of the other books I’ve browsed through, prompt() is used to get input from the user and document.write is used to output results. I don’t know if this is legacy code or the writer’s way of addressing this complication, but it’s bad code, bad JavaScript. One never uses prompt() anymore and almost never uses document.write. It’s stunning, really. In many books, lots of information is conveyed partially using code one would never use. And these are books published within the last year or two.
I have a lot of sympathy for my fellow writers, as writing a book is hard, and JavaScript poses its own particular complications. But hopefully the choices I’m making will result in a good book that does a lovely little language the justice it deserves, and so rarely gets.
