What goes in core / stdlib.js? about node HOT 6 CLOSED

here's one of my rants on the topic http://r.va.gg/2014/06/why-i-dont-use-nodes-core-stream-module.html

from node.

@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?

from node.

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 of put() and batch() 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.

from node.

It doesn't seem like there is any action to take from this issue, and @rvagg's comment provides an excellent answer. Can this be closed?

from node.

@cjihrig I'm still working on a response, but we could probably move back over to #55.

from node.

Closing this in favor of #55 for the time being.

from node.