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.
ppk on JavaScript, 1/e
《ppk谈JavaScript》热门书评
-
这本书是学习js的开始,而不是结束
25有用 0无用 Charles Tang 2008-12-26
我不是一个专业的Web开发人员,那只是我的兴趣爱好,我是一个blogger,热衷于定制自己的Blog,javascript在这过程中终究不能避免,于是就这么上手了。早期,我在Blogger上移植过别人写的Calendar,Music Player,那个时候,正是javascript刀耕火种的时候,那...
-
很好的书
8有用 1无用 mikeyao 2006-07-12
作者ppk是这个领域里的高手,在他的个人网站有非常好的JavaScript的教程。在各大国外的web开发网站上都有的他的文章。David Flanagan的"JavaScript, the Definitive Guide"第五版的英文版已经出版,其中17-19章是他所写。足以表...
-
《PPK谈JS》书评
5有用 0无用 豆豆家の哲爸爸 2008-11-13
PPK 在JavaScript界鼎鼎大名,他的《ppk 谈 JavaScript》这本书口碑极佳。在译书还未上市前我先看了 Realazy的blog:《ppk on JavaScript 笔记》,所以对该书有了大概的了解,知道这是本什么内容的书,适合什么水平层次的人来阅读。本书适合想要得到跨 we...
-
第二本书
2有用 0无用 焦靖 2008-04-28
第一本书 :JavaScript高级程序设计 http://www.douban.com/subject/1869705/这是第二本.极力推荐....
-
主要译者比较让人放心
1有用 1无用 靛海幽蓝 2009-02-19
本书优点见其他书评,我就不重复了。中文版主要有一点,译者是淘宝UED,比较让人放心,我自己看下来就是这样的感觉:书中有多处注释,是译者对作者描述不清楚的地方甚至错误的地方进行了说明,有不确定的地方也进行了实践检查之后进行了注释。见了太多原作优秀译作垃圾的书,这个是最让人放心的一次了。一般的学习方法可...
书名: ppk谈JavaScript
作者: Peter-Paul Koch
出版社: 人民邮电出版社
原作名: PPK on JavaScript
译者: 淘宝UED
出版年: 2008-4
页数: 337
定价: 59.00元
丛书: 图灵程序设计丛书
ISBN: 9787115175458