I'm really glad I checked out this posting because it led me to the author's other work, which is really impressive. http://kumailht.com/
Way to go, great looking stuff.
Thanks for the excerpt. It's not long, but I enjoyed the writing, it's crisp, fast-paced, and covers a lot of ground. (I imagine Peter's lectures to be similar!)
This gave me the confidence to order the book.
I think it could work well to start with CoffeeScript -- that is, to learn JavaScript by first learning CoffeeScript. For the real world you must understand native JavaScript, of course, but that could come incrementally. I don't actually know anyone who's done this, however.
Agree, though following this would lead me to extract all kinds of implicit library code from my applications. Likely not worth the effort without a genuine reuse story.
Reading the comments so far, this question seems to necessarily raise another:
What is the best team size?
Let's say it's 3. (1 has too much risk and 10 has too much overhead.) Once your productivity needs exceed what 3 average developers can accomplish, if you place importance on team size, it makes sense to pay more for higher performance in order to avoid increasing the team size.
It's like paying to upgrade hardware on the network nodes you have (which exist to mitigate risk), rather than distributing work across more and more network nodes.
I'm currently writing an eBook teaching Backbone.js in CoffeeScript, of about the same length as Recipes with Backbone. I'm still mulling over how to price it. Does anyone want to make a guess about the potential size of the market? Am I correct to think, the bigger the market, the more cheaply I can price it and still make a bit more than minimum wage for the time I'm putting in? Any further comments or suggestions about pricing are welcome.