So just to give you a quick introduction, for the ones who are watching this live stream the first time [or reading this blog post tying up with it]. “JSKongress meets friends” is a format that we want to invite people and teams where we think that they can answer some quite interesting stories of some tools, maybe you’re using as well. And also like getting some more insights, which you can’t read on the blog posts. You’re also able to ask your question directly on twitter using the hashtag #JSKongress or on the YouTube live chat, where I already see a couple of people chatting around.
So welcome to this edition. I’m Johannes, I am the MC for today and one of the organizers behind JSKongress. And I’m happy to welcome Jan-Niklas, Tracy, Moshe, Ben and Nicholas.
Check-in
So I would like to start with a quick warm-up question. So Jan-Niklas, let’s start with you: Where are you currently located, how are you doing, and can you remember the first time you got in contact with RxJS?
Jan-Niklas: yes yes yes, okay so I am located in Krefeld in Germany. I’m still melting because it’s freaking hot here. And I’m definitely not able to handle heat properly, so I’m just dying and not properly or active in any way. What was the second question?
jowe: Can you remember your first time with RxJS?
Jan-Niklas: yes, actually quite funny. I’m not sure if the others know that, but the first time I worked with RxJS was in an Angular project, Angular 2, in the release candidate phase. And I worked for like half a year in that project, and I had no freaking clue about RxJS. I didn’t get anything. And then I got in contact with Tracy and started contributing to the docs. And that’s pretty much how everything started and before that I was using switch paper all over the place is pretty much and subjects like professional.
Jowe: That’s been a good transition to Tracy. 🙂 So Tracy, who are you, where’re you currently located, and can you remember the first time you get in contact with RxJS?
Tracy: yeah sure, my name is Tracy. You can follow me on Twitter @ladyleet and I am currently located in Atlanta, Georgia. So all those Southerners out there. 🙋 But my first contact with RxJS was actually – you know – I was just learning JavaScript and I knew Ben. Ben was a good friend already. And I said: Okay Ben, I got JavaScript down after my second week of JavaScript, and whatever’s in that fly export Ben was working. I said: ok, teach me RxJS! And then opened up, you know, opened up the code sandbox or whatever we were using. And he was like: okay, cool, here’s an observable bubble or whatever. And then shortly thereafter he’s like: Let’s take a step back, and why don’t we learn JavaScript first. So that was my first experience with RxJS. And obviously come a long way since then.
Jowe: Moshe, who are you, where you are currently located, and can you remember your first contact with RxJS?
Moshe: all right so my name is Moshe Kolodny. I am located in New York and my first contact with RxJS was when I joined the firebase team. We were working on the firebase console and it was an Angular 2 / Angular.js hybrid application. So my first contact with RxJS would probably be ngrx – with you know – the Redux version of Angular or the Angular version of Redux. So that was my first experience of it.
Jowe: Nicholas, can you tell us, where you currently located and what was your first contact with RxJS
Nicholas: sure, I’m Nicolas Jamieson, I’m located in Brisbane in Australia, and my first contact with RxJS would have been in the Angular 2 beta, fairly early beta. I’d used .NET versions of rx before and it’s Angular 2 and the beta in the pre-release. And all that sort of a saga was my introduction to RxJS.
jowe: so Ben, who are you, where are you currently located, and what was your first contact with RxJS?
Ben: oh well, my name is Ben Lesh, I’m currently in Austin, Texas. Just not but a year ago I was in the Bay Area at Google and before that Netflix, and my first contact with RxJS was at Netflix, where it was sort of -I don’t know – thrust upon me. And I was like “what is this like Lodash or why do we have this? So I’m the RxJS team lead now, and that started because while I was at Netflix there was an effort to rewrite RxJS, and I was tapped to do that. Despite some protests on my part that I was not qualified to do that. So but here I am, turns out I was qualified – I guess – and I’m still working on it five or six years later
jowe: so thanks for an introduction and for giving a quick introduction of you. So glad that you join this session, and let’s start kicking off the questions.
What is RxJS?
So I am pretty sure a couple of humans watching this episode of #jskongress meets friends [ov: “this stream”] are not so sure about what RxJS is. So can you give us a brief overview of: What is RxJS?
embrace a reactive mindset, get used to functional programming
Jan-Niklas: so the RxJS is the kind of default implementation for reactive programming for JavaScript. So it’s not really much about Rx particular. But for using that properly you need to embrace a reactive mindset like you need to get used to functional programming. And what this reactive programming is pretty much about is the propagation of change. So something is happening; some change is happening – how do I react to that? Instead of saying “okay please do that kind of change” and this is a fundamental way how to treat programs pretty much. And RxJS provides the observable entity to deal with those kinds of changes that’s like on a very high level what RxJS deals with – from my point of view. I see Ben nodding, so this is like agreement.
Advantages of RxJS
Jowe: right, and how does RxJS make the life of an engineer better like what are the advantages when I’m using it
Moshe: So RxJS is great for when you’re working with highly type of events that could change over time. So when you need to compose those events or do things with complex workflows and pipelines for different things, you have click events coming in, then you have transitions. And you have all these different user events, and page load events, and different things happening on the page at the same time. Coordinating all that becomes a nightmare if anyone’s done it manually. But you could create beautiful pipelines in RxJS to be able to manage that and you can build up, you can start simple and build up. So there’s no need to kind of go all out to start. So it’s if there’s a ramp up area, as well. So that’s a couple of ways to make things much easier to do
Jowe: mm-hm, and what are the core concepts behind RxJS?
Nicholas: yeah, there’s a handful of core concepts. And that is tangible and there’s an intangible one. I’d say that the core concepts are really observables, observers and operators:
- Observables are sources of notifications.
- Observers subscribe to those observables to receive the notifications.
- And operators are functions that take them observable and return a different observable. So they’re able to change the notifications that come from a source and float the sync.
The easiest way to sort of explain those components, is to use an analogy:
So an observable is kind of like an event emitter. But an event emitter – just, event emits one type of event, whereas an observable has three types of notifications. It can give you a value notification, to give you a value. It can give you an error notification to tell you when errors occurred. And it can give you a complete notification to tell you that they’re only gonna be no further notifications from that observable. So it’s kind of like an event emitter but it does a lot more.
And observers are kind of like the listener for your event emitter. But instead of just receiving one type of event you receive the notifications from the observables.
Operators – the analogy for an operator would be something the the methods, that are on an array in JavaScript. You’ve got methods like map and filter that allow you to manipulate the elements of an array. Operators are kind of similar: They lay to manipulate the notifications that are coming from a source and being received. So they still do the operators used in location.
Some people sort of refer to our experiences of the Lodash for events. Now you can sort of fit those analogies together to – you know – explain that sort of terminology.
Cool concept: guarantees
But there is another sort of cool concept: It’s largely intangible and that’s the guarantees. RxJS gives you a bunch of guarantees. Behavioral guarantees for example. If you receive … an observer received an error notification from an observable, it’s guaranteed that it will receive no further notifications from that observable. Similarly if it receives a complete, it’s guaranteed not to receive any further notifications from the source. And combined with these guarantees, those core components observables, observers, and operators allow you to declaratively compose fairly complicated floats. That you wouldn’t be able to do if you didn’t have those guarantees. If you didn’t have the guarantees you’ve been doing the sorts of things you might have to do with an event emitter where you’d have all sorts of – you know – if-statements and things like “if this has happened and this has happened then do this”.
But the fact that it gives you those three sort of core components and the guarantees means you can build all sorts of interesting things. It’s declarative.
RxJS for .NET?
jowe: I think I first got in contact with reactive extensions for Java a couple of years ago. So there is RxJava, Rx.NET. .NET for example can be used with JavaScript. Would it be better to use RxJS instead of Rx.NET?
Ben: So I mean, if you’re targeting JavaScript or TypeScript you’re probably better off using RxJS. Rx.NET – as far as I’m not even sure what you would do to use or accept it to target JavaScript. I’m assuming there’s some sort of compilation step, where it compiles the the C# into JavaScript or something like that. But that’s weirdly, that’s actually where RxJS was born. Like originally there was this project a long time ago called Microsoft project Volta which actually used the reactive X logo as its logo at Microsoft. The goal of it was to compile C# to JavaScript. And ultimately I believe it was axed because TypeScript became so popular and kind of fit that need better. But RxJS was originally developed as a compilation target for Rx.NET. So it had roughly the same shape. And when they built you know C# down to JavaScript they could use that library. But it’s the – to my knowledge – it’s the only surviving piece. I might have butchered some of that history. But I’m sure Matt will jump in at some point in comments and tell me where I was wrong [editor’s note: Matthew Podwysocki, RxJS alum].
But that’s the basic gist of it:
If you’re targeting JavaScript or TypeScript I would recommend using RxJS.
Jowe: yes, right, so we got a pretty good overview about what RxJS is. What are the concepts behind it. And what are the main advantages of using it.
Numbers and stats
So it would be interesting to see how widely it’s used. Do you track any numbers of downloads, like on npm? Because a lot of other libraries and frameworks are making use of RxJS. Would be interesting what kind of number if you have something.
Tracy: all right, RxJS right now – I believe last week it went about 19 million per week. So that number is consistently growing over time, which is awesome. You know RxJS is the only external dependency in Angular. So a lot of that … a lot of growth is in Angular. But actually RxJS exceeds the number of npm downloads from Angular. And that’s because a lot of folks are using RxJS whether it’s with Vanilla JavaScript or React or Vue. You know another thing is – I think it’s interesting to see the React adoption. So Ben and I run Rx workshops. And you know it’s great to see people from Angular, people from React, and people from Vue, all coming to these workshops to learn. As people are moving away from Redux we’re actually seeing more people use RxJS for cases where they want cancellation or streaming data that they want to compose. So the growth is very exciting. In fact Ben is actually doing React full-time now. He was previously on the Angular team but now he’s full-on React. And I think a lot of us are actually, I know Nicholas is too.
Report your usage of RxJS
Jowe: so regarding the numbers: Nicholas wrote a tool to anonymously report the usage of the RxJS API. How did the idea come up? And how does it work? Can you tell us about it, Nicholas?
Nicholas: oh okay, yeah that lastely came from a discussion that we had in the core team meetings, where we talked about just “how are people using the API”. So I wrote that on the weekend because it was related to some other code I’d been working on. I haven’t had a look at the actual reported stats this morning. I did have a look yesterday after I woke up. And disappointingly, they were 2 – two people had reported their usage stats. But I’ll have a look and see what’s there later today. One person did report a bug, which was cool! He reported a bug, he actually fixed the bug, and then he reported his stats. So that is awesome! But the main thing: I wanted to just give people a way of doing it where it’s completely anonymous and not automated.
I didn’t want to have something that ran in the background when you were installing RxJS.
Because it takes a bit of time. It’s also not something to be particularly comfortable doing sending information with someone’s computer when they’re just installing a package. But yeah not too many results reported yet. It’s promising and hopefully that will give us a good view of what people are using. Interesting in RxJS there are a couple of the things that were reported, did have a whole bunch of different versions of RxJS and in different versions of TypeScript installed so it’s obviously a mono-repo they’d run. Interesting from a number point of view.
Jowe: So I would like to report the usages in my projects as well. Where do I find this tool, and how can I enable it? Is a lot of configuration needed, like is it a lot of effort to do, or is it just like “at this dependency” and it runs out of the box?
Nicholas: you can add the dependency. I posted a blog post on Twitter the other day. It sort of explained how to do it in the blog post. So if anyone wants to use the tool I should have a look at that. If anyone’s using any of my packages, any of the packages that I’ve altered, I’ve added the tool as a dependency of the package. So if you’re using the ESLint rules that I’ve written, or the TSLint rules that I’ve written, you’ll have the tool installed. So all you need to do in that case is run npm rxjs-report-usage, and it will gather the usage. It will show you the usage, it will prompt you whether or not you actually want to send it to the Cortana. If you say “yes, send it” it’ll just post it to a Google Form, and we can go on and gather it later. So if you’re using either of the rules ESLint / TSLint or if using RxJS marbles or RxJS etc: you’ll already have the tool installed and you can just run it. Alternatively you could use npx, and run it directly which will download the script for you and run it. So you can run npx RxJS – report – usage, and it will gather the usage shown to you and prompt you to send it.
jowe: alright, so those who are interested Nicolas Twitter handle is @ncjamieson and I think it’s the first tweet, who is mentioning that tool and also gives you a link to the blog post. and yeah, how and why you can use it
Ben: it’s a big deal, so please do that if you’re listening to this! Because it will help us out a lot.
Motivation to get metrics
Jowe: so let’s continue with this question, this is not marked right now in the document [editor’s note: questions for the session that have been prepared beforehands, and from the live chat are accessible by all session participants in a share doc]. And I think that’s quite interesting: What’s the intention behind, like what are your expectations on getting more and more metrics on that? Is it about the usage that you’re tracking you already mentioned? Like the different versions, which are used outside, which RxJS versions, which TypeScript versions? Like what are your expectations about the metrics you’re gathering, are there any?
Ben: Oh RxJS itself has a huge API surface area. So one of the things that’s interesting that we can get out of this is, like some metrics on what parts of RxJS are being used frequently. And that’ll give us an idea if there’s anything that we could maybe deprecate and remove. Or anything that we should prioritize for performance reasons. Or that sort of thing like if we know that – you know – everyone is using the window and operator for some reason. Which is the polar opposite of reality. I don’t think a lot of people are using that. But if there’s a lot of people using it for some reason, then we know we don’t want to to deprecate it and remove it or something like that. So just things of that nature. It helps guide us with decisions if we have more knowledge about how people are using the library.
Evolution of RxJS
Jowe: RxJS has been public for a couple of years now. Would be interesting like getting a quick overview like how it’s evolved until now: regarding architecture, regarding the team size, regarding the processes you’re using. Can you give us a brief overview about that?
Ben: sure, so actually a lot of that. The team that you see before you, excluding Tracy, is fairly recent in the history of the team as far. It’s been the last year and a half or maybe a little longer that we’ve had these folks on. But the team evolved in that. So originally it was this kind of skunk works project at Netflix, where I was working with a guy named Paul Theo that worked with me at Netflix, who was the original kind of architect of a lot of the pieces of RxJS as it exists. And a guy named John Hussain, who’s on the TC39, who had the observable proposal in front of the TC39 on behalf of Netflix and I was steering the project even though I wasn’t the primary architect of a lot of the features for a while. And then Paul left Netflix and for then after that it was just me working on it. And OJ showed up, OJ Kwon, who’s not with us today, but he’s still on the core team. And he meets with us all the time. And he started reviewing my pull requests. Thank God because I have anyone to review my pull request because it was just me. And eventually, you know, I’d asked him just to join me because he was submitting his own PRS and that sort of thing. So then it was me and him. Andre Stults was with us to write documentation for a while. And then we had … David Driscoll joined us for some time. He’s mostly inactive but he’s still on the core team and we see him from time to time. And then just over time Tracy joins to help the project and help promote RxJS and that sort of thing. And then we have … Nicholas joined us to work on the docks. But I don’t know how Nicholas found us. Did Tracy find you or you volunteered for something Tracy was looking for?
Tracy: A lot of the team, the current team I came together with, just from the core team saying “hey, you know, we need help with the docs – like just come help out”. And you know, we’ve been so grateful that folks who were just working on docs and helping out, had kind of transitioned to actually being part of the core core team. So it’s just really nice to see. But yes, I think Nicholas started helping me on the docs. And you know, the rest is history.
Ben: Yeah so that as far as the ownership of the project goes. The original version of RxJS was a Microsoft open-source project, and there is agreement amongst folks in the reactive X community, which was not a Microsoft organization. That it should be moved under reactive X. Microsoft was okay with it, and so that’s why if you ever look at the license: The license is kind of strange, it says “copyright Microsoft, copyright Netflix, copyright Google, and contributors”. So, and that was just there. There were lawyers that were scary. They were involved with that. “let me get an email from a lawyer from one of these multi-billion dollar companies”. And you’re like “oh I’m gonna get one of these other lawyers from the company I work for to deal with this. Because I don’t know how to reply, or if I even should reply to this”. So that was the agreement that was laid out. And so now it’s a true open source project in all respects. It’s not behind anyone’s agreements or anything weird like that, like some of the corporate open source projects are. So the only thing that’s unique about it is: It was a Microsoft thing, that Microsoft allowed to go full-on open source. And it’s been following contributors wherever it goes, between jobs and that sort of thing.
Future RxJS
jowe: I’m pretty sure the next question you hear a lot of times, because we’re talking with people who are maintaining a cold ivory core framework. Anything with that high visibility, they’re telling me, the most common questions they get asked at conferences or on Twitter or wherever is: When is the next release coming around the corner? So it’s an honor to ask this question to you directly. So when is the next release of RxJS scheduled?
Tracy: We’ve been talking about it internally, and it’s any day now. I think there’s still a few pull requests happening. And version 7 right now is still in beta. And we’re hoping to get it out of beta very soon. A few things that we’ve been working on are mainly kind of resolving some typings issues, and figuring out what to do with the new animations frames API. So nothing too crazy. I think all of us are charging ahead and looking forward to our RxJS b, which has been in conversation. But obviously focus on making sure 7 gets out of beta first.
Ben: And to that end people are pressed. I would recommend people try the beta, or will probably publish another beta here very soon. There’s a couple issues that we’re waiting for peers to land on. And I think you landed them yesterday maybe. But I recommend people do try the beta and – just for reference – Google actually uses it. So the way that Google does Angular and uses. RxJS is different because Google has an internal mono repository that’s massive. It’s this super huge thing and they have one version of every library in their mono repository. So what they do to get the latest version of RxJS is, they literally pull it on occasion off of the master. And they see if it works internally. They give us feedback if we break something. So we know before we even publish our release. And then they actually use a version from master on our repository. So technically when you’re using things like YouTube or some of the other Google properties, you’re actually using something that’s using RxJS version 7 pre-publish in production. So if it weren’t stable we would know big-time by now. So it’s a pretty stable thing.
Marco Stipek: Obviously the master branch of rxjs is working, otherwise we weren’t able to stream here. Interesting
JSKongress: here is a good example presented at the last #jskongress: Dissecting a completely Functional-Reactive JavaScript app | Netta Bondy [watch the session in full length 22:59]
[from the live chat]
How to support RxJS
Jowe: So, what would be a good way to start supporting the project? Do you have regular meetings? Can I just pick up an issue on GitHub? What would be a good approach? What would you recommend to someone who is interested, but for example hasn’t contributed to an open-source project so far?
Jan-Niklas: So apparently contributing to the docs is very valuable and takes a lot of work for me. So I really appreciate anyone who wants to contribute to the docs – especially as it’s far easier than contributing to the extra code base without any block then. So if anyone wants to contribute, honestly I think, the first thing that would be my go-to is: Reach out to me! So that we can figure out how to contribute on the docs. If someone is really super passionate – and I don’t want to force anyone to do docs-work if you don’t want to. But for other work he probably needs to reach out to one of those guys – at least not me.
Ben: I’ll just assign the coding side of things that is doc related. One of the things people ask for all the time are more realistic examples for the docs. So that’s legit writing code, and the code has to work. But you know it’s for documentation and it’s a big deal because, I would say that the documentation code probably has more effect on people’s day-to-day lives using RxJS than the actual internals do. So I would definitely recommend it if you see it really done as a simplistic example, and you can think of a real-world one that you can stuff in a stack blitz or whatever. Then by all means contribute that because that would be a big help.
To those who are interested in supporting the project. Please get in touch!
jowe: Take a look at the repository, or ping someone of the people here in the livestream: @ladyleet, @ncjamieson, @BenLesh, @mkldny, @niklas_wortmann. I’m pretty sure everyone is happy to get some support.
Start with RxJS
So we talked right now about what RxJS is in general, about the history, and the future. Let’s talk about the presence. What’s a good way to start actually with RxJS? Would you recommend just reading through the docs? Are there any boilerplate projects I can reuse? What would you recommend?
RxJS docs
Jan-Niklas: So even though the docs are obviously amazing and there’s like brilliant content in there. Everything is super clear. 😂 I would probably rather recommend – so the thing I mentioned before is that you don’t really need to learn about all the operators if you start off with RxJS that’s not really interesting.
get the “RxJS mindset”
What you need to do is like getting this different mindset. This is actually the difficult task to achieve. As soon as you got this like “how is this observable working and what is it therefore”. After that you will notice that operators and all this nasty stuff is way easier. So honestly what I figured out is the basis just like building stupid stuff with RxJS. And therefore I would personally recommend: You’re already using whatever technology. Just try to add RxJS and maybe build a feature that you already have implemented with RxJS. Or if there’s nothing right now coming out of your head, maybe implement the type-ahead search drag-and-drop caruso. Those kind of event oriented things, these are really good for ideas. And will really help you also to figure out where the strengths of RxJS are, and what the benefit of using it is. So this would probably go with you.
Learning resources: Learn RxJS and reactive how
There are some good resources that I like to recommend and one is Learn RxJS and one is reactive how.
Learn RxJS has this approach of having things like “here’s an example use case” and “we use these operators for that”. And the other one is reactive how, for this you already have to be kind of familiar with RxJS because it’s showing the differences between operators. But the animations are beautiful and it’s really helpful if you’re struggling like “okay, what’s the difference between switch map and merge map” for example. So these would be my other two go-to-resources and the docs for sure.
RxJS making web development even better
Jowe: So let’s assume I already started. And I’m getting more and more into RxJS. I want to use it more and more and more in my daily routines during work development. How is making RxJS web development even better as it is right now?
Moshe: So a lot of the things with RxJS dealing with values that change over time and that are going and passing by over time. If you try to do that manually – and I remember the early days of jQuery having event emitters and trying to wire things together, it becomes a mess – an absolute nightmare. 🙈 To be able to manage all the different things happening, keeping track of state is a monster. You know, you pretty much have to write a state machine with all these different permutations of every variable that could happen. Because of the big guarantees – that Nicholas was mentioning before – provides some sanity around a lot of the structure on that. So you know that as these events happen. I have an operator that tells, that will stop this stream of events if something else happens. And I could repeat it on a different stream. And I could have an interval on doing it a certain amount of times or in certain combinations of permutations of events. That happens pretty much – the sky’s the limit. So if trying to do that by hand is – for all things of purpose – impossible unless you are a superhuman. So having a well tested, well-documented, understood library doing all that nitty-gritty plumbing for you, just makes everything so much easier.
Redux, React, RxJS – working together?
Jowe: Alright so you just mentioned state management as well. This brings me to Redux: Redux, React, RxJS, all of them are digging around with states. Besides React like Redux is the main supporting library therefore. But let’s talk about Redux and RxJS: Can they be used together? Do they make each other redundant? What is your experience on that and your recommendation?
Nicholas: Yeah, you can definitely use Redux and RxJS there. They solve different problems. You can use React, Redux and RxJS all together at the same time. There’s a Redux observable package that does just that. Whether or not you should, really depends upon how familiar you are with each of the individual pieces. If you’re familiar with React, and you’re familiar with Redux, and you’re familiar with RxJS, you might want to use something like Redux-observable to solve the problem. Basically those things do different things. RxJS in that sense is managing asynchronous effects that are actually happening inside of Redux. Whereas Redux is providing a global store with action based changes. So they certainly don’t make each other redundant, you can definitely use both. It just really depends upon what you’re trying to do, and the problem that you’re trying to solve. And if it fits with the problem that you’re going to try to solve, then definitely use all three.
An example of a situation where it might make sense to use those: If you have a large application, and you have not all backends. Ideal from a frontend perspective. So you often have to deal with backends that are fragmented. And when something happens on the frontend you might have multiple requests going off to the backend. Anytime you need to coordinate those sorts of things RxJS is a good candidate. So if you do have a large Redux application and you have a fragmented backend, and you want to organize a bunch of backend requests when actions are occurring. It would make sense to use RxJS and Redux to solve that problem.
But I’d breach it in that way I’d look at the problems you’d need to solve. Look at the tools that you have. Look at how they solve problems. And figure out whether or not they’re appropriate for your application. But they’re definitely different. It neither makes the other redundant. And you can definitely combine the two, or the three.
Insights
Jowe: Let’s go to the next section, which is about the insights. I’m curious! I see you folks at a lot of conferences, I’ve seen you in the past, not right now. I’m interested. How do you receive feedback from the developer community, from the community who is using RxJS, from the different people? Where do you get your feedback about, which features can be added, which features need to be optimized?
GitHub and Stack Overflow
Jan-Niklas: So they are for sure like the obvious platform of GitHub. We receive issues, pull requests, and stuff like that. Also every one of us is fairly active on Twitter. So people are reaching out to us like “okay, I have this problem, what’s the matter”. And from those kinds of things we can see, maybe this is too complicated or needs some adaptation. The same goes for Stack Overflow: So every one of us is fairly active on Stack Overflow. We have a GitHub channel, where some of us sometimes pop in to help out. But also in general the community is fairly active and turns there. We have Slack, which is not that actively used from the community but we use it to organize our work. Yeah, and for sure every one of us is going to conferences, speaking to people, doing talks, goes to meetups, stuff like that. I think these are pretty much like the main things. And actually a funny thing: the animation frame observable was pretty much for RxJS Live [editor’s note: THE event for RxJS] last year. We’ve kind of forgotten that feature enormously. From seeing the talks it was like “oh no, that can’t be the proper solution for that.”
Ben: There’s another distinct difference between like our team and a lot of say like the corp like framework teams. And it’s partially born out of the fact that we’re all volunteer workers on this. But when I am not the Angular team – I was on the Angular team – everyone that I worked with was amazing super-smart wonderful people. But their heads down working on Angular the whole time, right. So that means that they aren’t spending most of their day using Angular the same way that other people would. They use it but they use it in kind of like when you’re writing testing. Your work on the Angular team. You write up these contrived tests that are to test specific parts of the framework, as opposed to dealing with very very large apps. Now sometimes we would get called to help somebody in the rest of Google or something, and help them with an actual app. But most of the work there – in the Angular team, and I’m sure it’s the same way for the React team, and maybe to a lesser degree for the Vue team – but you’re working on the framework, in the library. And it’s all conceptual, like how it’s being used. Where every single one of us has a regular day job. And at least I assume everybody else here is using RxJS all the time at work. You get a pretty good idea of things that you would like to see changed or fixed. Things that I don’t even know if I’ve ever documented, but I’ll look at things like group by and it’s got the arguments. And I really wish it was a configuration object that was passed. So I knew what the arguments were because I don’t always remember the arguments. And I wrote the darn thing.
So like there’s things like that that we encounter when we’re working with things. Or even small bugs that get caught by the folks in the team. And I think those obviously will get fast attention from us because we’re the ones that found it. But there’s also GitHub issues and that sort of thing. Sometimes when I find an issue myself, I’ll go and I’ll look on GitHub and nobody else has ever reported it, which is always shocking to me. And then there’s other times where I’ll find it, I’ll see somebody reported it – I didn’t – who isn’t able to reproduce at that time or whatever, and it got closed. But, oh yeah, we all use it all the time. So I think that’s another big source of where we find out what hurts the community.
Jowe: So it’s a kind of eating your own dog’s food.
Ben: oh yeah
Technical debt
Jowe: all right. So we’ve talked about all the contributions and issues. One thing, I think everyone in IT is affected, it’s the topic “technical debt”. What’s your strategy to deal with technical debts?
Ben: So I’m assuming you’re asking as a tech debt that you’re asking about technical debt. Yeah, so the technical debt is difficult on a library. This is widely used. Just what we have for example … look, there’s a couple parts of this one. We have a lot of tests over the entire breadth of everything that we’re doing. So if there’s tech debt within this utility library, which – it exists – but it’s fairly minimal. Ideally we can refactor something without having to change any tests. And if the tests still pass then we know that we didn’t break anything. So there’s that side of it. But the biggest and most important thing is making sure that whatever tech debt that we’re trying to fix is done in such a way that we’re not releasing a patch that’s going to break a million projects.
don’t break a million projects
Or something that, for example recently we had some tech debt on subject, which is one of the major types within RxJS. And what it was, we started working in RxJS or I started working on RxJS but way back when – I think – TypeScript 1.8 was the most popular version of TypeScript out, and TypeScript 2 or 2.1 was just being released. And it didn’t support certain features. So if you made a subject of void in order to call next, you had to pass undefined to it. And that made it unergonomic for some of Angular’s use cases. So we made the next … the value to next optional, even though it’s not actually optional. It was optional in TypeScript. It said “you don’t have to pass value here”. So if you made a subjective number, TypeScript will allow you to this day and version 6 to call next with no number passed to it.
And that’s actually incorrect. You can cause bugs, and you shouldn’t be able to do that. But it was a bit of tech debt. And it was tech debt because we had to wait for TypeScript to get to the point where … if you had a subjective void it automatically allowed you to call next without an argument, which it does now. So we had to go through, and we had to fix that. We had to fix it in a major version because if we were to fix that – even though it’s a bug in our types – if we were to fix that and publish it in a patch for version 6, or even a minor for version 6. Even though it’s a bug-fix, it would break so many people and so many builds that it would be untenable as a patch. So we had to make sure that we consider how many people are using this. Because it’s downloaded so many times per week and how many people will break. So it varies a little bit if it was my own personal project that I … oh no only, I see only like 12 downloads on. You know fine, we can publish a patch for the type change. And if it breaks all of 12 people. And maybe I get a nasty gram at some point.
getting up at 1 in the morning …
But if we publish something that breaks a lot of people. And I’ve done this in the past. Before any of these folks I think we’re even here. Like I start getting texts and messages and pinging at 1 in the morning from people who are noticing that their continuous integration bills are broken and they don’t know why. And then they figure out it’s RxJS. And then I have a meltdown. So if you need to make sure that we carefully consider every change that we make, especially those that we think are just tech debt or bug fixes. Because it’s such a widely used project it also means we have to move a lot slower. Because it’s used by so many folks.
Jowe: What’s been the situation and like the task? How did you resolve the meltdown you just mentioned? Why did you jump out at 1:00 in the morning? Coordinate like who is jumping on investigating, fixing the bug? How was this situation for you?
Ben: At that particular moment in time, honestly, it was no different than “what would happen if you’re on call at any other job”, right. I saw, oh my gosh, all the stuff happening. And basically I got up, washed my face, and went to a computer. And figured out what the issue was. Resolved it. And published another patch that fixed the bug. But it was embarrassing and difficult. And that stuff has happened early on. It happened a few times. But it hasn’t happened in a long time since.
Wonderful support net
Now we have wonderful folks that are helping us. So Michael-James Parsons and Christine Leg are at Google, Moshe also used to do this at Google, and I did it myself. I started this group at Google before I left. That are actually the people responsible for pulling in what’s an RxJS master into Google. And that means it gets run against thousands of targets. And we see if we broke anything. Where we broke people’s tests, or broke functionality. Or we broke people’s builds. And we get feedback about it before we publish a version to npm. So that’s been a big stopgap for preventing these sort of things from happening again.
Staying updated on RxJS
Jowe: So it’s already time I’m asking the last question. So the last question is from me and I’m interested like: What is your recommended resource when I want to keep updated on what’s going on with RxJS? About ongoing discussions, new releases. Would be the best source GitHub, the website, Twitter? What’s your recommendation, Tracy?
Tracy: What’s my recommendation for getting started?
Jowe: Just for getting and keep getting updated. Like a source of “I am interested in”: What are ongoing discussions? What’s discussed in the process right now? When are new releases happening?
Interested in contributing
Tracy: That’s difficult, a lot of these things are happening internally, right? For those people, who are interested in contributing … I don’t know if any of you guys else can. But you can always ping me on Twitter @ladyleet. And I can give you access to the Slack channel. The Slack channel is mainly for contributors. So if you’re really interested in contributing, and you kind of want to be able to start conversations about the contributions, then that is a great place to be. I think, for issues as well it’s a great place to be. We’ll randomly tweet out updates on Twitter as well. I don’t know if anybody else has any other suggestions.
Follow on Twitter + get in touch
Ben: One of the things I would suggest is following all these other folks you see here, who are not me (@ladyleet, @ncjamieson, @mkldny, @niklas_wortmann), on Twitter. I know that this is seriously everyone. Everyone here but me actually outputs a lot more content that’s RxJS related. As far as: What’s happening now? or like: What are new tools or different techniques? And that sort of thing. I think maybe I used to, and then got caught up with all sorts of other things or whatever. But that’s not the point. The point is that these other folks that are on this call, they output a tremendous amount of great material for you to follow. I will occasionally tweet something, like I’ll put up some issue or some pull requests. Some ideas that I have and ask for feedback, kind of thing. But I do that very rarely. And even actually going into this talk, I really really wanted to make sure that everybody heard from the brilliant folks on this team. Because frequently I feel like, whenever we do RxJS talks I end up blathering on for quite a bit about my perspectives on things. But everybody else here is putting out a phenomenal amount of material about this. Or they know where a lot of this amazing material is. So I would definitely follow them on Twitter and pay close attention to the things in the medium articles and the things that they put out on their blogs.
Tracy: Everybody’s pretty welcoming here. Reach out! We’re always happy to point you in the right direction. Or whatever level of contribution. So don’t stress.
Blogroll: our recommendations:
- Tracy Lee on medium
- Personal blog by Nicholas Jamieson
- Moshe Kolodny on GitHub
- Jan-Niklas Wortmann’s Blog
- official website of RxJS
Finale
Jowe: Right. Just hear some voices in my ear. Right now we’re a bit over time.
I would like to say thank you a lot to you Tracy, Nicholas, Moshe, and Ben, and Jan-Niklas for joining us from around the world. It’s been a pleasure!
I’m looking forward to watching the stream again, more focused on the answers. Because it’s pretty tough like having the document following up on the next questions, having the timings, and the voice in the ears.
Thank you very much! And yeah to all the others outside: Have a great day or night or a good morning! Bye-bye
Tracy: thank you for having us
Ben: Thank you!
Please support #RxJS by anonymously reporting your usage (click here to read how)!
Top comments (0)