Front end devs are now big borrowers
Yesterday we looked at how build, borrow and buy decisions big and small are happening day in, day out in all software organisations, at every level of the stack.
More recently, front end development in particular has seen an explosion of open source usage, enabled by better language and community support for module dependency management, better build tooling, etc. This has impacted the way we develop front end products in a big way.
To illustrate this, here is a chart of weekly NPM package download numbers between 2013 and a few days ago, when NPM hit 8 billion weekly module downloads for the first time:
Holy **, right?!
On a personal level, I stopped spending > 50% of my time on coding activities in 2015. No wonder I already feel out of touch with modern dev approaches!
While NPM’s early work focused on supporting Node.js developers, their runaway success is almost entirely down to adoption by front end developers. Initially this was in the shape of build tooling, but increasingly NPM is also used for managing browser code dependencies, and is no longer limited to JavaScript either.
This a fundamental, important shift. Front end developers used to consume open source libraries in specific, deliberate ways. The libraries we used had few or no dependencies of their own. Once we’d adopted jQuery and a few third-party plugins to add a dreaded carousel, a date picker and a map, we were away. These dependencies were added and managed manually, with no build step, by downloading the source and including them as separate script tag references.
NPM has enabled a far more complex approach, with deep dependency nesting encouraging tiny, single-feature utilities. Only a fraction of those 8 billion module downloads every week are the result of deliberate, specific choices by individual product developers. That fractal of custom built vs imported extends all the way into your open source dependencies too.
Negotiating the open source landscape has become an important skill unto itself. This is a matter of ongoing curation: using personal taste, past experience and the context of the current work to select appropriate tools. Choosing a modern ‘framework’ like React doesn’t negate the need for curation. The wider React ‘ecosystem’ provides various competing libraries and tools that offer support, abstraction and additional capabilities.
Borrow has become the default position, and an important area of expertise, even though our build skills are still what we generally talk about and focus on developing. You’d be wise to recognise that this is not a temporary shift, and to adjust your approach accordingly.
Are product developers becoming assemblers rather than crafters? What impact has this giant shift to open source had on your organisation?
All the best,
– Jim
