Is Node.js missing its batteries
Node.js's package ecosystem, npm, is the largest ecosystem of open source libraries in the world
The corollary is that we are in a position to reflect on the platforms strengths and weaknesses as experienced to date. In this post, I ask whether the platform's reliance on an ecosystem of open source libraries without the inclusion of a significant standard library is a risk for adopters. Languages such as Python make a virtue of a large standard library, describing the language as batteries included. Is Node.js missing its batteries?
Node.js has tested the workability of development away from a comprehensive standard library. The obvious comparisons are Java's immense standard library, and Python's stated goal of ensuring a batteries included language. What are the consequences of this point of difference?
I believe that we can examine the consequences by thinking through what happens when a developer requires functionality that is missing from the standard library. There are two obvious choices: a project may either create an internal implementation, or depend on an external package from the ecosystem. Each choice brings risks that are often avoided in projects that enjoy a large, well-engineered standard library, and the choosing must be repeated for each piece of missing functionality. Consider the two choices separately.
When a project chooses to create an internal implementation, it undertakes to relearn the lessons of a standard library in the context of the project. Solutions in a standard library embody careful compromise tested by diverse projects. When these solutions are rebuilt in a project, much has to be relearned. Worse still the lessons must be relearned in the code that affects the largest part of the remainder, where every change cause the greatest disruption. One symptom is contention in the code, as each lesson relearned triggers changes and refactoring that must be resolved before new features can be added. Another problem is what Sam Newman terms the perils of shared code. Since other projects in the organisation would likely benefit from the same code, the temptation is to create a shared package. Then the projects depend on an external package.
When a project chooses to depend on an external package, it takes on the risk embodied in the external package and must navigate the inter-dependencies between packages. The standard library represents certain guarantees that are difficult to meet in the context of lone packages. The project is now hostage to the governance and life cycle of the external package. Will the package still be supported by its developers over the lifetime of the project? Another problem is dependency hell. Since each package can depend on other packages, and each such dependency can demand a specific version, it can be incredibly difficult to resolve the dependencies to the satisfaction of the version constraints. A comprehensive standard library goes a long way to quenching dependency hell because the standard library is a large single object at a single version number that has been carefully engineered for compatibility between versions.
Love this story? Subscribe to the Syntegrity Solutions newsletter here and get them delivered to your inbox every month.
Andrew Burrow is a Senior Consultant at Syntegrity Solutions, a specialist IT consultancy that focuses on digital innovation enablement. He brings a philosophical bent to his IT practice. He’s both a big picture man and a devil when it comes to locking down the details – and we think that makes him a natural when it comes to integration work.