Laurie Voss, co-founder and COO, npm, Inc.
January 3rd, 2018
|« Part 2: The React Ecosystem|
Part 3: Back-End Frameworks
The other clear pattern here is that Express is not nearly as big a part of the registry as it used to be. At one point, 1.5% of all npm downloads were Express. These days, it is one tenth of that at 0.15%. However, unlike Backbone and Flux, where the decline has been continuous, Express has leveled out and is now “flat” relative to the registry.
It’s worth having a visual reminder of what “flat” growth means in terms of the npm registry. Nearly all of the frameworks we’ve discussed so far are, in this graph of absolute downloads, increasing in popularity. Express, the top line, has grown 6000% since the beginning of 2013. The reason 6000% growth looks like a decline in the previous graph is that the registry itself grew 67,000% in the same time frame.
Front-end usage of npm is exploding
The other thing we can learn from comparing the “flat” growth of Express:
Before we dig further into that conclusion, let’s examine some more server side frameworks.
Other back-end frameworks
The next four biggest back end frameworks that we examined are all tiny relative to Express. They are:
Koa, shown here in blue, is a spiritual successor to Express, rewritten with a more cohesive set of design principles. While getting respectable usage, it’s not growing very quickly.
Hapi had a brief heyday in late 2014. This is coincidentally when npm switched its own website to use Hapi and blogged about that choice, so it’s possible npm’s endorsement had an effect. However, Hapi has since then been in decline, and npm’s own site is switching away from it as well.
Next.js is a relative newcomer, and significantly less popular than the other three discussed. Next uses a package name,
next, that it adopted from a former project. This makes its usage pattern a little confusing, so here we track its adoption only since Zeit, its inventor and corporate sponsor, took over the package. It’s showing some steady and increasing growth, and is worth checking out, especially since it uses React.
Back-end vs front-end in npm
We mentioned that front end developers now outnumber back end developers in surveys of npm users. Is that reflected in package usage?
It’s a difficult question to answer. It’s hard to classify many packages as being “front end” or “back end” packages, since many work in both contexts and are used enthusiastically in both. It’s impossible to programmatically classify a package as being front end or back end, and with over 600,000 packages in the npm registry, it’s not practical to survey them all manually.
This graph is an approximation using the combined popularity of the back end and front end frameworks we’ve already mentioned, combined and compared. But the story is more complex.
Historical front-end usage in npm
In 2013 and earlier, front end usage of npm was enormous, reflected by the popularity of Backbone. However, Backbone collapsed while Express and other server side frameworks continued to grow.
Tracking front-end usage of npm
To try and get a handle on what front end usage of npm looks like, we’re going to look at a bunch of libraries used to deliver front end code, including:
Here’s the usage of Webpack and Babel, with React included for scale.
However, in mid 2016, Webpack’s usage began to accelerate past React’s. This suggests that web developers have started adopting Webpack more generally for use in other contexts than just React apps.
A possible explanation for this can be found in the two tools’ design goals. Browserify brings the Node.js API surface (including shims for many back-end APIs) to the browser. Webpack is a more general module system and compilation tool, with affordances for loading images, CSS, and other front end resources. Thus, Webpack is more useful to developers who aren't “Node.js Devs.” As an increasing portion of the npm Registry has become primarily front end, Webpack has become an attractive choice.
RequireJS and SystemJS
Bower’s universe of modules wasn’t the only alternative to CommonJS. RequireJS, another alternative loader with its own module format, was quite popular in early 2013 but began to decline around the same time that Bower itself did. SystemJS, released in 2015, grew slowly until mid 2016 but never really got major traction. Mid-2016 is also when Webpack began to accelerate past React in popularity, so it’s likely that’s where SystemJS users migrated.
Webpack and Express
Currently, the most reliable proxy we have for front end usage of npm is probably Webpack by itself. Comparing it to Express, we see it climbing from nothing three years ago to half of Express’ formidable popularity.
A few years from now, npm may be considered primarily a front end tool.
Take us to work
Millions of developers at hundreds of thousands of companies depend on npm to discover, share, and reuse code to build amazing things.