The Node Firm

Essential Node.js Training Course


Firm Blog

Updates & news from The Node Firm

Page 2 →

- Trevor Norris - performance

On January 31, 2014 my second son was born. That evening, while my wife and newborn were getting some sleep, I decided to jump on my phone and try to respond to the never ending mound of issues that seem to pile up in the Node repository. One of which was about enabling the --harmony option by default. Unfortunately one of my comments was misinterpreted by some. I will gladly take the blame for being simultaneously over-broad in my description of features accepted into Node core, and non-specific about what core means.

Though bear in mind I never thought my comment would be taken so far as to lead some to believe Node would actually fork V8, or some such, to prevent ES6 features from being available in Node (especially since we had already done for one feature what this PR suggested we do for several others). Or because just prior to that paragraph I had discussed my conditions for allowing --harmony to be enabled by default, and it would have been a contradiction to then say it would never be allowed.

So first I'd like to clarify that I improperly referred to the entire ES6 spec. In that post I was specifically referring to iterators, generators and promises. Second I'd like to state for the record that I've never had the intention of preventing any Node developer from using new features coming to JavaScript, or from preventing these features from being exposed to the user if enabled in V8 by default. Last clarification is that the reference to "core" meant core code.

My Node Future

Some of your are probably thinking, "Why wouldn't he want to save us from callback hell and integrate a generator/promise based API?" The reasons are simple and pragmatic. First is because the key thing Node does (integrating JavaScript with the V8 C++ bindings/libuv) can only be done via callbacks. Second is that I want to remove abstraction and allow users to interface their code as close to the action as possible.

The community has proven two things. First is that none of us agree on how an API should be written. Second is that there are very talented developers that will push Node to the limits. My hopeful goal for Node is to introduce a standardized minimal API that sits very close to these C++ bindings. From there the community can create whatever interface they want with as close to zero unnecessary overhead as possible.

I want Node to be tremendously good at one thing. Being the kernel of a web platform for app developers who wish to write in JavaScript. That means writing an API that allows minimal abstraction and as close to zero overhead as possible. So why use the callback style? Because currently it's the only way to interface with the V8 C++ bindings. When the V8 team introduces an API for generators or promises I will give it honest consideration.

Moving at Node Speed

Some days I like to write little apps that sit directly on top of the internal C++ API (Max, promise I haven't forgotten about the router app). Every time I do this I'm reminded of how much performance is left on the table due to abstraction.

Imagine you want to saturate 100Gb pipe with TCP traffic. That means you'll be sending at least 204,800 packets a second. Which also means something needs to be executed at least 204,800 times per second to send that data. Small amounts of extra abstraction start to make a big difference in performance at this level.

The V8 team has done some amazing stuff to improve performance in key areas that are important to Node (although I doubt they had Node in mind when making those changes, but I'll take it anyways). Things like making calls between C++ and JavaScript have become extremely cheap—we're talking double digit nanosecond cheap. I'm working on new performance patterns that can hopefully be integrated down the road that will allow techniques like using JavaScript to chain a series of C++ callbacks together, useful for high performance transforms.

There is still so much more to be done, but if we're really going to make Node fast and keep it lightweight then it must be done using a specific subset of the JavaScript specification. Just how far can we push Node? Let me just say you ain't seen nothing yet.

Thank you,
Trevor Norris

This post first appeared on Trevor Norris' blog

- The Node Firm - news

These past seven months, David Dias has been with The Node Firm as the first ever #firmintern. David epitomizes everything we love about the Node Community with a contribute first mentality and a sincere desire to help others.

When David joined us, he had already run two conferences, organized multiple meetups and was a dedicated Node.js developer. David was quick to learn and and lead the efforts to upgrade to use Hapi.js. David helped us enable performance monitoring with New Relic. Together we launched new online initiatives like Node Firm Office Hours and Node.js Performance Analysis Training with Trevor Norris. He helped us make Node Summit amazing.

David worked tirelessly with our course development team in an around-the-clock to help create a custom training program for one of our clients. David was instrumental in making this insurmountable task possible. In fact, we delivered an extraordinary experience within an implausible amount of time. Last but not least, David helped kick off a new initiative where The Node Firm is helping support the Node Core team deal with core issues. David has truly helped make The Node Firm better in the time he has been with us.

It is with great sadness and respect that we say goodbye to David today. Nonetheless, he won't be going far. Join us in congratulating David in joining the Node Security team with Adam Baldwin. We will miss you and look forward to your amazing contributions in this very important project.

Thank you,
Your Friends at The Node Firm

- The Node Firm - News

This month's Node Firm Office Hours will feature Adam Christian and Daniel Shaw. They will discuss the challenges of large scale testing and explore what works and what doesn't in the realms of automation, testing and test-driven development.

Schedule (Pacific Time)

10:45am - 11:00am PST Setup and Registration
11:00am - 12:00pm PST Office Hours

Office hours topics:

  • What frameworks have you used?
  • Favorite testing framework (Node.js) or which framework do you hate the least?
  • Unit vs Integration vs Functional. Fight!
  • To mock or not to mock.
  • Challenges of testing at scale across a large number of devices and platforms.

Hosts: Adam Christian, Daniel Shaw


Join us for office hours Thursday at 11:00-12:00 PT.
Signup now:

Thank you,
Your friends from The Node Firm

- The Node Firm - News

The Node Firm is preparing a new half day Performance Analysis training. Each topic has been specifically chosen to address issues most common to Node.js application development. This training will instruct how to quickly identify and troubleshoot existing performance bottlenecks, and architect more scalable APIs going forward.

Key topics include:

  • Understanding how Node handles I/O
  • The basic tools of Performance Analysis
  • How to apply what you find
  • Performant module development patterns
  • Writing useful benchmarks

This training will be presented by Daniel Shaw, CEO of The Node Firm and experienced Node.js Engineer, and Trevor Norris, Node.js Core Maintainer and performance freak.

Unique Format

We will be introducing this as a prototype for a totally new course format. We will be offering this course online. This will be our first ever online offering! It will feature a unique, engaging format. The course starts with a half day hands-on training session. Then, the following week we’ll reconvene for and optional in-depth Q&A and deepening understanding session.

This will also be available as an onsite course in conjunction with our performance tuning and benchmarking services.


Students taking this course should have strong Node.js programming experience from The Node Firm’s Advanced Node.js Development or equivalent with a solid understanding of core Node.js patterns and primitives including the module system, Event Emitters, Buffers and Streams.

Pre-Register Today

Performance Analysis Training pre-registration

Thank you,
Your friends at The Node Firm

Page 2 →