Ben: Hello, and welcome to PodRocket. Today, Kaelan and I are sitting down with Ben Lesh, who is a staff Software Engineer at Citadel and a project lead on the RxJS project. How are you guys doing today? Ben Lesh: Doing great. Kaelan: Doing great. Ben: Yeah. So Ben, maybe just give us a quick intro. I know I introduced you a bit, but maybe just who you are and what you do. Ben Lesh: Sure. So let's see, I've been working in web development for a little more than 23 years, so I'm old, I guess. And then I've been working on RxJS for the last seven years about, since I started working on it when I worked at Netflix and then it followed me to Google and now I'm at Citadel Securities. Ben: And what is RxJS? Ben Lesh: RxJS is, well, the RX stands for reactive extensions for JavaScript, which doesn't really tell you that much, but it's all about reactive programming with a type called observables. Ben: And for folks that may not be familiar, what is an observable and how does the paradigm of using observables with RxJS help and what are some of the benefits? Ben Lesh: Sure. So observables are what's called like a push-base type. So that means that you hand it a function, that's like an event handler, and then it pushes events at you with a value. And the thing that's unique about observables is it allows you to treat events as sets of things. So values over time, if you will, as an individual set of things. And when you have a set of things, you're capable of doing a variety of stuff. So when I say a set of things, I don't mean like a JavaScript set necessarily, but an array is a set of things. A bushel of apples, a bushel is a set of things, right? A truckload is a set of thing. Ben Lesh: So when you have a set of things, there's category theory properties of having a set of things, where you can have what we call maps. So you can map an array to a new array of the same size of mapped values, or you can reduce an array, or you can filter it, you do the same thing with the truck, right? So you have a truck of apples, you could map that truck of apples to a truck of apple slices. Well, I guess maybe that's a reduce, but either way, anything that is a set that can be dealt with as a set or a collection of things has special properties about it. Ben Lesh: So if you treat events or values over time as a set of things, you can transform it into other events. So you can say, "I have an event of button clicks," or, "A stream of button clicks, and I want to transform that into a stream or an observable of fetched data," is a very common use case. But you can also do things like combined streams of events. So maybe you want to do drag and drop, where you take a stream of mouse downs, you switch map, we call that switch into a stream of mouse movements. And you take that stream and mouse movements until you get an event from your stream of mouse ups. Ben Lesh: So it's just an interesting way to deal with streaming things or event based things. And the other thing that's interesting about it as it has this idea of cancellation, so that it makes it easy to be like, "Well, I no longer want the stream, I want to cancel that." So even if it's a stream of one thing, could even be a stream of no things, but you have the ability to cancel and finalize and kind of tear things down. So that's the two most interesting aspects of RxJS. Kaelan: That sounds quite powerful. What does that mean specifically though for front-end apps, if I was trying to convince a skeptical lead engineer. Ben Lesh: Sure, sure. So, I mean, well, there's one thing that's true about front-end development is there's a lot of, it's very event based and people don't often think about this, but I mean, you've got things from document load, all the way through button clicks and mouse movements, mouse over. Even when you go and fetch data, you get an event back. So they even, you'll hear people talk about the JavaScript event loop. Everything is event based in front-end development in JavaScript. And if you can take those events and treat them as sets of things, so you can manipulate them with a kind of a powerful domain specific language over top of, like everything's the same shape, then that's pretty powerful. Ben Lesh: The other side of it, which I actually personally think is more powerful, is having a unified mechanism for canceling something. So right now, for fetch there's AbortSignals and for XHR, there's an abort method, and for set timeout, there's clear timeout and so on, like a closed method on WebSockets and that sort of thing. And these are all things that are sources of events, but they have no unified universal way to cancel those things. So RxJS, in particular the observable type, attempts to do this by providing a subscription. So you get the same shape back whether or not you have an observable of button clicks or an observable of set interval or whatever you wrapped in an observable. Kaelan: That sounds great. Almost feels like it should be part of the language. Ben Lesh: Well, there were attempts to do that. So whenever I first started this, there's a gentleman by the name of Jafar Husain, who is on the TC39 for Netflix. And he championed, along with another guy named Kevin Smith, championed the observable proposal, which is still there but dead. No one's a champion for it. So the thing about the TC39 is, it's an organization where people go in and they vote on what features should land and in order to belong to this organization, it's a paid membership by companies. Ben Lesh: So if a company is paying you to go there, they have to have some sort of vested interest in whatever you're championing. So it's not so much about the will of the people so much it is the will of these individual companies that can afford to send software developers [inaudible 00:06:57]. So the proposal itself is not dead in the aspect of, it'll never happen, but there's no one championing it right now. So it's just kind of paused and sitting there. But RxJS is modeled after the proposal. I have no idea, I couldn't even tell you what the prospects are for the proposal, other than that, it's not dead and no one really objects to it. It's just it doesn't have a sponsor in the TC39 to kind of push it forward. Kaelan: Oh, it doesn't seem to be holding our RxJS back. Ben Lesh: Yeah. Not at all. Not at all. I mean, we still try to keep that in consideration, but one thing is, if it did become part of the standard, RxJS would aim to just use the native observable. We probably would still have all of the different operators and stuff because I doubt most of those would land on the native observable, but at the same time it does afford us opportunities to use unique mechanisms to make RxJS faster and things like that, that we might not be able to use if observable was native. Ben Lesh: And it also gives us the opportunity to experiment with things. For example, there are native cancellation mechanisms that are now landing and they've landed in node and most major browsers like AbortSignal. And then there's actually a companion to this called task signal which is behind a flag in Chrome right now, I think, for scheduling API. And these are things that are very, very similar to our subscription. So we're looking at these and saying, "Hey, if more APIs adopt wanting to use this, then our observables should probably support that, and maybe we move away from subscription." So we kind of evolve with the platform, and that becomes easier if we're not also tied to the platform. Because as you know, sometimes once they put something like that out there, they're not going to change it. Ben Lesh: And it might end up being some sort of dissonance between like, "Oh, we've got this cancellation thing, but by the way, we already shipped observable and whatever." Although part of me wonders if we have this universal cancellation mechanism, if maybe getting an observable proposal through becomes easier, because there's less types to add to the language in order to get that. So the got you though is, the AbortSignal and task signal are not part of the ECMAScript spec. They're actually a part of, for AbortSignal, they're part of node and they're part of, I believe the WHATWG spec, and then it's W-C-I-G or something like that for task scheduler. So there's other specs that are related to the DOM and to node that control those things. Kaelan: That's fair. Did you think it would be part of JavaScript? Ben Lesh: Yeah. It's like setTimeout, setTimeout is also not part of JavaScript, which is funny. It's one of those things that's ubiquitous, it's everywhere but it's actually not part of the ECMAScript language per se. Kaelan: Cycling back to what you said before about the main focus of our RxJS, in the last five years, I know the web development community has been focused a lot on how to improve how our apps handle state. And I'm wondering if you can talk a little bit more about how our RxJS might improve, not just events but also state handling, or maybe not part of RxJS core, but other libraries that use RxJS, since it's pretty low level. Ben Lesh: So reactive programming in general is actually a fairly good mechanism for handling state, and there's a wide variety of ways you can look at reactive programming or what reactivity is. But at the end of the day reactivity is a lot about like, "Oh, I have a handler," or a function and it gets called when something changes and it doesn't have to know what it is that changes, or why that thing changed, it just has to know like, "Here's my new set of values and I'm going to act on that." So there are people that would be like, "Oh, well React isn't that reactive." And in fact React is reactive, especially now, it's very obvious, you got a render function, it gets called every single time prompts change or state updates or whatever. Ben Lesh: So can RxJS help with this? Absolutely. RxJS is, it's about reactive programming, there are many very different attempts at creating state management libraries around RxJS. I think the early versions of MobX were even written either with RxJS as an inspiration or actually utilizing our RxJS under the hood and parts. So I mean, the idea is also with reactive programming that when you have these functions, a lot of them are pure functions, meaning that you're not dishing out a lot of side-effects. Ben Lesh: And side-effects are, and for people that are listening to this, that don't quite understand what a side-effect is. In simple terms, if you have some pieces of state, or some variable outside of your function that is altered when you call the function, that's a side-effect. So whether that is like, "I called my function and made an HTP call and stored something in a database," or whether that's like, "I literally have a variable that I updated when I called the function," that's a side-effect. So when it comes to state management, side-effects make things kind of hairy to deal with in the same way that shared global state makes things hairy to deal with. Ben Lesh: It's exactly the same set of problems is, now you're saying, "Oh, when I called this and when somebody else called some other thing, they're both racing and maybe updating the same piece of state, and that makes things harder. Where if you can kind of control the stream of how things are inventing and control, at what point, kind of centralize at what point your state is being updated, then quite often you'll find your state management becomes easier to reason about. Now, that's where things like Redux come in, and Redux can be implemented in RxJS with nothing more than a scan operator and a behavior subject. It's literally the same thing pretty much. Ben Lesh: There's, what's the other one, Recoil, which is also a Facebook thing. That's basically behavior subjects in RxJS. So these are patterns that show up over and over again. And I'm not saying like, "Oh, well, they copied us." It's like, no, these are just things that people naturally come to these decisions like, "Oh, this is a good way to do things." And then organically, everyone kind of builds the same thing. That said, all of the state management solutions, there actually is something to be said for mutable global state, mutable global state is really easy to think about. Ben Lesh: If I'm like, "Hey, I've got a foo variable," and I'm very careful about who is updating my foo variable, then it's pretty easy to just update a food variable and look at it. Where sometimes when you get into these reactive state management systems, you end up with these, you've got the centralized, synchronous state management, and then you've got all this asynchronous stuff going on, that then updates the centralized state management, and you have to bootstrap and create all these things. And then the next developer joins your team and they want to quit as soon as they look at what you've made, because it's this giant spaghetti mess. Ben Lesh: But there's trade offs. You're probably more likely to get some correctness with one over the other. Then there's also things like state machines and XState and these other things that are really great for state management. But they're complimentary, they have different goals. So one is like, "I'm managing state in a process of," maybe combining streams or something like that. XState would be a horrible choice to deal with combining streams, it's not what it's written for. Where RxJS, can you build something like XState off of RxJS? Absolutely. Should you? I'm going to go ahead and say probably not because XState's written for a specific purpose and you're... I mean, go ahead. Ben Lesh: I mean, if you can create something amazing and everyone wants to use it, then absolutely go use it. I don't want to stop people from innovating, but RxJS t's a set of primitives and tools to do things, and it's not necessarily geared for state management or not geared for state management. Can you use it for that? Yeah, you can use it, but you can use JavaScript for that too, right? You can use whatever you want for state management. Reactive programming itself, just to go back to it though, does have a place in state management. It can be a powerful tool for kind of centralizing and dealing with things and you're talking about things like use reduce is an example, and say React of reactive programming are RxJS in a lot of ways. Ben Lesh: It's just, RxJS has a lot more tools in its built for dealing with things in similar ways. So hopefully that answers your question. Yes, RxJS can do a lot to help people with state management. There's a lot of other tools, they're all kind of interrelated. Look into state machines, they're pretty cool. I haven't actually had a ton of need to use state machines, I just think they're really cool. But I also don't heavily lean on RxJS for a lot of my state management, which just surprises people because I'm an author of the library unless I have to. In some cases I have to, but it'll be like state management within the confines of bringing multiple streams together and trying to reconcile things. Kaelan: You reminded me of the most useful React hook that I've ever came across, the use observable hook, and the React use [crosstalk 00:17:30]- Ben Lesh: Use observable, yeah. Kaelan: Yeah. Anyway, I wanted to ask you what the common pitfalls, because like you said, this is a very primitive tool, you could say, that you could add to your app. What would you say the most common mistakes that people make when they're using our RxJS? Ben Lesh: Honestly, the first and probably biggest mistake I see people make with RxJS, in my opinion, this is just from my perspective, because I don't want people to hate me because I wrote the library. Is the first thing they do is they're like, "Wow, I know a lot about RxJS and I can write this really cool thing that used to be 50 lines of code in like two lines of code now." And they do it and then no one else on their team has any idea what the hell it does, right? So that's probably mistake number one, don't do that. Make sure other people know what it is. Comment the bejesus out of it, teach people on your team how to use it, because what you're doing is you're kind of expanding your language with this new domain specific language to deal with things in special ways and it's important not to do that. Ben Lesh: Now, the other list of things is, there's really common stuff. Like people will subscribe to observables inside of an operator of another observable or something, and then not track the subscription. I mean, there's just a laundry list of kind of weird mistakes, sometimes people will have side-effects in places where they shouldn't have side-effects and they find that confusing. Other times people will work way too hard not to have a side-effect when it would have been really easy just to put a side-effect inside of a map functioning, you would have been fine. No one would have... like, I wouldn't appear before you wouldn't be like, "Hey, why did you do this?" That's not a thing. Ben Lesh: So I think that I think that the other mistakes sometimes people get is getting too dogmatic about what they have to do, "This should be in its own operator and this should be in its own operator." Like, did you really need to map three times, or could he have just done that in one step? There's things like that. So I think that the mistakes kind of fall into a couple of categories. One is the mistake of plunging headlong too quickly, and the other is the mistake of kind of just technical gaps where you maybe don't understand that you shouldn't be subscribing inside of a map call back, or you really shouldn't even subscribe inside of a subscribe, right? There's certain areas where you kind of do and don't want to do these things. Ben Lesh: And I've seen all of it. I've seen it all of it from really, really smart people too, just where they missed by a little bit. One tip I would have for people though, is sometimes all you really needed to do is subscribe to your observable and just deal with it. Sometimes I'll see people like they've got an observable and then they'll filter and map and scan, and then they'll subscribe. And if you look at it, you'll just be like, "You could have just subscribed to that observable, you don't need filter map or scan, you could have just subscribed to it. And then inside of that did your filtering and mapping and scanning all kind of in one step." Ben Lesh: And sometimes that makes sense, other times it doesn't make sense. But yeah, I think, but that kind of falls in the first category again, where maybe they're plunging a little bit too deep into it or overthinking it or something like that. Kaelan: Or probably just intimidated by them. They're really huge API. Ben Lesh: Yeah. We're working on reducing that, that API is quite big. There's a story about why that API exists, and a lot of people don't really think about this. But RxJS originated because it was a direct port of Rx.Net. So there's a project in Microsoft called Microsoft Project Volta. And Volta was aimed at compiling .Net C# down to JavaScript. So this was going on around the same time as TypeScript was conceived, in TypeScript one, thank goodness. And the only remaining piece of project Volta was this piece that Matt Podwysocki, who is like the, I don't know, the grandfather of RxJS, if you will, did a direct port of Rx.Net to JavaScript. Ben Lesh: And so Rx.Net is, it's .net, it's a compiled language. So you can have as many methods as you want or extension methods as you want on anything, and it'll all get compiled away, whatever you don't use. Not that that matters, it's probably running on a server somewhere, and it's binary. So where RxJS itself has different goals. So we end up having tons and tons, and tons of methods that we inherited from this previous API. And we're slowly trying to whittle that down to something sane. Now, on the other side of it, one of the reasons we have so many different methods is, I was talking before about how things are sets of things. If you have a set like an array, right? An array is a synchronously accessed linear set of things. It's got a unique property that you can access things individually in it by index. Ben Lesh: But a synchronous linear set of things, you can map it, you can filter it, you can do all these things, but it's one dimensional, barring you can make an arrays of arrays then when you have a two-dimensional array. But either way, arrays are one dimensional as an individual thing, whereas observables are actually kind of two dimensional, right? Because not only do you have a collection of values, but there's time between the values, it's still linear, but there's two dimensions that you have to deal with. So not only can you do all of the same operations that you can do with an array, as far as transforming one array into a new array, so observable to observable, but there's all these other things, like you can delay a value, or you can say, "I want to value it after a specific time," or whatever. Ben Lesh: So there's just an additional dimension to the things you can do and RxJS tries to provide really well-tested operators to do these common things that people might want to do with sets of events, but that causes it to explode into, "Here's all the set of synchronous things, and here's all of the set of other asynchronous things you can do when you get a value." It's just one more way to kind of manipulate things. Kaelan: I noticed you recently released 7.3, and it seems to have a lot of really great performance improvements. I wonder how different it is from two years ago when I last tried it. Ben Lesh: Well, let's see. Honestly, version seven, it's not going to be like version 7.3, it's not going to be super different. So two years ago, you still would have been using Pipeable Operators and these things. So this is like a functional piped way of dealing with operators. For people that are listening I could get into that after. So that's all pretty much the same. We haven't removed any deprecated API, so none of that's really changed, version seven actually reduced the size down to 53% of the original size of RxJS, or the previous version. So you notice bundle size improvements, pretty drastic bundle size improvements. Ben Lesh: And then starting in version 7.2, we started exporting all the operators from the top level. So you can pretty much import everything you need from just RxJS now, which is a big deal. There's been some additions, there's new APIs for converting to a promise which are first value from last value that are tree shakable. There's a new API for getting an observable of animation frames that will give you time since it started, there's a duration sort of thing to kind of help with making animations. There's new additions to multicasting operators that we're trying to move towards so we can get rid of all the other ones, because there's like 12 or something. And now there's a set of three that you can use to do pretty much everything. Most people will probably only ever use the share operator anymore. So that's kind of a big deal. Ben Lesh: But yeah, there's tap, it'll notify you when someone's subscribed, when someone's unsubscribed things like that. So there's a lot of new things and some things that people have been asking for a long time, that you might enjoy a bit, ultimately most of your code, if it worked in version six, will just work in version seven. If anything, you have to update TypeScript to TypeScript five or 4.2 and anywhere that you had explicit typings because RxJS couldn't handle typing things properly before, that might break and you might have to just delete your explicit typings and then things will suddenly work, which is nice. Ben Lesh: But otherwise it's not that different. I mean, I'm not going to change like mergeMap, mergeMap will be merge map, I'm assuming long after I'm dead and gone. There's only so many ways you could do that. So things are pretty stable. Kaelan: Has it been challenging to introduce new concepts and ideas while also still making sure that you don't cause too many breaking changes? Ben Lesh: Yeah. Yeah. So I mean, we don't really worry across major versions too much, but we don't want to introduce too many breaking changes too quickly. Which is why most of our deprecations are minimum one-year-old, in some cases four or five years old. And the thing is there's a lot of scale to RxJS. So working on RxJS is, I've had open-source projects, I've worked in open source where I wasn't the owner of the open source, which makes it different. But when you have your own pet open source project, it's easy to think, "Well, this open source project is the same as an open source project like low Dash," or RxJS or whatever. Ben Lesh: And in code structure you might be right. But the difference is, it's scale, there's actually a unique cutoff, I don't know what it exactly is, but at npm, if I publish a version of RxJS, I'm not allowed to unpublish it. Or any other project, there's a time period where you're allowed to unpublish it. So many projects depend on RxJS that if I publish a version, it immediately gets picked up by somebody and people start to depend on it. So the challenge... yeah, it's a little intimidating. The challenge is to make sure that you're not driving it towards a way that will cause some catastrophic situation when people try to update to the next major version, right? Ben Lesh: And there's always, there's always some complaining when there's a new major version, there's no way around it. We didn't even remove anything, we deprecated this time, version eight, we're going to be removing the stuff where deprecated and a lot of it has been deprecated for, like I said, four to five years in some cases. And I guarantee they're still going to be with people that are like, "Oh my God, you broke everything, why did you remove this?" Ben Lesh: The upside is, you branch and you can maintain the old version and the new version. So it's not completely the end of the world, but yeah, have to think about like, "How can I move things forward in a non breaking way, what can I do to make things better for people now that won't break them? And then how do I remove it later on?" There's been a lot of really great things that help with that. The fact that deprecated things in like TypeScript and using Visual Studio Code gets a little line through it, right? There's linting tools that sometimes won't even let you use deprecated things, which is nice. Ben Lesh: There's a lot of different stuff, code transformation tools that people have written to try to help people migrate away from things that have been deprecated. So things are easier, that and now people have lock files, which is amazing. When I first started doing this, not every project had lock files and I introduced a breaking change in RxJS like a patch and didn't realize, but it was breaking people's builds. I mean, that same night, so I released or published the version, I went to bed and I woke up to a bunch of messages from people I didn't even know that somehow got my contact information from big name companies that I do not work for, they were like, "Dude, you got to fix this, you broke all the builds." Ben Lesh: But now people have lock files to kind of prevent that. Thank God. Use your lock files if you don't, that's your fault now. But yeah, the scale of it is very intimidating for me, I mean it gets deployed. There's all sorts of things to think about. It gets deployed to everybody's, like all these Fortune 500 companies and stuff, npm, to my knowledge does not have any security around post-install scripts, right? So if someone was to get ahold of my npm credentials, and I didn't have two-factor off on or something and they were to put some horrible little virus in RxJS and publish it, CIs would kick off, God knows what kind of havoc that would wreak. Kaelan: Let's not give anyone any ideas. Ben Lesh: Yeah. So it's fair, there's some certain bits of intimidating parts about that. I always made sure to log off of npm after a publish and things like that. Ben: What are you most excited about kind of in the longterm roadmap for RxJS? Ben Lesh: Well, I'm really excited to take out all of this deprecated stuff in version eight. I did a preliminary pass at doing this a little while ago, just to see what the size improvements would be and kind of how it cleaned up code. It cleans up code dramatically, and there's, I think it was almost 25% additional reduction in size, on top of what was already done in RxJS seven. So that'll be a really big deal. And just trying to get everything to where it's a little bit simpler. One of the changes too, is kind of prepping us for the future. So one of the changes is subscribed can currently be called with three functions, or two functions, or one function, or a function [inaudible 00:33:23] a function, or an object. There's all these different ways to call it. Ben Lesh: And by version eight, and we've already deprecated the other signatures, but by version eight, you can only be able to call it with either empty, just subscribed with nothing in it, with one function or with one object, which would be your observer. And the advantage, there's huge advantages to this as far as internal code size. But one of the advantages is it allows us to maybe by version nine, or later in version eight, like 8.1 or something, introduce features where you can pass some configuration to it. So maybe we can start accepting AbortSignal instead of relying on subscription or things like that. Ben Lesh: So it's kind of the next big evolutionary step in getting us set up for the future of where observable could go. And that's still very fluid, but we do know that we're going to remove all the deprecated stuff, which by itself is very exciting for me and for the rest of the team as well. Ben: And so folks out there interested in the project and want to get involved, is it easy to contribute to, or what does your contributor base look like, and any recommendations there? Ben Lesh: So version seven is much easier to contribute to than version six was. During the massive refactor that was done, and again, it wasn't a rewrite, it was a refactor between six and seven to get to version seven. I personally spent a lot of time adding a lot of very detailed, why comments in the code and making sure things were named as best they could and making sure everything's very terse. So I think contributing to it now is much better than it was because the old architecture was... and just to be clear, we refactored the old architecture, so it's still kind of the same architecture, but before there was just tons of classes and not a lot of comments, and variables weren't always named great. So I think it's a lot easier to contribute to code wise. Ben Lesh: Now that said, this is a utility library. So the need for code contributors on it is actually fairly light. The best place to place, the helps the absolute most is when people are working on things that are like documenting, or articles, or helping other people, or doing trainings, like free videos on how to do this stuff, or working with their teammates. Honestly, the thing that stops RxJS adoption more than anything else is when you get somebody who's an expert in it that just goes buck wild with it, and then never, ever teaches anyone else. Ben Lesh: And what ends up happening is all the people around this person, we'll be like, "What is this person doing? I hate RxJS. This is awful." Because it's just this big, wild mess of whatever. And the more people they involve and the more people that work on it, the better that code's going to get, and the better the usages are going to get. And who knows, maybe someone creates something even better out of it at some point. But then the big thing is educating other people, helping with documentation is really huge. Ben Lesh: I know that's not the sexiest work in open source. People want to be like, "I wrote the code that did X, Y, Z." But trust me, your documentation and how to do something is going to get a whole lot more views than my code will. There's no comparison, people aren't going to be like, "Oh, let's go look at this map operator code." They're not going to do that. They'll go read your article about the map operator and that will be a bigger deal. And there'll be like, "Oh, the RxJS doc suck. Look at this great article that explained the whole thing." That's super cool and there's no barrier to entry to that, right? Ben Lesh: And again, the documentation, really easy to contribute to, there's literally little pencil icons on it, where you can click and it will take you to GitHub where you can immediately open up a PR and be like, "Here's my change," and send it in. So things like that, like helping other people learn RxJS, or even just giving talks about RxJS, great. I mean, if you're doing a great job, I will lend whatever Twitter following I have to be like, "Hey, check out with this person over here is doing with this cool talk." Great, by all means. Ben Lesh: And do that with other open source projects too, because everything that you can think of that you hate about software development, be it documentation or educating other people or whatever, I'm not saying that open-source authors hate it, I'm just saying they probably have the least amount of time for it too. So they'll love you if you start doing these things for them in earnest and even if it requires some collaboration with them a little bit, I guarantee that that's going to make them very happy. Ben Lesh: Otherwise, if you do see a small issue and you want to contribute code, by all means do, abide by the code of conduct, be respectful. I think if people want to get started in open source in general, independent projects, like RxJS are going to be an easier bet, because you don't have to sign CLAS or anything like you would for Angular or React. The big corporate teams are working on corporately owned open source. They're great, but they have bosses, and meetings, and schedules, and the odds that your PR is going to be a priority on their list, is pretty much nothing, unless one of their bosses says your PR is a priority on their list, right? Ben Lesh: So they're still going to try. I know that when I was on the Angular team, we tried to go through everything and process everything, but that stuff gets backlogged big time. So contributing to smaller open source, independent open source projects is a better way to get started if you want to code in open source, in my opinion, Ben: Great. Well, Ben, thanks so much for joining us today. This has been awesome. Ben Lesh: Thanks for having me. Brian: Thanks for listening to PodRocket. Find us @PodRocketpod on Twitter, or you can always email me, even though that's not a popular option, it's brian@logrocket.