Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What goes in core / stdlib.js? #59

Closed
kumavis opened this issue Dec 4, 2014 · 6 comments
Closed

What goes in core / stdlib.js? #59

kumavis opened this issue Dec 4, 2014 · 6 comments

Comments

@kumavis
Copy link

kumavis commented Dec 4, 2014

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.

@rvagg
Copy link
Member

rvagg commented Dec 4, 2014

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

@kumavis
Copy link
Author

kumavis commented Dec 9, 2014

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

@rvagg
Copy link
Member

rvagg commented Dec 10, 2014

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.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 10, 2014

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?

@chrisdickinson
Copy link
Contributor

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

@chrisdickinson
Copy link
Contributor

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

boingoing added a commit to boingoing/node that referenced this issue Apr 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants