Nearing Practical Maintainability

On what was probably a sunny day in 2012, our fearless leader, isaacs, created the current version of the npm website, internally referred to as npm-www. In light of the general lack of established patterns for using Node.js to make web applications, isaacs created a fully-functional, mostly-modular application that did exactly what it needed to do: it let people see the npm package ecosystem online.

Fast forward a couple of years, and the npm-www codebase isn’t as manageable as it used to be. It takes newcomers somewhere on the order of months to get familiar enough with the codebase to be fully productive; the structure of the application causes some race conditions that can’t be fixed without some major rewrites; and as npm is a company now, the impending redesign requires a user experience that won’t happen easily in the current architecture. So we decided to start over from scratch.

That’s right: we’re rewriting npm-www.

Knowing full well that this isn’t a task to be taken lightly, we started out with some really important goals:

Modularity - our ecosystem is all about modules; our website should be, too
Minimal cruft/extra baggage - give us what we need and let us add anything else we want
Ease of use/development - new contributors should be able to start adding within a day (preferably in a few hours, max)
Templating/CSS preprocessors - let’s modularize our pages and get our new designs into production as quickly as possible
Reliability - we want it to work in production right out of the box; the latest hotness that needs extra flags won’t work for us
Security - the safety of our users’ data is non-negotiable
Support - when we have questions or bug reports, turnaround time should be minimal
Productivity - we need to get this site up and running soon

With all of these goals in mind, we decided to pick a framework. While, yes, we could use barebones Node.js and roll our own framework, we want to avoid the same “special snowflake” situation that we’re currently in. Plus, by using a framework, we can focus more on pushing out the features our community wants and needs, instead of debugging some weird nook and/or cranny that someone forgot about.

We looked at a bunch of different frameworks, including Restify, Sails, Keystone, KoaJS, Express, and Hapi. We evaluated each framework based on the goals listed above, and found most of them didn’t fit our use case.

The Contenders

Restify - Restify doesn’t have a templating engine or any front-end bits at all. However, we are using it for our microservices.
Sails - Sails cares a lot about security, but also includes a lot of functionality that we don’t need for this project (including socket.io and ORM database support). It’s more than we need.
Keystone - Keystone is a wrapper around Express, with heavy reliance on MongoDB. That, combined with the emphasis on CMS abilities, isn’t a good fit for our use case.
KoaJS - Koa uses generators, which requires Node.js version >= 0.11.6 and use of the --harmony flag. While we love bleeding-edge technology, we’re not sure if it’s production-ready today.
Express and Hapi - Both Hapi and Express rate extremely well against our juding criteria. To choose between the two, it pretty much came down to the framework architecture: Hapi’s plugin system means that we can isolate different facets and services of the application in ways that would allow for microservices in the future. Express, on the other hand, requires a bit more configuration to get the same functionality (it’s certainly capable!).

It’s important to note that our reasons for choosing one framework from this list are extremely specific to this particular project at this time. Other use cases will have different needs, in which case the most appropriate framework may very well be a different one (perhaps even one that we haven’t listed here!). In any event: do your homework and pick the best tool for the job.

Conclusions

Ultimately, it was a really close call between Hapi and Express; we decided to go with Hapi.

Hapi’s minimal base system allows for a ton of modularity, notably through their use of plugins. Plus, we were able to get up and running with a minimal version of our current site within a week. Considering Hapi’s performance during the Node Black Friday event, it’s hard to find a more reliable and secure framework. Finally, during the week of creating a proof of concept, the entire Hapi team was incredibly easy to reach out to and get responses from; we know that if we run into any issues, we’ll get a response virtually instantly.

While we’re still bringing our second iteration of npm-www (lovingly referred to as newww) up to speed, it is out in the open and ready for your perusal. Architecturally, it’s quite a change from the original npm-www, but we hope that contributors old and new will find it easier to work with. Feel free to add issues, create pull requests, and reach out to us on IRC - we welcome your ideas and input!