(Basically, I am finally getting around to actually writing that specification for my JS streams design - they're streams that don't suck, and that can be parallelized safely, and that have well-defined termination behaviour, and that can interoperate with all existing types of streams, and...)
For those who are curious, here's a work-in-progress draft of the spec so far: https://gist.github.com/joepie91/9ced67203070051be70c2ae0cd644a30
@joepie91 sounds interesting.
at the moment i use the dependencyless
https://github.com/mafintosh/streamx/blob/master/index.js
would love to see a comparison and benchmarks once you have it 🙂
@serapath That looks like it's based on Node streams - the awfulness of Node streams was very specifically why this project originally started :p
The system I'm working on is quite different in a lot of ways - for starters, it's pull-based rather than push-based (which makes for better backpressure control, among other things) and it doesn't require special inheritance trickery to use; the design is more of an iteration of pull-streams, but with native Promises support and an actual solution to parallelism (which streamx doesn't seem to have?)
@serapath Notably though, performance is not my #1 goal; I'm prioritizing ergonomics and reliability above that. It should Just Work reliably as essentially a multiple-value counterpart to Promises, and be similarly trivial to use
@joepie91 alright. definitly curious to see 🙂
They're also environment-agnostic; they require zero special runtime features (not even ES6 Promises, any A+ implementation is fine!), and are realistically implementable from scratch (and from spec) even in a library-less environment - all you need are a bunch of object literals with 3 functions each that have some defined behaviours, basically - the system as a whole is just emergent from those properties