JavaScript Technology Writing

My Last O’Reilly Book

The editor for JavaScript Cookbook, 3rd edition, just sent me a draft to review and comment on. This is the last of the O’Reilly books that will feature my name on it. I wasn’t actively involved in it; my name is on it because they kept about 15% of my old content. New authors, Adam Scott and Matthew MacDonald, took on the majority of the work.

They did a good job, too. I particularly like the chapter devoted to error handling. The days of using an alert message to debug have been gone for decades, and JS developers now have sophisticated error-handling techniques and tools. It is no longer your Mom’s JS.

Good. I’m happy the language and its uses have evolved. But…

I sometimes miss the simpler days when an alert was your JavaScript best friend.

I’ve been working with JavaScript since it was first introduced over 25 years ago. Not just traditionally in the web page, either. I worked on a small project that used Netscape’s server-side JavaScript (LiveWire) in the 1990s. It was so very different from an application made with Node. as you can see for yourself from an old Dr. Dobb’s article on LiveWire.

Writing about JavaScript today requires a different mindset than writing about it years ago. Then, JavaScript was laughably simple. It’s simplicity, though, was also its strength. In its infancy JavaScript was so embraceable. You could literally toss a tiny blurb of JS into an HTML file, load it into a browser, and see an immediate implementation. You didn’t have to fiddle with compilation, installing special developer tools, or figure out a framework.

My first book on JavaScript, the JavaScript How-To for Waite Group Press was published in 1996. The hardest part of writing it was trying to find enough about JavaScript to actually fill a book.

JavaScript today, or ECMAScript if you want to be pure, is not so simple. And oddly enough, that’s its strength now: it is powerful enough to meet today’s very demanding web applications. And the hardest part of working on a book such as the JavaScript Cookbook is limiting yourself to the essentials, because you could easily write three or four books and still not envelop the world of JavaScript as it exists now.

When O’Reilly asked me to do a new edition of the Cookbook I knew I just didn’t want to take on that kind of burden again. It was hard to give up control of one of my favorite books, but after 25 years of working to deadlines and dealing with tech editors, I knew I just didn’t have the energy or patience to do the book justice. I knew it was time for me to hang up my drafts.

Thankfully, the new Cookbook team have done an exceptionally good job. I’m happy to have my name on the Cookbook, one last time.

If I write now, it’s solely for me: my ideas, my deadlines, my expectations. I may only write in this space. I may try my hand at self-publication.

Who knows? Maybe all I’ll do is write incendiary commentary in Facebook and Twitter and see how often I can get banned.

JavaScript Technology

Solving the Node Buffer Constructor Deprecation problem


With the EOL (end of life) of Node 4.0 and the introduction of Node 10 coming in April, it’s time to look at that perennial Node problem: what to do about the Buffer constructors.

JavaScript Writing

My latest, and last, book for O’Reilly

I said a few years back that when Node.js released version 1.0, I’d issue an update for my book, Learning Node. Little did I know that waiting for Node.js 1.0 was like waiting for Godot, but in JavaScript.

I did try to do an update on the first edition of Learning Node earlier this year, but the changes were just too significant. So many of the modules I covered are no longer supported, Express 4.0 happened, and then there’s that Node.js/io.js thing, and skipping version 1, altogether. The first edition of Learning Node just can’t be updated, in place. The only solution was a new edition. It’s also a good time to do a new edition: there’s more stability in the development of Node.js, and less personal ownership.

I just hit the half-way mark in Learning Node, the second edition. It should be out for early release in January or so. The finished book should be in the market some time around April/May. We took a different direction with this book: smaller, learner, and staying closer to the core of Node.js. I’m very happy with the direction it’s taking. It’s the Learning Node book I probably should have written, way back in Node.js’s infancy.

Of my books, I finished JavaScript Cookbook, second edition earlier in the year, and I’m happy with it. I like the design of the book, and feel it’s nicely comprehensive. A new author has taken over for the Learning JavaScript series, beginning with Learning JavaScript, third edition. I’ve been chatting with O’Reilly about releasing Practical RDF to the public domain. With the second edition of Learning Node on its way to completion, I feel it’s a good time to ease my way out of writing books for O’Reilly, and finally take the plunge to self-publication.

My first book for O’Reilly was Developing ASP Components, published in 2001. It actually hit the Amazon top 100 bestselling books list for a brief moment. In 15 years, we’ve managed to publish 16 books, and I’m proud of all the work we’ve done together. O’Reilly has been a good publisher, and a good company to work with. They’ve always been supportive of my efforts. I’ve enjoyed working with the people, including, and especially, my long-time editor, and friend, Simon St. Laurent.

JavaScript Writing

JavaScript Cookbook 2nd Edition: Live and Personal

JavaScript Cookbook cover

The second edition of the JavaScript Cookbook just went live at O’Reilly. If you’re wondering why I haven’t been writing about technology as much lately, it’s because I was saving all my tech writing mojo for the book.

We went a somewhat different path with the second edition. I spent a lot less time on syntax, and a lot more on JavaScript in use. When I wrote my first book on JavaScript, in the dark ages that was the mid-1990s, syntax was about all you had with JavaScript. Now, JavaScript is everywhere. It’s the programming language that ate the world.

Well, nibbled the world. JavaScript is still that friendly, approachable language, even with the new ECMAScript additions. JavaScript has never roared; it’s meowed and purred its way into our lives. Good kitty. Nice kitty. Here, have a closure.

In the new edition of JavaScript Cookbook, I covered JavaScript in the browser, and re-visited our old friends (Ajax and the JS objects), yes. But I also spent a considerable time covering JavaScript in the server, in the cloud, and in our mobile devices. The only environment I didn’t cover is the open source hardware, DIY, wearable world, and that’s because I feel these need more preliminary introductions to the environment, so you don’t do something like fry your new Raspberry Pi. Or Computer. Or shirt.

I will never join with those who are critical of JavaScript. I have always had fun with this language. There’s just so much you can do with it.

Books JavaScript

JavaScript, not a ‘real language’

Simon St. Laurent and I have been discussing that exciting upcoming conference, DHTMLConf.

Party like golden sparkles following the mouse cursor is cool again!

If you’re going to JSFest, how can you not go to DHTMLConf? This is a conference celebrating a time when all of the technologies we take so seriously now, were fun!

Simon is going, and is taking along a copy of his old Dynamic HTML book he managed to find. That made me dig around online for anything on my old books, including my Dynamic HTML book (1998), as well as my earlier (1996) JavaScript How-To.

I had to laugh when I saw the marketing blurb attached to the JavaScript How-To book at Amazon:

JavaScript is the ultimate in web eye-candy. It is not a real programming language such as Java, and it isn’t really essential for web site development, but it sure is a lot of fun for tinkerers.