Blogging OSCon Day 2: Node Day

In which I learned to stop worrying and love the Node.js. During Node Day I was able to connect with real-world examples of people running Node in production, talking about why they chose Node, and how it was working out for them. As a by-product, I started to grok the things I had learned the previous day in the Node Tutorial. To sum up the talks of the day:

Tim Caswell talked about translating the SDL Library into a Node.js extension. He claimed to not be a strong C programmer, and he accomplished quite a bit despite that limitation. This gives me hope, for if we were to similarly port Contacts to Node.js, there would be some heavy lifting in the C world to accomplish first. Guillermo Rauch live-coded an HTML messenger client from scratch, demonstrating the steps it would take to do so as well as showing of The most impressive bit was Guillermo’s almost flawless, fast typing. It was also neat to see how little code was required to make this happen, he got it done in 20 minutes or so.

Ryan Dahl gave a talk on porting Node.js to Windows. Apparently there has not been a release of Node.js in some time as they have been doing all of the porting work for the past few months. The new system framework is being built alongside the old Node.js system framework. If you are running the unstable branch of Node, you can try out the new code by using the --use-uv command line flag. It sounds like these guys are going through the same work the FastCGI for IIS project had to go through to port to windows (the same discussion of threads vs forks came up, at least.) Another interesting tidbit: the 3.4 version of V8 cause a 10% performance drop in Node. They feel bound to stay with the latest V8 version, and are working with the V8 team on the issue. Dahl also expects there will be a stable 0.6.0 version of Node.js in about a month.

Tom Hughes-Coucher did not talk about scaling, as the talk description might have led one to believe, but more on overall performance and benchmarking Node. For the most part he was responding to this article on Node vs Erlang performance. The really interesting thing here for me was to reduce my ignorance of the technological landscape in which Node exists. Otherwise Tom’s basic point was benchmarks are often flawed, tough to do right, and would like to see real-world use case benchmarks rather than artificial stress tests. He also stressed looking for the hot-path perf blocker for your use case. All pretty common-sense but worth-repeating type of stuff.

The next few talks had similar themes, mainly running Node.js with a real application in production. These were great to hear first-person perspectives on running and deploying Node to production. Paul Querna from Rackspace had the most detail on tools and process. They have created their own Node package repository for pushing in-house patches to public packages. It is an extension of npm which checks their package repository before hitting the public package repository.  The other interesting bit from his talk was the discussion of Node.js and SSL… apparently all is not yet right in the world between these two, regarding performance. He recommended running stunnel+haproxy or stud+haproxy as a solution to Node’s SSL woes.

The final talk was Elijah Insua discussing the design and development process for JSDom. This is a module that aims to be a faithful replication of the DOM per the w3c spec. This is what both jQeury and YUI use to run server-side in Node. It currently supports Dom Level 1+2, and they are actively working on the DOM Window global object (which is not covered by a spec but is a collection of vendor conventions), and DOM Level 3. Caveat, there is a memory leak (I believe it was in using setInterval/setTimeout, the context is not being released) which they are aware of and working on.

The session ended with a roundtable Q&A with the speakers. An interesting question came up regarding sharing code logic between the client and the server. The surprising answer was none of the speakers thought this was a good idea, or could see a use case. One of the justifications I hear frequently for Node.js is that you could potentially share code between client and server. This was a good confirmation of what I had come to on my own after this day of examples. Node.js code needs certain extensions that are not compatible with client-side code. Node.js server-side code is not portable in that way without some effort. You need to use the “require” keyword to include other modules, and the syntax for creating a module is a bit odd and not useful outside of the Node.js context (it is from a standard called “CommonJS” but insofar as a browser is concerned, not helpful.)

Final Thoughts

This day of Node left me feeling excited about the technology. These guys made programming for Node seem fun and cutting-edge. The attitude was DIY, a few talks mentioned not relying on other libraries that you could write yourself in a few days. Much was made of the simplicity of the platform and how few lines of code many of the demonstrations required (not counting whatever code went into the modules being used as middleware.) After seeing the support Node has in its modules, it no longer seemed like such a problem that you have to re-create basic functionality like listening for HTTP connections or doing basic server access logging.

However! For a company like Yahoo!, the migration will be non-trivial. Our basic apache comes with a lot of pre-configuration that will be a hassle to re-create. Using Node.js in that context will require a bit of heavy lifting by a variety of parties. For the short-term, we may be able to find use-cases where Node can fit, but we will have to proceed very carefully. For the long-term, Yahoo! as a company would need to decide whether it wants to support Node for the long-haul and put together a package covers the areas that apache currently covers. (Note that the relevant folks at Yahoo! are already aware of this, however now I have a deeper understanding of what is missing for us to go full-bore Node.)

So work-related use cases aside, I am looking forward to mucking about with Node on personal projects!

Links Round-up

More tools and modules were discussed than I could possibly cover. The following is a rough round-up of all of the links that made it into my notes.


winston  more
log magic


whiskey Example coverage report



JS Lint

Closure Linter


weld  more


One thought on “Blogging OSCon Day 2: Node Day

Leave a Reply

Your email address will not be published. Required fields are marked *