So event-stream was of that era. I went on to write a huge number of stream-related modules, and event-stream was actually the very first one that I wrote. I wrote it, and then after about 11 months of stream experience, I realized that event-stream was kind of the wrong basis, and I wrote a thing called Through, which became the basis for all of my streams stuff after that. So even by that point - that was six years ago - I had basically moved on from event-stream; I wasn’t really interested in – I wasn’t using it as my first go-to thing for writing streams anymore.

Then another year or two after that the Node core team had decided they were gonna fix all the problems with Streams and create Streams 2. I hadn’t managed to participate in any of these discussions on what was gonna go in Streams 2; it was all at this Node conference in California, and I wasn’t there… And when I saw what they wanted to add, I was like “This is horribly bloated and ugly.” But it was also backwards-compatible, which made it twice as bad. I tried some mild protesting, and they were just like “We’ve already decided, this is how we’re gonna do it.”

That sort of spurred me to be like “Well, if you’re gonna really make a really minimal efficient stream thing that wasn’t backwards-compatible with the current streams, what would it look like?” I started experimenting - me and some friends - and came out with pull-stream. Pull-stream is really minimal – you just have two functions; one function is just a normal Node async function, and you call it repeatedly, one at a time. So you have a readable function. And then you have a reader function, which is a function that the readable was passed to. I’ve got detailed blog posts about both the history of Node.js streams and pull-stream, so you can go through them at dominictarr.com.

[ ] Pull-stream was like – I decided this was actually so much better and solved several of the problems that node streams had, like error propagation… So if the error occurs somewhere in the stream, it cleans up and aborts the whole stream, and you know that the stream ended in error… Or just move data about, like you did with event-stream. It was just much more minimal and lightweight and efficient, and benchmarked that it was faster, and stuff like this… Even though I hadn’t really tried to optimize it, I had just written all this code… So I had fully moved on by that point. It was like “This thing is great.” And I’ve really tried to promote pull-streams.

Some people caught on and there’s a pretty good community of people that use it… But anyway, by the time – that was also several years ago, so I had completely moved on from event-stream like twice.