Node.js in Action by Mike Cantelon and TJ Holowaychuk, is a book that tries to introduce the platform to web developers coming to Node from established technologies such as Ruby on Rails and PHP.
Node.js is an elegant, server-side, JavaScript development environment suitable for scalable, high-performance web applications. With Node you access HTTP and TCP/IP functionality through a minimalist server-side JavaScript interface. It supports an asynchronous programming model that is especially suitable for real-time applications such as chat, online games, and live statistics.
Node.js in Action aims to be an example-driven tutorial that starts at square one and guides the reader through all the features, techniques, and concepts they'll need to build production-quality Node applications. Readers will start by learning how to set up their Node development environment, including loading the community-created extensions. Next, they'll run several simple demonstration programs where they'll learn the basics of a few common types of Node applications. Then they'll dive into asynchronous programming, a model Node leverages to lessen application bottlenecks.
After the basics, follow things like Node's HTTP API, data storage, application deployment, output templating, filesystem interaction and non-HTTP applications, such as TCP/IP servers and command-line tools.
The book’s publisher, Manning, has provided InfoQ an exclusive excerpt from Chapter 3, “Asynchronous Programming Techniques”.
InfoQ had a Q&A with the authors about their book and Node.js:
InfoQ: Would you like to tell us a little about yourselves and your background?
TJ Holowaychuk: I'm TJ Holowaychuk, I'm 24 and I live in Victoria BC, Canada, and I'm working with the awesome team at LearnBoost, building revolutionary education software. I started off as a graphic designer roughly 4 or 5 years ago, later getting involved with software and realized that in many respects software can be just as creative, if not more so. I'm 100% self-taught in both fields, however I made the usual mistake of learning PHP before anything else.After a year or two of writing Drupal modules & web applications I started dabbling with other languages, and soon realized that PHP is terrible. I went on learning a few more languages and ended up settling with Ruby & the Sinatra web framework, which I used to write corporate data-mining software for roughly a year and a half.
My first year of Ruby opened my eyes to some new concepts, although the more experienced I became the more I disliked the magic the language provided, which was often misused and caused nothing but ambiguity and headaches. I started getting interested in parsing technologies like Ragel and Lemon which lead me to Ryan Dahl's "ebb" server for Ruby, which I believe was the early inspiration for Node.
Mike Cantelon: I'm Mike Cantelon, 39, and live in Vancouver, BC. I've worked with PHP for over a decade doing a wide range of custom application development. I worked with a small company for a number of years where I was lead developer for a proprietary content management system. It was pretty full-featured, but we weren't funded and had to do a lot of other custom development to keep the company going. As we tried to market it, open source solutions started to make our product look increasingly irrelevant. Exposed to open source software, I ended up getting interested in the culture and decided to change focus and take on a gig where I'd work with Drupal. I currently work with a Vancouver alternative newspaper, providing Drupal support for a small development team.PHP has a lot of limitations and playing with other languages has kept me sane over the years. I spent a few years playing with Python and Ruby and eventually ended up revisiting JavaScript. This led me to being exposed to, and amazed by, Node.
InfoQ: Would you like to give us an overview of what Node.js is and what attracted you to it?
TJHolowaychuk: After discovering Node early on (one of the first ~30 in IRC?), I started prototyping the Sinatra-inspired framework Express. Very quickly I realized that Node was quite different, but at the same time quite natural for writing servers and web applications. The data-mining load that had previously required many Ruby worker processes, were immediately more expressive, natural, and performant than my Ruby implementation. Plus JavaScript is just a nicer language to work with in my opinion.
Mike Cantelon: I ended up being exposed to Node later on, through a blog post by Simon Willison I came across in early 2010. Node amazed me: something that let you not only write web applications in JavaScript, but also write low-level TCP/IP applications and protocols.
InfoQ: What types of applications do you think are especially suitable for Node.js and which would benefit more from alternative technologies?
TJ Holowaychuk: I think Node's use is already quite broad considering it was intended as a networking platform, but due to that focus it naturally provides a solid base for writing web application servers. Another obvious benefit is code re-use and simply the fact that you can write JavaScript for the server and the client, which is definitely a win.Node is great for virtually anything with a concurrency requirement. This would be things like IRC & mail servers, web services, job queues, and essentially anything "real-time", be it a chat, log reader etc. Also with the massive list of third-party modules to choose from, Node is becoming a tool for almost anything you can think of: command-line tools, s3 clients, proxies, you name it.
Mike Cantelon: Yeah, I'd second that. Because Node, and the modules created for it by the community, is relatively cruft-free it's a joy to work with for pretty much anything.
InfoQ: How is the current adoption of Node.js? What do you see people using it for?
TJ Holowaychuk: For such a young project I think the adoption is absolutely amazing; I can't say I've personally seen anything that has grown faster. Like I said, in roughly two years it went from a few people in IRC and a few hundred mailing list subscribers, to several thousand, not to mention major interest from large companies like Google, Yahoo, Facebook, and Twitter.I've seen quite a few interesting uses for Node. There are some very well done real-time analytics tools out there, as well as real-time heat maps showing user interactions, multiplayer game servers, among more typical things like chat servers.
InfoQ: As a complete stack or just a small addition to their existing infrastructure?
TJ Holowaychuk: Both! Frameworks like Drupal or RoR are quite robust, but they are not designed for real-time applications, though there's no reason you cannot use both! One obvious downside is that you can end up duplicating logic, be it database models, session integration or similar. I've seen quite a few uses of Node with many of the popular & more opinionated frameworks out there, for things like we've already mentioned: chat servers, live statistics, reporting, feeds, mapping etc.
Mike Cantelon: Definitely. I think, also, that as more high-level open source web applications get created in Node, such as content management systems and blogs, it'll induce people with less Node experience to either start out with Node or migrate to it.
InfoQ: What are the biggest challenges for using Node.js? How should a team go about adopting it?
TJ Holowaychuk: Node moves fast! Both core and the community-driven modules are constantly evolving and discovering better patterns, so at times it can be a bit of work to keep up.
InfoQ: Are there things that you feel that are currently missing from Node.js, since it is still a fairly new platform?
TJ Holowaychuk: One thing that I really do miss from Ruby-land is solid scraping tools. JSDOM is getter better all the time, and some of the HTML parsers are ok, but I found that they are currently not as robust as Nokogiri and some other Ruby tools that I was using for mining. I have to say though, JSDOM has more potential... it's the DOM... on a server... that's pretty cool!
InfoQ: How is the developer’s experience in Node.js compared to other platforms?
TJ Holowaychuk: I think most engineers, specifically ones that are not overly familiar with JavaScript, find it both intriguing and aggravating at the same time. Quite a few people refuse to take the time to really learn to appreciate JavaScript, and immediately jump to one of the many languages that compile to it, allowing them to write Python-like or Ruby-like code while still utilizing Node.JavaScript is in a unique position as it's essentially the only language you pretty much have to use, but I think many people are mistakenly jumping to these languages before taking time to learn JavaScript, potentially even appreciating it. Some people make similar mistakes when learning Node; they will pick up Connect or Express before even trying a basic Node HTTP server.
In general though, I think a lot of people appreciate where Node is at. Most of the frameworks are still relatively low-level, so you're forced to learn certain things about HTTP, TCP, and web apps in general, that otherwise a larger framework like RoR or Drupal may completely abstract away. I think this is somewhat comparable to the army of jQuery users that know nothing of the DOM. I'm not saying it's necessarily a problem, but I've seen comments from quite a few Node/Connect/Express users that were very happy about learning some lower-level stuff.
Mike Cantelon: The low-level stuff can definitely take some time to grok, but overall I found creating web applications with Node to be much easier to learn than other technologies I've played with over the years. I think one big plus for Node is having a lot of clean community-created modules and a good package manager.
InfoQ: What tools or libraries would you suggest to Node.js developers? What are your favourite ones?
TJ Holowaychuk: Like I've been saying we have some pretty talented people in this community, producing some pretty awesome libraries. One of the really great things about Node is that, unlike environments like Ruby, it does not ship with a large, unwieldy, stale standard library. The majority of the third-party libraries are focused, and generally well built, and everyone is really passionate about keeping core clean (hell we've had massive debates about a single character).One of my favourite libraries is Matt Ranney's Redis client: it's efficient, elegant, and battle-tested through its every-day use at Voxer, Matt's "Live Walkie Talkie".
Socket.IO is an obvious choice, abstracting away the massive mess that is client-side streaming into a unified, elegant, high performance library of awesomeness. I'm assuming you already know what it is, but if you don't, go find out.
Formidable is another great library that pretty much everyone uses for multipart parsing. It's built by Felix Geisendörfer for his upload startup "Transloadit", where it's battle-tested and powering through gigabytes of uploaded data.
Nodejitsu's node-http-proxy is pretty handy too. Compared to using nginx or HAproxy as a reverse proxy, setting up node-http-proxy is really trivial so you can set up "vhosts" and other proxy behaviour in no time, and in JavaScript! Boom!
Mike Cantelon: There's definitely a lot of amazing tools available. Express, of course, is a great all-purpose web application backbone. Connect, which Express depends on, is also super handy, providing essential low-level web application functionality. node_redis, which TJ mentioned earlier, provides painless Redis access and I'm also enjoying Mongoose, which provides a high-level interface to MongoDB data.
InfoQ: How important do you think Node.js is outside of the context of web servers?
TJ Holowaychuk: Pretty important. Not only is it relatively easy to write custom protocols, fast TCP servers etc, you really have to try to make them slow; even inexperienced Noders should see pretty nice results. I can only speak for myself but it's the most natural networking framework I've ever used. People complain about callbacks, but in some sense they help get your mind in "async mode", because visually there's a distinction between what happens now, and what is asynchronous and will happen later.
Mike Cantelon: Callbacks took a while for me to get used to, but now they seem natural. Node is definitely not just for web servers: for me, Node has even made writing CLI tools fun again.
InfoQ: Are you satisfied with the current JavaScript tooling, compared to other languages, e.g. Java? What do you usually use in your daily work?
TJ Holowaychuk: Yes and no. Some aspects are better than what I've found in other languages, some are worse. Working within a community that compiles to JavaScript from many other languages can be a pretty big pain in the @#$ at times contribution-wise, or when people expect you to integrate these things into your existing libraries. There are simply too many of these languages to be doing that. I think these people just need to spend more time learning and appreciating the features that JavaScript provides you, not complaining about syntax. If typing is your bottleneck, you're doing it wrong.Node's package manager, NPM npm, are nicer than what I have used in other languages. I think this is largely because we don't have as much legacy functionality to support, so for example localized installations are the norm now, where they were not with earlier versions of npm. Either way npm is working pretty good lately; the simple fact that it doesn't really get in your way is really all a package manager should be, and I'm grateful for that! It's certainly the foundation of a solid ecosystem.
We currently have many, many, many test frameworks in node, which is great, but none of them seem quite right yet; this is definitely an area that can be improved. Testing asynchronous logic can be a bit trickier than what you might be used to in other languages, but you get used to it.
InfoQ: How do you see Node.js evolving in the future? Would you like to see some new features, improved stability, performance, or what?
TJ Holowaychuk: Just like any software I expect Node to stabilize, but not too early. Everyone wants a stable framework, but at the same time Node shouldn't be too concerned with legacy APIs right now. If it needs to change them, it has/probably should continue doing so in pursuit of perfection.The stream API could be a bit easier to work with; it's a nice simple concept but currently it's a bit difficult to construct stream-like objects as the machinery is reasonably involved at the moment. There has been talk about filter-like APIs for streams as well, for example piping the contents of a file through a gzip "filter", and out to a socket.
About the Book Authors
TJ Holowaychuk is a prolific open-source engineer who has backed Node since its infancy. He has also authored many robust Node.js modules, including the popular Express web framework, Cluster, Stylus, and Jade, among many others.
Mike Cantelon is a web programmer with 10 years of experience in bespoke and product-oriented web application development.