Repository navigation
What goes in core / stdlib.js? #59
Description
Activity
here's one of my rants on the topic http://r.va.gg/2014/06/why-i-dont-use-nodes-core-stream-module.html
@rvagg great counter points -- I'm having trouble applying both those experiences into a cohesive philosophy -- it seems like we were (are) still trying to figure streams out, so they were a little too unstable to be in core. @rvagg while you seem to be more on the no-core side of things, where do you draw the line -- is it just at fundamental data types? are streams not data types and so this doesnt apply?
The lesson on "primitives" that we've learnt in the level* ecosystem is: a primitive is only a primitive if it can't be built outside of core ontop of existing core components. i.e. primitives exist only as a means to build additional features, if they are just nice-to-have then they are sugar and not a primitive. We expect the core to be only large enough to suppose those features absolutely needed and if you can construct a feature ontop of those features then it doesn't belong in core. For example, the
createWriteStream()we have in LevelUP is simply made up of a combination ofput()andbatch()operations, those are the primitives here and we've even found from experience that there are multiple ways to write a WriteStream for level* and the one you choose depends on your use-case (e.g. fast initial bulk loads vs ongoing slow writes, vs fstream-compatible writes, etc.). So we're pulling the WriteStream implementation out of core completely and letting userland decide how to best implement it.
In the case of Node.js streams, we can all pretty much agree that we've landed at a decent abstraction that makes for workable, composable code, but that doesn't make something a "primitive" by any means, even if everyone is using the same abstraction.Even if 99% of the WriteStreams used on top of LevelUP were the same library, it still wouldn't make sense to push it into the core. We keep core small so the innovation, experimentation, etc. can happen elsewhere. There's also nothing stopping people from bundling opinionated level* packages that have all of their favourite components already built in. Same goes for Node.js core.
Closing this in favor of #55 for the time being.
- added a commit that references this issue
on Apr 6, 2017
Given compatibility with existing node, everything from node core would go into io core.
Continuing from there...
I found @chrisdickinson's discussion on primitives really interesting. I'm curious what primitives the community perceives as general, distinct, and necessary.