npm Blog (Archive)

The npm blog has been discontinued.

Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog.

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:

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

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!