I’ve alluded to it a couple times now but it’s probably important to state it definitively: I’m writing a new JavaScript book, to be published by Manning Publishing, called Secrets of the JavaScript Ninja. I published the rough Table of Contents previously and the contents of the book will be staying virtually the same (with a couple minor additions).
I wanted to take this opportunity to give a sort of progress update – letting you know what’s happening. Not enough is said about the process of writing a book (especially technical ones) so I wanted to try and fill in some of the gaps.
Dec 28th: I first decided that I wanted to write a new JavaScript book around the end of last year. While it wasn’t, explicitly, a new year’s resolution – the timing was rather nice.
Dec 28-30th: I then set about collecting some information, trying to decide if the subject matter was worthwhile:
Jan 9th: I decided that I had enough information on hand to warrant a full book on the subject matter (namely advanced JavaScript techniques and cross-browser scripting). I started work on congealing this into a full outline/table of contents.
It was around this time that I started work on my first (non-introductory) chapter: Functions.
Jan 21st: It was around this time that I started talking with various publishers. Luckily I’ve been able to accrue a number of contacts in the technical publishing industry, over the past couple years, so I already had some starting points and good references. I also received a few contacts after my post on the profits of my previous book.
Jan 25th: I made the decision to go with Manning Publishing as the publisher of my book. I had the opportunity to have a number of long phone calls with Marjan (the head of Manning) and he had some fantastic ideas for the book and its direction. Hearing his ideas and excitement was a huge reason for me to go with them but in the end there were a number of reasons for choosing them:
- They were very open to trying new techniques with the book – everything from how it was to be published, what the contents were, to even how the writing process worked.
- When we originally started talks we were looking at the idea of having the book be similar, in style, to other books like Why’s Poignant Guide to Ruby. We discussed this, at length, for quite some time. After a few weeks of mulling it over I decided that this wasn’t the best course-of-action for this book. The mixture of complex material and narrative would not work well, I felt.
- However, we agreed to include a heavier use of illustrations and figures to communicate difficult topics (such as timers or closures). We’ll have to see how this works out, but that’s the current plan.
- The book will have a companion web site which will be open to those that have purchased a copy of the book. It will behave very similarly to the Django Book, in that you’ll be able to comment on any portion of the text – becoming part of the editing and review process.
- I’ll be able to write the book using DocBook, which is a huge win over the old pass-Word-documents-around strategy that a lot of publishers use. Many technical publishers are getting better here – I definitely wouldn’t want to go with one who didn’t support this, or a similar, strategy.
- They have a good level of distribution and their books are widely available in book stores.
- We were able to negotiate a good level of compensation heavily tied to the sale of books, which made me happy.
Feb 3rd: Chapter 2 was completed and submitted on time. I now have an absolute schedule to work against. One chapter every 10 days until the end of August. It’s pretty grueling (as is to be expected with book writing) but I’m optimistic. I started with Chapter 2 so that I could get a feel for how an actual chapter would be written (I dislike writing non-code chapters).
Feb. 17th: Chapter 3 (Closures) completed. I also released a portion of this chapter as a blog post: Partially Applying Functions in JavaScript. I fell behind with this chapter because I was traveling to Mountain View, for Mozilla work, during this period. I suspect that this will happen frequently throughout the summer as I’ll be traveling a lot more.
Around this time I was assigned an editor for my book, Tom Cirtin. I look forward to working with him more – I’ll certainly have plenty of opportunity for that.
Feb. 24th: Chapter 4 (Timers) completed. I’m virtually caught up at this point. However I have to jump back now and finish Chapter 1 (the introductory chapter) before moving on. I released one portion of this chapter as a blog post: How JavaScript Timers Work.
There’s a lot that I’m doing differently from my first book and it’s already making for a saner experience:
For starters this book is highly specialized, it picks one topic and covers it completely (there’s a chapter on closures, on timers, on eval, on with – to name a few). I enjoy giving high-class treatment to obscure topics. Knowing that someone will be able to pick up this book and absolutely see something that they’ve (probably) never seen before makes for a very invigorating writing experience.
Another thing that I learned from my first book was that I really dislike long chapters. To counter this the book is broken up into 21 “small” 10-12 page chapters. I love it, it’s the perfect chapter length, for me. I rarely find that I have more to say on a subject after about 4000 words (which is what 10-12 pages works out to be). With my old book I constantly felt like I had to flush out topics in order to meet page quotas, not so here. This causes me to become much more relaxed, knowing that whatever result I end up with it’ll be an ideal length.
While I wouldn’t call this book a ‘cookbook’ it’s certainly not a traditional-style technical book. I’d say that it’s something of a hybrid between the two. The chapters, thus far, have a structure like: In-depth explanation of topic, simple use of topic, specialized use of topic #1 through #3. For example in the chapter on Timers I dive in to how timers work, look at the minimum timer delays and reliability, explore computationally-expensive processing, build a centralized timer control, and finish up with a look at an asynchronous test suite.
While I don’t have a final date for when the book site will be ready (or when the book will be available for pre-order) you can be sure that I’ll blog about it here, when that’s the case (be sure to subscribe to my blog, if you haven’t done so already, to receive more updates).
In short: I’m really excited about this book. Progress is going well, the publisher is friendly, the topics are ideal, and the content is coming out great.
Oncle Tom (February 25, 2008 at 3:39 am)
Thanks for all these details, it’s very interesting.
I’m looking forward your book as I loved your “Pro JavaScript Techniques”.
Keep up the work, I’m sure you will succeed :-)
serkanyersen (February 25, 2008 at 3:58 am)
must mention about
somestring.replace(/(\d+)/gi, function(all, match){ return match * match; })This is a good secret of javascript.
Keep up the good work.
Robin (February 25, 2008 at 5:59 am)
Definitely looking forwards to this!
Jason (February 25, 2008 at 7:23 am)
I’m really looking for to your book John. Definitely gonna purchase it. Keep letting us know the progress for now.
Dan (February 25, 2008 at 8:04 am)
You mentioned skipping to Chapter 2 because you dislike writing non-code chapters. Have you considered not writing Chapter 1 at all? The standard chapter 1 in tech books, explaining what’s going to be in each of the other chapters, and that code is printed in a monospaced font, and how to read the book, is worthless padding that I, for one, would not miss.
Make every page in your book count. It may be inspiring to take a look back at books like K&R’s The C Programming Language in comparison to today’s 800 page bloated monstrosities.
Mike Purvis (February 25, 2008 at 9:54 am)
I’ve had mixed feelings about technical books that I’ve bought in the past. Even some of the best, like Jeremy Keith’s “DOM Scripting” I felt were well put-together and advocated good practices, but still didn’t really teach me anything new.
This book, on the other hand, looks to be a really interesting and worthwhile read. Most of the topics I have a working knowledge of, but having the full story laid out really helps sharpen up the tools and make a person aware of different gotchas and corner cases. For example, I didn’t know about dropped setInterval callbacks until reading yesterday’s post, but now I can think of cases where I might use an interval instead of daisy-chained timeouts.
I’m definitely interested in your take on the object prototype business. Everyone and their mother seems to have an opinion about exactly how that should be done, and it looks as though JS2 is just going to make matters even more confusing by introducing
classandextendsas keywords.Hugh Bien (February 25, 2008 at 11:08 am)
Glad to see progress is coming along well. I really like that you’ll be including a chapter on testing, I’ve googled around and have found very little about unit testing Javascript. Congrats!
John Resig (February 25, 2008 at 11:14 am)
@serkanyersen: That’ll be in Chapter 6 – RegExp!
@Dan: Oh no, I definitely wouldn’t write dreg like that for the introduction. In my first book I gave a good overview of the contents and what I hope the reader will achieve by reading it. I’ll be doing something similar here as well but with a strong emphasis on why I’m writing the book like I am (with the focus on libraries and library construction). It’s not as bad as I make it out to be, the chapter is definitely necessary.
@Mike: Anything relating to Object Prototypes that you’d like me to cover, specifically? I’ll be writing that chapter next (after the introductory chapter).
Dan Dorman (February 25, 2008 at 1:53 pm)
This sounds like it’ll be a phenomenal book, John. I can’t wait.
Hamish M (February 25, 2008 at 2:42 pm)
This is great. I own another book from Manning and I really enjoy their publishing style. Do you plan on having a PDF version?
Mike Purvis (February 25, 2008 at 4:35 pm)
Re: Object Prototypes
The style I’m most used to for defining functions and inheritance is what I think of as the “traditional” model:
function Parent() {// constructor
}
Parent.prototype.someMethod = function() {
// Parent's method
}
function Child() {
// constructor
}
Child.prototype = new Parent();
Child.prototype.otherMethod = function() {
// Child's method
}
It basically works pretty well, but the obvious weakness is that you have to instantiate a dummy Parent to use as Child’s prototype. I know other strategies include having a
delegatefunction (or sometimes method on Function.prototype) that spiders an object’s prototype and copies the method references over one-by-one.I guess I’m just curious to know what are the leading mechanisms for handling inheritance in JS, and what the important advantages and drawbacks of the different approaches? How much of it is syntactic sugar, and how much is just religion? Of the differences that appear superficial, is there a good reason to do it, say, the way the jQuery code does, with all those methods keyed to their names inside big objects?
Filipe Campos (February 25, 2008 at 5:24 pm)
looking forward to read…
Richard D. Worth (February 26, 2008 at 4:55 am)
This is very exciting to watch, John. Thanks for sharing the entire process with all.
Johan Sundström (February 26, 2008 at 10:48 am)
Might be a tad late to make the Functions chapter (unless the writing process is as flexible as it ought to be :-), but a great javascript ninjutsu moment of mine was when I realized that the composition of encodeURIComponent and unescape make an UTF-8 encoder, and that the composition of escape and decodeURIComponent make an UTF-8 decoder, because the other effects of both functions cancel out (example).
It’s definitely a tip befitting your book, if it’s not there already.
Joe (February 29, 2008 at 7:03 am)
Cool. Loved your Pro JavaScript book.
Will this be available for the MEAP (Manning Early Access Program)?
Nick Fletcher (March 1, 2008 at 8:58 pm)
Great news. I think read I Pro JavaScript Techniques from front to back in about a week.
Craig Buchek (March 3, 2008 at 9:59 pm)
What are you using to write the DocBook? Are you editing the raw DocBook XML, or are you using some pseudo-WYSIWYG editor to make it more manageable? I think DocBook is great, but have never found an editor that made it reasonable to author.
Ryan Dunphey (March 7, 2008 at 1:45 am)
“this book is highly specialized…high-class treatment to obscure topics.”
This is exactly what is needed in our discipline; I cannot wait!
Thanks!
Agent G (April 19, 2008 at 8:10 pm)
Secrets of the JavaScript Ninja
Love the title!