← Software Engineering Daily
Software Engineering Daily
RxJS with Ben Lesh
00:50:29
RxJS is an open-source library for composing asynchronous and event-based programs. It provides powerful operators for transforming, filtering, combining, and managing streams of data, from user input and web requests to real-time updates.
Loading summary
Transcript74 lines
- [00:01]
Ben Lesh
RXJS is an open source library for composing asynchronous and event based programs. It provides powerful operators for transforming, filtering, combining and managing streams of data from user input and web requests to real time updates. Ben Lesh is the creator of rxjs. He joins Josh Goldberg to talk about his path into engineering and the RXJS library. This episode is hosted by Josh Goldberg, an independent full time open source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES Slint, the tooling that enables ES Slint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube and dot com as JoshUakGoldberg.
- [01:10]
Josh Goldberg
Ben Lesh welcome to Software Engineering Daily.
- [01:13]
Ben Lesh
Hey, thanks for having me. I haven't seen you in a while.
- [01:15]
Josh Goldberg
Yeah, it's been a bit. I'm excited to talk to you. You've been doing a lot of really interesting stuff around observables and RXJs. But before we get into all that, can you tell us, how did you get into coding?
- [01:25]
Ben Lesh
Well, let's see. I had been doing like little basic programming stuff when I was a kid, but then I went to art school, dropped out of art school after about three years and was working doing graphic design work at Ohio State University. Working there. I was not going to school there. There was a situation where someone was working on a website or whatever and I was curious about it and I thought I could fix something or work on it. And basically I learned how to do like some basic HTML and JavaScript stuff. And I had a friend that was like, dude, do you know how much more money you can make doing this? I was like, really? So at the time there was no Google, there was no stack overflow, none of that. I basically loitered in Barnes and Noble and read books because that was the only way to get recent information. Like they weren't at the library or anything. You know, practice doing stuff on my little compact Presario. Eventually I got my first programming gig. It was, there was an ad they were trying to hire somebody for. It was like 80 bucks an hour or something like that for four hours a day. I had to call them over and over and over again because they were not calling me back because I wasn't qualified for what they were looking for. And they finally brought me in, they asked me some questions. I got probably half of them right and they were like so you know what we're going to ask. I was like, do you think you're qualified for this? And I was like, well no, but I really think I can do what you need done and I'm willing to learn and I'll work for $10 an hour. So if I work for two days and you don't like me, then you've only paid me for what you're going to pay somebody else for one hour. And you could probably even still hire that person if you wanted. They liked that answer and I got the job and it was a one month contract, which is I think why it was open for so long. And they kept me for like three months or something like that and they gave me a letter of recommendation because I asked for one. And after that it was, you know, I got other programming jobs in the pay was higher and everything.
- [03:20]
Josh Goldberg
So that's a fascinating interview technique to offer to undersell.
- [03:25]
Ben Lesh
Yeah, I mean you can get away with it when you're. How old was I? I was 20, I think. 19. 20.
- [03:32]
Josh Goldberg
So, so what tech stack was that? And I, I'm just curious.
- [03:36]
Ben Lesh
The first gig actually was a lot of HTML and JavaScript. So the JavaScript was funny. The very first thing I had to write was they wanted. People don't remember this probably, but there's a thing, it still exists. If you get into any browser and say window status, there's just an empty. And there used to be this property in window you could set called window status and you set it to any string and you know when you hover over a link modern times, it shows like a little like the URL underneath, like on the bottom of the whole page that was the status bar. And you used to be able to set that manually with window status. And they, they stopped allowing people to do that because it was a, it was a way that you could be like, aha, you're going to click on this link. And it's not actually the link because someone was setting it. It was like a security hole. But what I was tasked with doing was making like a little ticker that played in that window status of all the deals that were going on in this E commerce site that day. So that's set interval. I learned about setinterval there. That was the first time I ever used set interval and I had to slice a string and make it tick along and continuously wrap. And that was the first professional problem I ever solved.
- [04:47]
Josh Goldberg
Just getting a ticker at the bottom of the page with a now deprecated API Right, yeah.
- [04:51]
Ben Lesh
But you can get the string off of it if you want. The empty string is still there.
- [04:56]
Josh Goldberg
That's kind of representative of what you're known for in the web community. Now you're doing some sort of timing, some sort of streaming Data shenanigans in JavaScript with bizarre APIs. How did you go from that to working on libraries like rxjs?
- [05:09]
Ben Lesh
Oh, boy. It's a long. It's a long path. After that job, I was doing like Visual Basic programming and ASP Classic they would call it now, but at the time it was just ASP. Got into doing. Net development, did that for 10 years. And the reason I got into JavaScript development was around the time Angular was new, we were trying to build. I was working at a company, they were doing pharmaceutical robotics, and they were trying to build like this client that was very rich in features. There was this belief amongst software engineers at the time that JavaScript was a joke. It was a joke language. You could never make good money doing that. It was not the work that you wanted to land on. And I was like, all right, I'm the senior. At the time, I was the senior engineer on that team. And I'm like, that's fine, I'll do this work, I don't care. And this was back when you had to concatenate your JavaScript files yourself and all these other things. There's like, you had to basically build your own build tools. So that's kind of how I got into it. And I had to answer a bunch of questions on Stack Overflow about Angular to learn things about Angular, So I'd find ones I didn't know the answer to figure out the answer and answer. Just so happens that that meant that I was one of the top answers on Stack Overflow and someone at Netflix was building something with Angular or trying to build something with Angular, and they saw my name over and over and over again and they said, hey, why don't we see if we can get this guy to come work for us? And I thought it was a joke. I got this email from Netflix and I thought it was one of my friends screwing with me like that Netflix was like, hey, just randomly reaching out to you to see if you're interested in working for us kind of thing. Right? Like, I didn't apply. And so I went and I was like, all right, I'm going to go to this interview, I'm going to have a phone conversation. That's what I thought. And I had a phone conversation with this person. I was Very honest with them about, you know, my level of ability or whatever. And they were like, well, great, we'll have you come out. And I'm like, okay, cool. So I've never been to California. Living in Pennsylvania at the time, I mostly spent time in Ohio, Michigan, Pennsylvania. I was like, okay, so I get a free trip to California and you know, that's, that's probably all this is going to amount to. I'll get a little tour of Netflix. That'll be awesome. Then the next thing you know, the. One of the. I think the VP of engineering or somebody was walking me out to the front door, like talking positive. I'm like, okay, so I'm going to get an offer, but there's no way it's going to be enough to get my family to move to the most expensive place in America to live. And then it was. So I ended up at Netflix and at Netflix, this is a really long story. I told you, like, we're going to get to the RXJS thing. At Netflix was my first introduction to rxjs. I'd never seen it before and I started using it for some things as I started to understand it better and was working on real time streaming dashboards. So Netflix RxJS really helped with memory management in this really busy streaming dashboards of charts and things and of course the updating streams and all of that. There was a feature that we needed. It was a re, I think retry when. So I added that feature through open source. And I had also done a lot of work in open source on the Angular code base at the time too, even though I was working in Ember at Netflix, which is funny. Yeah. So since I had a lot of open source experience, I was approached by Jafar Hussain, who worked at Netflix at the time, and Eric Meyer, the guy who invented Observables, and this guy named Ben Christensen who worked on RxJava who worked down the aisle for me. And they came over and they said, hey, we want to talk to you. And they said they wanted me to work on RxJS to rewrite it. And I told them I was not qualified and I told them they should give them a list of other people they should pick. And they were insistent because of my open source experience. And so the rest is stuff that people know, I think. But yeah, that was 11 years ago almost now. So. Yeah.
- [08:55]
Josh Goldberg
Wow. On the reactive dash extensions, RxJS, GitHub, we see issue number 482 and pull request number 486 from. Yeah, over a decade ago. That's incredible. I also love that you've now used another interesting technique, Stack Overflow, as a form of development, that a lot of this was started in part by you finding questions you did not know the answer to and answering them. That's a powerful technique.
- [09:21]
Ben Lesh
Yeah, well, I mean, what I tell people, you know, I don't know that you could still use Stack Overflow for that now. But, like, what people should do if they want to make it somewhere is be conspicuously helpful. And right now, the climate's pretty weird. Right now I feel like all of the really popular developers are these like kind of loud, bombastic people on YouTube or whatever. Like, they're not. I wouldn't classify them as being helpful all the time. Like, sometimes they're the opposite of that, I think. But there are. Some of the information they give out is helpful and giving information to people in general is helpful. I guess so. But I think that being conspicuously helpful, either in your own community, giving talks, writing blog articles like, whatever you can do, or just answering people's questions and being kind and nice and that sort of thing, like, is really a pathway to success. Like, you're going to be a lot luckier in your career if everyone knows that you know things and everyone thinks that you're useful and helpful than if you just sit and be quiet and keep your head down and that sort of thing. So in Stack Overflow, that was. It wasn't intentional on my part. It was more just like, I want to be helpful and I want to learn the answer to this question. So therefore I'm picking out interesting questions and seeing if I can figure out the answer.
- [10:35]
Josh Goldberg
We're going to talk about RXJs, but I have to agree with you for a brief moment that there's this kind of growing area of developers who are technical, who create content, you know, content creators. And it's a very different thing to be a great content creator versus a great, let's say, contributor. A lot of overlap, a lot of people who do both, but it is two, you know, similar areas. Similar to how Front End and Full Stack are similar areas. And it can be hard, I think, for people to. To understand when someone is speaking as a content creator just to spread information versus educating them, you know, helping best practices get spread or even evolved.
- [11:10]
Ben Lesh
There's a monetary, a heavy monetary component to the content creation thing too. Right? Like, there's. It's not just people out there, like, I'm curious and I want to be helpful, therefore I'm out there doing things and you know, ideally I get rewarded in some way by my getting a better job or something at some point. But like, these are folks literally like making money off of the number of views they get for things, which is, It's a different kind of incentive. Like it's. It's not. There's probably less incentive to be helpful anyways. Like unless the helpfulness is the reason people are showing up to your channel, I suppose. But I'm a little bit cynical about it. I have children. I've watched my children's brains rot watching weird short things on YouTube. I hear the word YouTube and I just like, I shudder a little bit, like. But you know, it's just because I'm. I think I'm just getting old and cranky when it comes to that sort of thing.
- [12:05]
Josh Goldberg
So, yeah, holding cranky, he says with a happy smile and laughter, let's simulate stack overflow for a bit. The heyday of stack overflow. I'd like to ask you a few questions. To start, let's say that you find someone has asked, what is rxjs and why would I want to use it? How would you answer a question like that?
- [12:22]
Ben Lesh
Oh boy. Well, I mean, first of all, I know the answer to that question, but like, I would probably just start off with, you look at that thing and you're like, all right, so most people don't want a whole book, or they do want the book, but they need the summary. So you start off with some bullet points. Like RXJS is about streaming data. RXJS is the opposite of iterables. Like RXJS is a cancellable asynchronous type for 0 to n values. And you can just start off with those simple bullet points and then dive deeper into what each one of those things actually means. Like, what is asynchronous data? How is it the opposite of iterables? Why is cancellation important? Those sorts of things, you can come up with something that might take somebody a couple hours to read if you really wanted to get into the whole details of it. But the important thing is that people get the very, very high level bits of it and why they would reach for that particular type or push versus pull and some of these other things.
- [13:24]
Josh Goldberg
Yeah, that's a great segue. The next question is, I've heard of these things that RXJS sounds like, but I don't understand the difference. What is the difference between an iterable and something that's provided by RxJS?
- [13:36]
Ben Lesh
Oh, okay. Well, so an iterable we use Those all the time. So if you use a for of loop, that's using an iterable. So you've got this. And I know you know this, but this is obviously simulated. But. But yeah, an iterable. If you use a for of loop, what it's doing is it's taking the object on the right side of that of and it's saying, hey, give me your iterator. And it calls the symbol dot ITERATOR thing. This iterator comes out and all the iterator is, is just an object basically with a next method on it. And for every loop through, it calls next and it gets back a result that says it has a value and says whether or not it's done, if it's done, the loop stops. If it's not done, it takes the value and goes into the loop. What you're doing then is you're pulling values out when you iterate. So you, as the consumer, the person that wants the data is saying, oh, I'm gonna do something. Okay, give me the next one. You pull it out and then you say, I want some data. And you say, okay, give me the next one, you pull it out. Now, an observable is exactly the opposite of that where you subscribe and you give it a function that is your next and it calls your function when it has the next value. So instead of you, the producer saying, oh, or the consumer saying, I'm gonna do something, I'm ready, give me the next value, you're saying, I'm waiting for you to give me a value and I will do something with it when you give it to me.
- [14:51]
Josh Goldberg
So.
- [14:51]
Ben Lesh
So that's more like an event. So any sort of event that you might have, like click events or mouse movements or even getting a HTTP back or something like that, those are all mod can be modeled as an observable. So that's the main difference is one is you're pulling values out and the other one's pushing values at you.
- [15:11]
Josh Goldberg
That push versus pull description makes a lot of sense, I think. And for anyone who has extra time, I think you gave a fantastic talk on this@revo JS 2023 on pushing and pulling in JavaScript. Another topic that comes up a lot in the context of pushing and pulling is observables. Now, you've been working on observables. Can you just define for us what does it mean to work on an observable or even what an observable is?
- [15:34]
Ben Lesh
Okay, well, observables were the original kind of team that Created this was at Microsoft under Eric Meyer. And literally they went at it from an academic standpoint and were like, what if we took an iterable and pulled it inside out, like made the dual of it, if you will, and made this pull based type, the iterable into this push based type observable. That's kind of how it started. Or another way to go about it is if you've ever seen the observer pattern, which people don't realize, but they use it all the time. So the observer pattern, there's two things. There's a subject and there's an observer. And the subject is shaped like add observer, remove observer and notify. Those are like the three things on a subject. And it does what you would think where the observer then has like a notify on it. That's all it has. And you take this, you take this observer, you give it to the subject, and then the subject, when, by adding it or whatever, the subject, whenever is notified, will notify all the observers of that subject. Right. And so it starts with that. But there's kind of a missing piece in here where you can kind of functionally chain any subject to any observer by like kind of chaining them together. And the way you do that actually is with observables. People don't often think about it, but an observable, really what it is is you have this type that when you subscribe to it, it executes a function internally and says, hey, create a producer. Here is this observer for you to next values into or call next on whenever you get a value or call error complete or whatever. But we'll just focus on the next part of it. And what happens is when you subscribe, it calls that function, creates the producer. That producer starts nexting values. And then when you unsubscribe, there's some teardown logic that you've registered in there that will say, oh, I know how to tear this down. It's a websocket. You might close it. If it's a mutation observer or whatever, you might disconnect it, like that sort of thing. So it's a really, really, really simplified type. The observable itself in its raw form, it exists in every single language that exists as far as I'm aware of, well, every Turing complete programming language anyway. There's not one in like CSS or something. But it's really, really, really simplified type. And it's used for a great number of things, which is why it's being moved or been put through standards bodies. And it's being now added to the browser.
- [18:00]
Josh Goldberg
That's a fascinating process that I think would be interesting to walk through because for a very long time, as you said, this was just a common practice in a lot of libraries. And RXJS is to many understanding the most common, the very popular way to.
- [18:13]
Ben Lesh
Do observables APIs are the foundation of reliable AI and reliable APIs start with Postman. Trusted by 98% of the Fortune 500, Postman is the platform that helps over.
- [18:25]
Josh Goldberg
40 million developers build and scale the APIs behind their most critical business workflows.
- [18:30]
Ben Lesh
With Postman, teams get centralized access to.
- [18:33]
Josh Goldberg
The latest LLMs and APIs, MCP support.
- [18:35]
Ben Lesh
And no code workflows all in one.
- [18:37]
Josh Goldberg
Platform core quickly integrate critical tools and.
- [18:40]
Ben Lesh
Build multi step agents without writing a.
- [18:42]
Josh Goldberg
Single line of code. Start building smarter, more reliable agents today.
- [18:46]
Ben Lesh
Visit postman.comsed to learn more.
- [18:50]
Josh Goldberg
So what is it about observables that you think has made it so that people not just want to do it, but want to standardize it in the web altogether?
- [18:58]
Ben Lesh
I think the most powerful thing about it, there's several powerful things about it. But one of the things that's interesting for folks is if you've got an iterable. An iterable is a set of things as we know. It's like an array can be an iterable, a number of different things can be an iterable. So an iterable is a set of things. And if you have an observable, it's also a set of things, but it's a set of things over time. But what's true about sets of things is let's just say you have a basket. A basket can contain a set of things. If you have a container for a set of things like an observable or an iterable or a basket. You can take a basket of apples and create a basket of sliced apples by putting it through some mapping process of slicing it, right? You can, you can take a basket of apples and make a basket of not rotten apples by filtering out all of the rotten apples. You can do the same thing. Obviously arrays and iterables have map and filter flatmap and these other operations. All of those same operations exist on observables, but the difference is the observables are events. So now all of a sudden you can take events and coordinate them together with these same sort of operations you would use on, you know, these static synchronous sets. So that's the biggest thing, I think, that attracts people to it initially. Now what I also know is, and this is one of the reasons we liked it at Netflix, was it also has this very deterministic teardown feature where when you're not subscribing it tears everything down. Like if you chain a whole bunch of other stuff together, it will automatically tear everything down. If you have a retry, it will tear everything down and stand it all back up again. Like, and you have this deterministic kind of memory management that gets really, really hard when you're manually coding events together where you might have to be like, oh, if I get this, then I have to subscribe to this, I have to start this websocket. When I get this message, I have to send this HTTP request or whatever. Like all of those things, if they're mid flight, become very difficult to make sure that you get all of those things torn down appropriately if you're manually writing it. Where if they're all wrapped in observables, it's almost like having a finely block in every bit of your code to make sure that things are being torn down.
- [21:04]
Josh Goldberg
Yeah, I can see why that would make for a much cleaner code both to write and read. Using the example you brought up of your very first experience, little ticker at the bottom that kind of brings up a lot of the concepts of observables and piping through. Right. Where you need to start something, you need to update on an interval, you have constant actions and then at some point you might want to dispose of.
- [21:22]
Ben Lesh
It or start it back over again. Like repeated or whatever. Yeah, now easier to read. That's in the eye of the beholder, as with all code. But so RCS does have a bad name to some folks. And the reason is honestly, async programming is really hard. Like there's no way around it. Like you're taking like synchronous programming with iterables or anything else you're doing. If this, then this, if this, then this. And you can read it top to bottom, left to right, no problem. Asynchronous programming, even with for await, you go down, you get to an await statement and it goes off into the universe like it's not on your page of code anymore. It could be doing literally anything at that point. You could be awaiting a message coming from Saturn. Like there's who knows what what that's doing and it could fail or not fail. So every single bit of asynchronous code, it goes off to some Schrodinger's cat problem and then comes back and Then you continue on your way and you can even do something where you do asynchronous code. It makes a call out. And since you've left that synchronous code block, you can become reentrant, where that call out actually comes back into the top of the same function. So if you've got any shared state, you've got an issue. And that's not a problem that's unique to rxjs. However, rxjs makes asynchronous work so easy that people create those problems, I think, easier because they're, they're doing more asynchronous stuff, a smaller amount of space, and then they build more complex asynchronous things. And yeah, it's, it's, it becomes difficult. And then the other thing is, if you don't understand what a flat map is, you know you're going to have a hard time. It's something I hear fewer complaints about people who don't do or don't understand the operators anymore because it's been around so long and I think a lot of people have exposure to it now. But that's not to say that I haven't seen some absolutely abhorrent code where people were using RXJs for things that they should not be using it for. The completely synchronous things, they'll be like, yeah, let's just wrap this in observables. And you're like, no, dude, this is just. You're going over arrays. Just do erase stuff, you'll be fine. You made one request to one HTTP endpoint. It's okay if you don't cancel it when you're no longer using it. It'll just come back and yeah, it'll eat some resources for a second, but it's probably not the end of the world. There's a give and take there.
- [23:41]
Josh Goldberg
How do I know whether the app I'm working on is a suitable candidate for updating to RXJS or upgrading?
- [23:47]
Ben Lesh
So observables, and let's just talk about observable itself. Not all the operators, just observables. Observables are good candidates for anything where you get more than one value or maybe no values, synchronous or asynchronous, it doesn't matter. So if they're a good candidate for things where you could get no values, you could get multiple values, asynchronous, usually, ideally. And then the other thing they're good for is cancellation. So promises have no cancellation. If you have a promise in flight it must resolve or reject. You can't just be like, oh, this is done now. And if you have it resolved with null, so it's not annoying, then you've got to handle that null every single place that you could be using that promise, therefore you have to reject it. But now you have this error that you have to handle and you have to look and be like, is this an abort error or is it like an actual error? And then you have to handle it appropriately. So promises, they're not truly cancelable without a lot of annoying steps. And observables don't have that problem. Observables are more like, this is a push based type. You cancel it, it's done. Like it just silence, it tears everything down, finalizes itself or whatever it needs to do and carries on with life. So anything where you need some sort of cancellation observables are really, really good for that. And of course things with zero to n values now then you get into the operators and stuff. And if you're doing a lot of coordination of events, like say you've got two streams of data coming in and you have to make sure that they line up. Observables are really, really good at that because we have these operators where they can like RXJS has zip, they can zip things together. Or you can take a stream of data and you can like switch another stream of data to a different stream of data every single time. Like it's really, really good at event coordination. But if you don't have a lot of events to coordinate, like, and you don't have any cancellation, it's probably okay. You don't really need to use observables.
- [25:41]
Josh Goldberg
For my little app that renders a chart when I click a button, might not need it, but like your rich data vis platform or your Netflix Dashboard perhaps would be a better candidate.
- [25:51]
Ben Lesh
Yeah, for sure, for sure. Even if it's not a real time updating dashboard, if you're in a situation where you're like, look, I just kicked off 12 network requests and when they come back they're all going to do something heavy like try to update a chart. I know that the user might click away and unmount all those things, you probably want to make sure that those 12 network requests are cancelable. And that doesn't mean like you're going to tell the server to not respond. It just means you want to tell the browser, hey, this fetch here is done or this XHR is aborted. Like, do not do anything with this. Like, don't Even attempt to parse it or read the headers or anything, just forget it. Because you've got one thread in web development, so it can get a little heavy if the app is busy enough. Sure.
- [26:40]
Josh Goldberg
Which is, by the way, a thing that I think a lot of web developers don't pick up on, because most of the time we have no need for this. You can abort fetch requests, xml, HTTP requests in the standard dom. That's actually a feature.
- [26:53]
Ben Lesh
Yeah, yeah, yeah. So for a while, the fetch for a while did not have abort. They added abort signals for that purpose. But XHR always had an abort. It always had one. So the XHR was the only cancelable way to make one of these requests. And it does have impact. If you. Again, if you're making a bunch of requests, there's a difference between saying, oh, it came back, forget it, like you would do with the old fetch before a board existed, and abort, like, just stop. Because one is still going to do a bunch of work before it gets to your code and you can tell it to drop it. And it'll have put things in memory that need to be garbage collected on the same thread. It'll have done a bunch of processing on the same thread, probably done some JSON parsing, which is slow as dirt on the same thread. So it's not ideal. But in most cases, like you said, it doesn't matter. It's fine in most cases. It's not like a big deal. But then anywhere that I'm going to be working where I'm working on something that's got more intense problems than make one call, load a list of stuff on a page. Yeah, they probably need cancellation or some other nicer mechanisms for handling that sort of stuff.
- [28:02]
Josh Goldberg
I'm going to want to talk about the future of RXJs. But before you, I can't resist gloating or expressing glee over the operators page in the RXJS docs. You have a very lovely website, rxjs.dev with a guide that goes over all sorts of articles and information and like full docs on all the things you can get from rxjs. And honestly, very well written. Like a lot of the pages, especially the subscription page, I found to be very useful.
- [28:27]
Ben Lesh
But.
- [28:28]
Josh Goldberg
But the operators page is one of the biggest lists of just all these different functions. And there's AJAX and bind callback and bindle callback. And it kind of makes sense what's stated in the front page. The introduction RxJS of think of RXJS as Lodash for events. You have every possible conceivable kind of event handler in there. Do you have thoughts on the plethora of stuff provided by rxjs or events?
- [28:52]
Ben Lesh
I. I don't like most of them, no, because. All right, so I inherited this. This is. RxJS is not my creation. RxJS started at Microsoft and was actually. This is the truth, was actually it was written as a build target for Microsoft Project Volta, which predates Typescript by a bit. And the idea there was you write stuff in C and then compile it. You write. Net code and you compile it to JavaScript. They needed build targets for rx. Net, which was very popular at the time. So RXJS was up there. They had things like, what is it, the same thread scheduler and stuff. And it's like, well, there's only one thread. What are you talking about? They had all this other. These weird names for things. And it was very much because it was a build target for that. It came from this compiled language where it didn't matter how many methods there were on something because the compiler would remove everything you didn't use right to JavaScript land, where the versions of RXJS before what I worked on, it would just be like, all of these operators are on prototype for observable and therefore you get all of them. Boom. The bundle is now this big. So that was one of the things that we had changed. But every operator you see there, window, window, window, when window time, all these different window things, which I've never seen anyone use, I don't think those all came from this, this original implement implementation. I'll be dead honest. Like, I don't even think I could name all the operators if I had to. Like, I'd be. I'd be closer than a lot of people, but I think I'd miss a few. I think that I could get by with probably 10 to 12 of them. Realistically, out of a list of like 80 or however many there are. So that's what I think about it. I am happy that what's being offered in the browser is a more minimalist but important list of things. Rxjs will still be necessary for people to really get the full power of observables, I think, until I can convince them to add just a couple more features. But yeah, that's when I see that huge list. I just think if I could get away with it, and I can't because it's so widely used, I would slowly trim away at a lot of these things, and I have to some degree, but there's just, I mean, there's only so many ways that you can write Window Win. So it's there. It doesn't need a lot of maintenance. Will it be in future versions? If I have to rewrite RXJS for this new observable for the platform? Will Window when be there? Probably not. But that doesn't mean the previous version of RXJS won't still be actively maintained because there's so many people using it. So.
- [31:35]
Josh Goldberg
Tbd on whether every single one of them will.
- [31:39]
Ben Lesh
I'm sure I'll get people that are real excited to contribute that want to add it, but whether or not they can prove to me that we actually need it out in the world, like, yeah, the most telling thing is when I worked at Google, I could look through hundreds of thousands of build targets that used RXJs and see what they actually used. And so I know which ones are used and which ones aren't used that often. And some of these people are like, were RXJs nuts? Like, they were so crazy to use RXJs for things? So they tried to use like all the operators. The window one I'm picking out in particular because I recall no one using Window out of all of that. So they use Buffer, they use all the different buffers and all these different things. They use every other operator. But I remember Window in particular. I didn't find too many instances of at the time.
- [32:27]
Josh Goldberg
Is there an operator called InstanceOf wondering if that's an accidental pun you made. There's observable instance in the docs. Okay, but no, let's talk about this actually for some time. I remember on, you know, social media there is a small push to try to get observables built into JavaScript through TC39. That's not what's currently happening, but it's still, still happening in some form. What's going on with observables?
- [32:51]
Ben Lesh
Right, so observables are being standardized through the W3C, the whatwig added to the browser, and they're being added to the browser in that anything that's in event target, so like buttons or anything where there's add event listener, remove event listener will now have a when method on it and you can say when click and it will give you an observable of clicks. And the advantage to using setobservable of clicks is when you subscribe to it n times it only really actually adds one listener. So it's multicasting that. So the observables for the, for the web platform are a little bit different than the ones for RXJs in that they are multicast by default, which means they're reference counted. Like if you have a bunch of subscribers to it and it'll wait for all of them to unsubscribe before it removes that event listener. So it's very useful for that. It's going to be useful for a variety of other things. Like you can then do like the whole the classic idiomatic ARCS JS example of like when you mouse down on this thing, you take all of the mouse movements until there's a mouse up, right? And you can now create some draggable elements or some movable thing or you can draw on a canvas or whatever you want to do with that information. But that's the sort of use case that it has built in. And then of course it has the type where you can create your own observable. It's got all of the important operators on it, it's got map and filter and these things. So that's kind of how it's landed. And that is the result of about 10 years ago it was in a TC39 proposal that stalled and the idea was put forth that well, there's no, we need a use case to add this thing to JavaScript. We can't add this thing to JavaScript without a known use case. And they're like well the best use case is probably event target. Why don't you try it over at the W3C. And so that's what happened like five or six years ago I was tasked to write up a proposal while I was working at Google and I think their proposal number was like 5, 4, 4 or something like that. It was this hugely liked. It's got tons and tons of thumbs ups and rocket ship whatever emojis that people add to GitHub issues, probably more than any other issue that they've had. Then we had to make the case for it and the case was made that these things exist everywhere because over that period of time like the usership for RXJs had not only like gone up upwards, but there was tons and tons of libraries that are widely used like React, Router and VUE to some degree and trying to think svelte that had their own observables inside of them. Relay had its own observable inside of it like they were indistinguishable from the RXJS observable except for they were on their, their own little proprietary things because they needed them for various purposes. If you go to the readme on the proposal, you can see all the. The uses of it. The other thing is, I could say, what is it like two or three years ago I looked in. The overall downloads of RXJS since I had started working on it was up over 2 billion total for the time that it existed. So the number of total downloads every year is still more than all of the frameworks added together. There's a lot of evidence that people want to use observables for things. Even though there's plenty of people, loud people out there like, oh, observables are the worst. Developers are really bad, I can tell you that. But observables themselves, they never hurt anybody on their own. It was always in the developer that hurt somebody with them. There's a lot of evidence. So the TC39 process and the W3C process are very different. And the W3C wetweg stuff, I think you need to have, and someone can correct me if I'm wrong about that, but I think you need to have two implementers, people that actually create browsers, interested in this in order to proceed to the, the very first stage. Then after they're interested, it goes, you go to something like tpac, it's discussed, there's a proposal, all this other stuff, and then an implementer implements it and they put it behind a flag and there's some discussion and more discussion and so on. So that's where we're at. And like right now, it's very, very close to being released. It's already been announced that we're going to try to land it here, and I think chromium 133 or something like.
- [37:06]
Josh Goldberg
That, that's very exciting.
- [37:08]
Ben Lesh
So, yeah, so it'll be available. That makes it available in Chromium and Edge and whatever the newer Electron is that comes out after that. Firefox and Safari and Opera, all those folks are interested in it as well. But I don't know when they'll get to it. They've been a little slower to release features. It's not their fault. It's just how things shake out, I suppose. But they definitely all have interest. All those people were involved in the discussions that I was in, so. And then the only other thing that needs to be done is it needs to be added to Node, who has vested interest in wanting it in there, because they have Event Target as well. So after that it'll be everywhere. If not in some browsers that are slow to catch up, but the polyfill is pretty small.
- [37:50]
Josh Goldberg
So this is what you mentioned earlier, that the core API, the stuff that you don't wrinkle your nose at, is not that much stuff. But from those very bare primitives you're able to create a lot of really beautiful logic with the observables.
- [38:04]
Ben Lesh
Right, right, right. Yeah. There's almost everything I would want to use is there. You've got your finally in your catch and instead of tap we have inspect. I think there's some really good stuff in there. The only stuff that we don't really have yet that does belong but it's not there right now is there's no concat. For example, there's no merge is one that's kind of powerful where you can merge two observables together and mix their events sort of thing. Which is fine because like I said, we've got Lodash for events. So this now literally RXJS and Lodash are kind of on the same path where Lodash existed before, arrays had so many nice features. I think arrays used to just kind of have like filter and map and I think maybe reduce and now there's flat map and all these. There's a variety of ways you can use an array now that didn't exist whenever Lodash first came out. And so now I think that RXJS is probably going to be kind of in the same path, which is fine. It's great. I'm happy, happy to relinquish control of that to. There's no reason that Ben Lesh of all people should be the arbiter of everyone's favorite async push based type. Like that's not probably not a good state for the world to be in if that's the single point of failure for that. Because I'm not that great of an open source maintainer.
- [39:26]
Josh Goldberg
I don't know, Ben, you've distributed or demonstrated a lot of the really common positive attributes of an open source maintainer, which is you wish people would use fewer of the features of your library. You've expressed excitement about pushing it to a better place, in this case the web platform. To me, those are pretty good indicators that you're doing a good job.
- [39:43]
Ben Lesh
No. Well, great. I'm glad to hear it.
- [39:47]
Josh Goldberg
Yeah. What does that mean for the next major version of rxjs? Are you just going to be a thin wrapper around observables?
- [39:52]
Ben Lesh
I'm working on it now. I had to put it out. So originally the next major version was going to be. I Remove all the deprecated stuff, make the total size of rxjs another 20% smaller because I cut it in half the previous version. I was going to make another 20% smaller in this version. And then this proposal caught on and I was like, okay. But then it really caught on. I'm like, okay, this is actually going to happen and it's going to be maybe a little different shape than our observable. So I stopped all new production on RXJS code because I wanted to make sure. I thought it'd be silly to release RXJS8. And then immediately afterwards, here's RXJS9, the thing that is, you know, wildly different because it's trying to make peace with the platform. So right now, and especially also because it's just me working on this right now, what's going to happen is RXJS8 is going to end up being targeted at the web platform shape of observable and wrapping that and relying on a polyfill that will provide if you don't have it, because there's going to be people that don't have it. And then RXJS7 will exist, you know, for a very long time. I don't know how long I'll extend my support of that, but we're going to have to keep it going for quite some time because there'll be a lot of people that are stuck on RXJS7 or using RXJS7 until we figure out. Until I figure out how to wait to provide some sort of backwards compatibility or migration path for folks, if that's even necessary if you're using RxJS 7. Hell, if you're using RxJS 6, it's fine. You probably want to move to 7 because it's faster and smaller. But, like, if your app works, like, I would not spend tons of money and time updating something like that unless you really, really were excited about it or there was some great pressing reason to do it. And you know, younger me would be like, no, you update to the newest thing all the time. Don't be crazy. Like, you're going to get so behind. But older and more experienced me has learned, like, oh, you know, it's okay if you're using this old version of whatever there's features to ship and make sure everyone's getting paid and making money at your company and don't worry about what version of RXJS you're on. But, you know, I'll do my best to try to provide a path for people and, you know, Also make sure this version of rxjs8 is a lot more simple and hopefully, hopefully at the end of that, like I can just kind of watch it and make sure it stays on a good course. And as I stated before, there's only so many times you can. So many ways you can write a window when or whatever. Like it's not. Doesn't require a ton of maintenance once it's, once it's up and running. It's not like a, it's not like a framework or something where there's, there's the platform shifting underneath it. This is pretty close to the metal.
- [42:36]
Josh Goldberg
JavaScript stuff you are working at Privatives. We recently interviewed Jessica Janik from Angular, for example, who went on in detail about all the interplays between streaming and suspense and server rendering and delays and deferables. And yes, it's great to not have to deal with that ever shifting target of what users need and what the browser does. But at the same time you are dealing with complex data. I mean at the end of the day, moving from RXJs, let's say 6 to 7 or even 6 to 8 is a very amorphous, kind of hard to measure task compared to say just upgrading your typescript version, right? Like there's a lot of stuff that's really hard to detect when it asynchronously breaks unexpectedly.
- [43:15]
Ben Lesh
I think the thing about it is that the contracts are like when, when each thing should happen is very like kind of academically constrained. So there's a set of guarantees like you can't, you can't next after you err, you can't err twice. Like you know, there's, there's all these, these things as like if there's an error like before and this is, this is actually fairly recent because not every version does this. But like if there is an error, you tear down everything. As soon as you know that something bad has happened, you tear down everything and then you push the error. So like there's, there's all these rules that exist about how it's supposed to behave such that the only real rule that's changed with the new observable in the platform is that it is refcounted and multicast in some ways may surprise some folks and in other ways in most, most of the time I think it's going to help be helpful to people because the reason that decision was made is because the very, very primitive version of observable, which is cold by default and will start a new subscription for every time you subscribe all the way up to the chain. That behavior, I think despite being the more correct behavior, the academically correct behavior and the more composable behavior, I think that behavior confused some folks. Like a lot of people were thinking, oh well, if I start this stream over a websocket and I subscribe to it seven times, there should only be one WebSocket. And what would happen if you wrapped it with an old observable would? It's open end websockets for however many subscriptions unless you shared it or whatever. So and if you go through and you look at people's code bases that use a lot of RXJs, everything's like share, share, share, share, share. To prevent that from happening. So this is kind of does that behavior by default. So that's the only place that it'll really get hairy when people go to convert things over. There's other things that would require some manual work. Like for example, rxjs7 uses the. These pipeable operators. With pipeable operators, you're basically doing functional piping. And the reason that exists is so we don't bloat bundle sizes by adding a bunch of methods. Well, the platform just has methods on the observable, so we need to come up with a better way to do that. I think I've developed a pretty good way. We'll see how that goes through Alpha. And then we need to make sure that we still support the old pipeable operators and all these. So there's. There's a variety of things that have to happen. It's definitely not going to be easy. I would never sit here and be like, oh, it'll be easy. And then someone else will listen to this. At some point they'll be like, God, that Ben Lesh, a bastard. Can't believe he said it would be easy. No, but you'll get paid for every hour that you do it. I guarantee it. If you. Well, I don't guarantee that you could be open source, you poor bastard. But if you're not working in open source, then you're ideally collecting a paycheck while you're doing this. And you know, enjoy, enjoy the money. You're welcome. Thank you.
- [46:14]
Josh Goldberg
Cool. Well, that's all the time we have for RXJs. As much as I would love to dive into so many of the cool things in it, I just have one last question for you, Ben. I'd like to end with something not technical. You dropped out of art school, but you're still an artist. Can you tell us, are There any particular artsy things you've done recently that you find?
- [46:33]
Ben Lesh
Oh, well, the most recent thing I did was, and it was the first oil portrait I have done in, God, 20 years, probably is. I painted a portrait of my parents, my mom, my poor mom, she's terminally ill. And like after art school I'd never gotten them any paintings ever. Like I went and started working and I was busy and then I had kids and blah, blah, blah. Like I never painted everything and anything and gave it to my parents. So this last maybe a couple months ago, I had finished a pretty good sized painting. It was 3ft by 2ft or maybe a little bit larger portrait of both my parents side by side. Like the classic portrait thing. And I was able to present that to my, my mom. That was a big deal. That was a big deal.
- [47:14]
Josh Goldberg
Do you still draw often? I think I remember you drawing at a conference coming up.
- [47:18]
Ben Lesh
Yeah, I think I drew a picture of you. Actually I drew a picture of you when you're on stage. So, yeah, I do draw. I have a sketchbook that I bring around. Usually I do it on trips when I'm here at home with kids and work and housework and everything. I don't get the time I'd like to, to do it and if I do like, it bothers me when I get distracted in the middle of it. But if I go to a conference, sometimes I'll sit there and I'll sketch the speakers on stage or if I'm traveling abroad or I'm like at an amusement park with my kids and they're off doing their thing. Like I'll be, I'll sit somewhere and I'll just sketch people I see sitting around. So I like that. That's. That's the best way I kind of do art these days is just quick pencil sketches of random people as I'm roaming about. But.
- [47:59]
Josh Goldberg
Well, I'm just curious now to end the interview. On the curiosity note, you get so much out of open source. Clearly you've had a wide impact. You've improved the platform. You've tackled very many interesting problems, design code, et cetera. With rxjs, what are the parts of your brain that you find are being scratched by the drawings, the art side that are inspired by RXJS in your.
- [48:18]
Ben Lesh
Day to day job, I mean, they both kind of do the same thing. You're building something from scratch, right? So there's a process. You're building something from the ground up. Like you have to kind of anticipate the next thing you're going to do while you're doing it. So if it's a painting, you start with an underpainting and then you build layers up and you think about, you know, where's the dark and where's the light and like what, what do I need to accentuate over what the actual photo shows and those sorts of things. Like you, you're problem solving effectively in order to produce something that other people can enjoy. And like that's the same. It's the same thing for me with, with open source work or work stuff I do at work, I am generally problem solving to give something to other people that they'll enjoy. That sounds sappy, right? But it's true. It's true. That's what I do.
- [49:09]
Josh Goldberg
It's a lovely sentiment and it's a great way to end the interview. Ben, if there is anything people wanted to find out more about you about rxjs, is there some place or set of places on the Internet you would direct them?
- [49:19]
Ben Lesh
Oh, let's see. I'm on Twitter at Ben Lesh. I'm on bluesky Ben Benlesch BSGuy app for now. I didn't like put my custom domain in. I'm not that cool. But yeah, those would be the two places you could find me other than going and trolling and issues on GitHub. Feel free to ask me questions. I'm always, I'm always. I try to be helpful with people. If they message me, I do try to respond. Although Twitter's DMs used to be my go to spot and recently they've gotten so gnarly with so much spam that like I have a hard time even opening it and paying attention to it. So I'm sorry if you message me in there and you fall in with all the other people trying to get me in some sort of cryptocurrency scheme.
- [49:58]
Josh Goldberg
So I do have this one blockchain. Just kidding. But no. Ben, thank you so much for coming onto the show. This was fantastic. We talked about RXJs and observables and the platform and I'm really excited for where you're taking the project. This is good stuff.
- [50:10]
Ben Lesh
Thanks Josh. I'm happy to see your face again.
- [50:12]
Josh Goldberg
Yeah, it's been a bit. Cheers. Thanks for listening. Alright, it.