it is nowhere near the point of adoption that it can always be relied upon.
Make Node.js Core Bigger
Mikeal
1135

Abstract Blob Storage may be “standard” but it is also not necessary the best solution.

For example: It is not possible to implement the full API for crate.io because the key in crate needs to be equal to the SHA hash of the file. This is an implementation chosen to ensure that all the data intended to send to the server was also received correctly and to be make sharding and concurrency more effective.

Those features that are missing in the Abstract Blob Store API and as such Abstract Blob Store might not be the best solution for me.

(Note: I asked for a more flexible implementation: https://github.com/crate/crate/issues/2981#issuecomment-260221917)


About the small core

I have had the honor to talk with James Snell in person about his attempt to add http/2 to the Node core. I see two cases in which adding should be considered:

1. Better Node Core

The libraries in core have cross dependencies that allow Node to run: http needs the crypto library. the fs api is required for loading script files, the streams for fs & http, os for error and process handling,… etc. All those libraries are essential to run node itself.

Technologies that further improve usability of node core should be an exception and considered for inclusion.

Example: If node decides to have colored CLI output, then a lib to handle colors might be worth adding. (example: off the top of my hat).

Reasoning: Not trying to improve Node Core — not trying to make the CLI, debugging, runtime better — seems like a recipe for failure. Once new code for improvement is written & shipped, then it would make a lot of sense for the users of Node to be able to use it and not to need to install yet another implementation of the same logic already present in core.

Concession: Not all code in core is mature, or flexible, enough to expose to the public. Simply exposing every code would be the wrong way to go.

2. Better NPM

Without http & fs, npm would be hard to get running. NPM is shipped with node and a crucial part of what I would call “the node experience”. In order for NPM to do a better job it might need better tools from Node.

If NPM needs implementations of standards that are currently missing it should be an exception and APIs that improve that considered to become
Node core API.

Example: http/2 would make NPM faster (likely). Instead of NPM implementing (and shipping) a http/2 implementation, Node could directly implement & provide a http/2 API.

Reasoning: I understand that maintaining code costs resources and spending those resources for NPM — owned by NPM inc. — keeps the ownership of it. (Which I am totally fine with) But — like http/2 — it seems strange that NPM comes should come up with a solid, good solution for tar/untar that is not part of core. If you are worried about the cost aspect then get NPM inc. to help maintain those new parts of Node core. Having those libraries in Node core would ensure, probably improve, the quality of the delivered Node version.

Concession: I understand that versioning is a problem here. i.e. old versions of NPM need to run on new versions of node and vice-versa. Adaption obviously can only come slowly and with fallbacks. Thus any new API would need to be a long-term goal to improve the Node.js platform. 
I also remembered that npm only needs a subset of “common functionality” in order to get Node Core running. Turning those subsets into general API’s might be a bad idea.

… Apart from that

I am happy over the way how Node keeps its core small. I think its an awesome strategy that is laudable. Thanks for bringing awareness to this topic!

Like what you read? Give Martin Heidegger a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.