Episode transcript

Ryan Burgess
Welcome to the second episode of Front End Happy Hour podcast where over drinks we discuss all things front end developments. For this week's episode, we're recording on site at Netflix with a special guests and lash, who's here to talk to us, RX js. And he's actually here tonight at Netflix talking to a large group for a meetup. Each episode, he choose a keyword that if it's mentioned, we will take a drink to that keyword. Last episode, we kind of missed a few. But we'll try and get a little better at this for this episode. If we do miss any call us out on Twitter, we're happy to hear it at @frontendHH. Before we dive in today's topic, let's go around the table and introduce each one of our panelists. give a brief introduction of who you are and what you do. Brian, you want to kick us off?

Brian Holt
Sure. I'm Brian Holt, and presently senior UI engineer.

Ryan Anklam
I'm Ryan Anklam. I'm also a UI engineer at Netflix. And also, one thing I think right that went off in the introduction is if you do call us out on Twitter, we do have stickers, and we will send some to people who call us out and get the number right.

Ryan Burgess
Good call.

Jem Young
I'm Jem Young. I'm also a senior UI engineer.

Ryan Burgess
I'm Ryan Burgess. I'm a UI engineering manager at Netflix, and thought I'd introduce our guests unless you want to do this little intro about yourself.

Ben Lesh
Oh, sure. I've Well, I'm also Wow. I'm also the project lead on RxJS 5, which is a redevelopment of RxJS.

Ryan Burgess
So I guess we need to decide what today's keyword is that we're going to take drinks to whatever we decide today is async and drink. All right on. That sounds good. So let's kick off today's topic and dive into RX js. How did you first get involved with RX

Ben Lesh
I first got involved with RX really when I started here at Netflix. My hiring manager design said oh, he knows anything about RX. He uses a lot of Netflix, you should learn this. I said okay, I wouldn't looked at it. And my honest thought the first time I saw RX was the hell is this another one? Why do I need another Lodash it was being used in our project, we had this Ember projects, it's pretty big app that does like real time visualizations of like Netflix club. And it really wasn't being used for anything other than we're getting some streaming data out of a WebSocket. And then he was kind of splitting it into a bunch of subjects that was kind of the end of RX for that app, like it didn't, wasn't really using it to its full potential, we started running into some serious performance issues. Because everything that was happening after that it was kind of taking these large arrays of data coming in with a WebSocket is dropping it. And then we had all this kind of functional programming, array manipulation. After that we're able to like map and then map it again and filter it and reduce it over here and over here somewhere else. And it was creating all these intermediary arrays that had to be garbage collected and was happening so often in the streaming data, that garbage collection was actually pulling the performance of the app. Well, it's crazy. That's crazy. It was I've never seen anything like that before. And that's what made me start investigating RX more. And I thought, well, I could use RX, more like a transducer in this way where I actually as the results come in, I processes one of each one of the records individually, kind of bring them closer to the front. So kind of connecting a wire from where I'm getting them from the WebSocket all the way up to the UI, right to the components that are that are dealing with the data, as opposed to, you know, dropping in some big stack array and so on. And, you know, it's all about one's issues. So that's, that's how I really got started with RX js as a user. As a developer of it. I originally, I had some interest in trying to figure out some sort of interrupt spec or different observable types for paging, or in most other things. And I was pulled aside by some folks from the reactive X community, namely Dr. sane and then Christiansen who was here at the time, Facebook, and Eric Meyer, and they're like, how are you interested in developing this development like trying to redevelop a verbal view a little bit faster and playing with this as a variable spec is now saying one that is only the people championing that disease? 39 cores and like, Yeah, that's great. I will I was a little bit like, Why me? Like why? Why do you mean, but it had to do with the fact that I had a lot of interest in the area. So that's, that's my origin story. As far as working on our awesome how much of your time actually like since it's not your full time job at FOC are working on are like how much time is spent actually working on RFCs? A lot, a lot there, I would say that there's some weeks, you know, here and that was where it was maybe 50% of what I was working on, there was maybe even a couple of weeks where I was 100% of what I was working on here. Yeah, no, Netflix is has really allowed me to partially because, um, you know, it benefits all of Netflix, afterward or x. But also, partially because the freedom to work. It really depends on kind of saying what my deliverables were for my team and how, you know, how urgent or, you know, there's, there's always a little bit of downtime here and there. And no matter where you work during this before we go any deeper, we should explain to everyone what are actually scribe RX and what it is. Yeah, what are the benefits of using RX? Well, I already said what is this another lodash. So that, that's what makes it different. It's, it's lodash, or AC, that's that's really the what it boils down to. It's all about a type called observable. an observable is a set type that gives you a set of values over time. So it basically gives you these values and that count is close enough. And, you know, we ever thought of a downside of having a guest here, you just, yeah, that's true. Like, you can literally just sit there and say this over and over. I really yeah, that's, that's the the basics of it. And so since you have a set, like any other set, you have all of these different combinators, or operators that you can use over like map, filter, reduce, zip, and that sort of thing. So it really that is shaped a lot like a lodash. But it's, again, a lodash for events are asynchronous. I think a really good website, I had to try to visualize our x versus RX marbles.com. And that's a really good way to visualize these reactive streams and how these annotated forms. Yeah, absolutely. That's, that's a really cool actually, the the RX marbles, we've kind of worked that same thing into our integration tests for our GS five. So our integration tests, now I'll have these sort of ASCII art looking marble diagrams that we use to set up our tests, which is kind of vertically aligned, to see what you think is supposed to happen. And verify that as opposed to having to write some really wonky code that says, you know, you know, emit this value at this timestamp, this value of this timestamp? And then you're able to just kind of use this little marvel ASCII DSL thing to create a, an observable, zoomies. zerbies. A lot on here. Oh, yeah. In fact, in the talking, I'm doing live tonight, I'm going to have a couple slides up about that, specifically, just showing up. Here's a side when we got out of this whole idea was Andre Stoltz came up with that idea. And I believe he's gonna do it work on RX marbles. And then I had the fun part that I implemented it. So I was, I was pretty pumped when I got it working. But yeah, it's it's 20 lines of code to test, you know, hey, how am I gonna merge seven different observables with some operator versus, you know, 100 lines of code, merge three observables as an operator, it's pretty, it's drastically different. And it's much, much better to read any, anybody can come in with some limited training on what the what the actual marble diagram, I mean, look at it, like, Oh, I get what this is, you know, and I can visually see how the values are lining up. So that's, that's a big one. And we're actually I want to, it's already being exported the tools necessary to test your code this way, but I kinda like to have a separate NPM package. And I'll be doing that here next week to allow end users to use the same techniques to integrate integration tests on their, on their arm. So, yeah. So promises are just browsers and people are just not getting around to it. You guys can get them games. But what's their fate of promise? Observables? Like, a different difference. So the primary differences are that promises are one value observables are any number of values in both asynchronous? Yes, they are both. So yeah, it's it's a promises a read only immutable feature value, where an observable is more of a function that sets up listening for future values. So you in that, like a function can be called over. If whatever it's doing fails, if you have a handle to a function, you just call the function again, same thing with observables. If an observable, an observable fails, or completes, and you want to do it again, you can literally just subscribe to it again, is there. So promises on the other hand, they can't be retried or replayed. That's one minor disadvantage. The nice thing about promises is promises have that feature guarantee like if you have someone give you a promise, you're roughly guaranteed unless you know your code does very poorly, that it's either going to resolve or the that actually becomes more of a foot gun. And you're talking about modern web apps, which are frequently single page. So you'll go to a view and you'll leave a different view. And what happens if you're using a promise API, and you're saying, Oh, go get this Ajax data for my first view. It says, okay, it goes and fires this request. And then before the request comes back, you decide, yeah, I don't care about that, I'm going to go back to some other view, that promise is still going to resolve and when it resolves, is probably going to take this, this JSON, whatever is coming out with a AJAX request, and it's going to parse that into an object. And then after that, you'll see, it'll hit some signal that says, I no longer care about this disinterest. And what that does is it actually blocks your thread while it's parsing that JSON. So you know, that's, that's not really desirable in anybody's app, especially on an app, maybe like, on a resource constrained devices, older smartphone or these smart TVs. So an observable, on the other hand is cancelable. So when you subscribe to it gives you a subscription, when you call unsubscribe Message version, and it will call some tear down that was defined in your resume. And with that teardown logic, you can do things like abort your x HR, your abort your AJAX request. So it doesn't, it's not even that it's like, Oh, I'm just interested in what's coming back. It's saying whatever's coming back, I'm not going to handle it. So it gives him a new processing. In that regard, I think that observable is a little bit better type for most situations, especially when you factor in all the composability with all the various operators and seen that one of the like, big advantages of observables is being able to handle it. What if promises was had the ability to do that? Would you still need observables? See, now, once again, I'll go back and see one of the nicest things about promises. Actually, it's even called a promise, right? Saying, I promise you that I will did it will do so and they're immutable. Yeah. Now, if I was to suddenly make up on this cancelable, is it still a promise, right? Like, it could be any lie. So it's, it's it at that point, you know, what happens? And then there's some, like, I think that the spec is it for a canceled promise that if you have a promise, and it does resolve, and then does resolve, and then later you cancel it, and you then try to then offer it again, you still get the value back? But to me, that's a little bit confusing. Like what does that really mean? Canceling Promises, promises of value. Cancelled? Was that no, it's a good point. Yeah. It's just been super vague. Yeah, and I don't know if, if that's a result of, oh, jeez, there's this observable type now that supports this, and people are using it a little bit more, because it's a slightly better fit for, you know, a lot of the web UI use cases, and we should implement something like this, you know, so people want this type more again, like if it's like some sort of reaction to having this this cancelable typing observable? I hope not because I really think it has monies that I would have it promises have their place, just that. They're not like they're not the best solution for everything.

Brian Holt
So I recently gave a talk called promise not to use promises, which is just a giant troll, right? I was just trying to get people to come to the talk. But it was about observables. And in the talk, I railed on promises quite a bit, just not for not being very effective methods of flow control, right? Like, chaining promises together to try and get this basic, this simulated flow controller working pretty well get out of cervicals. It's not not a great idea. And Kyle Simpson pulled me aside afterwards, he said, you're totally missing houses. Someone, first of all, he went to Toronto, why cancel promises are a terrible idea, which is, I tend to agree with that very reason. But promises are just that they're the promises of future values. And it's pretty powerful to be able to call a MPM module or something like that, hit a promise, and then pass it around as you want to have that promise of future value. And then later, when you need something like flow control, you have symbols or CSP or something like that something that was so just like that was totally agree that they're not scratches, image promises, and observables serve different purposes. And you can kind of use one to model the other imperfect abstraction. Right? I mean, promises I think, also have some use in like data iterator type situation where you want some sort of back pressure control with individual values and the back pressure control their course, is because iterators are lazy. And, you know, promises are async values, so.

Ben Lesh
So you would, you would then, you know, say next, and then it's going to give you a promise, and you wait for that to resolve and resolve in three to handle that. So you can get backed up on that on the client side of that the same time, you could have iterator of observable, right? And that's a little bit because observable isn't having you a backpressure. It's just going to push values at you. RX Java observables. Do you have that, but they're starting to call that global pipe? I think Allen RX Java two. But what you can do for backpressure, there is you can say, well, what if I want 100 values pushed at me at a time, so I don't have that extra object allocation of a promise every single turn. You could do that with an iterator of observable, right? You could say, Here's my iterator, you could have some generator that that's every time it next out gives you an observable of 100 things and just called out over and over. So this would work basically the same way. It's just, it's your allocations return. And it's important to note, like promises aren't going anywhere. ServiceWorker API is used as demos is essentially async await. Yeah. Yeah, so promises aren't going anywhere. Observables are amazing, but it's probably good. iterators Yeah, you did. Well, the thoughts important is important. That's coming forward. And it's going to be me pretty much if you go through this async iterators they're pretty awesome. Thanks for me that last time, the word tools and it came up more than talking about that. Yeah. So my main problem with promises are and I'm sure we've all dealt with this is air swallow. You know, I don't know if you guys are run into this but anybody's on any houses where it throws an error, but it just leads back to the homeless, not actually with air came home and it's aggravating as hell go on Twitter and look for it and you'll see people's blowing up about it. How does the rules versus the RS Jack's handle that? Because arts in observable have like a terminus to chaining so if you chain like map map map, and you know, the very end, you actually have to help us arrive. And because of that there's an actual Terminus to chain where with the promise is then then then then any call to then isn't necessarily the last call to then you can't really tell where that's headed. In observable, you know where it's ended, which is at the subscribe call in there. If there's an error that's not handled, it will just throw so they'll actually like dump right you can go to like window on air or, or whatever and actually do global air handling. And that's not true. Unfortunately, unless you go hooking to whatever this special On your, or whatever different for node versus, versus the browsers on Chrome has now shipped with a house. Yeah, I've used, it's kind of the opposite. Yeah. Think about the implications of that, though. Like, you need a special debugger is needed. Yeah, definitely. Right. It's it's a thing in, I don't know, actually, we ran a really interesting bug in our x, or it has a process. So you can convert a promise to an observable. And there's a call to from with a promise, or you can even use from promise the same. But what happens is you how this works. Whenever you say, give me an observable from this promise, then you subscribe to it, you actually air in your next handler, that next handler actually occurs synchronously within the then block of your promise. Because the internals of what this has to do like when you're converting a promise to an observable says, okay, return a new observable, then call promise dot then and inside of the then block, pass whatever value that you've gotten from your promises, then into the next handler, or your observable, right. And then that propagates on out. And if you do a bunch of synchronous stuff on the way out, and then subscribe, and in your subscription, you throw an error in your next handler, that next handler technically synchronously occurs within your then block props, which then traps it right. And never never actually go with those. So it's, it's just a really, what is a really interesting bug in the workaround there was to say, Oh, well, I'm going to put a try catch inside of my then. And then throw it like on the next micro Tasker vote on the next set timeout or something so I can actually escape out of the air trap of promises. Yeah. It's very confusing. Imagine, you're like, Oh, well, I've got all of this code. And I'm merging different variables, and the one observable happens to come from some promise. And then you've got all this change, you know, this chain stuff in there and error happens and like, you don't get any notification that there's happened at all. There's no rhyme or reason to it. I think one of the pain points. Alright, so this is pretty easy. Things, because I think you guys are doing easier in Yeah, the newest version of our x. So the older versions of our x defaulted to trample scheduling. And what that is, is it says, Oh, well, I'm just going to assume that in any moment, someone could do something that's going to blow the stack, all sorts of things. So what it does is it says, oh, every time I'm going to next out of value, I'm going to schedule that to happen in in the same frame. But you know, as kind of the next call is going to sip it over the same thing. It's like a micro task schedule. Only before that it's actually happening in the same. And what happens whenever you do scheduling in any sort, is you take your call stack that you're used to looking at, and you actually are knocking it over to the next line. So you kind of miss some context in there, particularly when it's not on like a micro test schedule is Chrome, I don't even pick up the AC testing checkbox. So the idea there is to try to make sure that we're limiting the number of function calls and also reducing recursive scheduling by default recursive scheduling is no more it sounds fancier than is basically just means that you're calling functions from within functions that you normally would. So if I say hey, do this now it literally does this like now as soon as it can execute. scheduled for next day. So we've talked a lot about like observables obviously, the really big important thing RX, what other features do you get by using? Something like lodash? Doesn't? Um, well, I mean, the biggest thing is observables. Since variables can be any number of values or any amount of time, and they can set up and they can embody the setup and the tear down of any producer. They can really be used to model just about anything you could want to model and basically, I don't know that that's a good idea. That's a possibility. Right? It's totally if you could literally have an application that was just a big observable that he's subscribed to and inside of there, it was splitting off into like subscribing a bunch to a bunch of other variables and flat mappings and actually write an application like that. I've seen stuff like that, since getting logged in ArcGIS. I think it's a little nutty. But that's what people want to do. I mean, it's pretty cool. But it's like, wow, I don't know how many people would be able to maintain this. Yeah, that you get that. And, you know, you're not going to be able to do that with lodash as synchronously dealing with iterable type objects. And because of that, there's no, there's no temporal nature of anything to do with those sorts of things, there's always going to be dealing with synchronous values that already exists in some in some array or some construct by the time you get it, where, you know, this is dealing with sets of things observables deal with sets of things that might not have even happened. So that's a really powerful tool, it also means that you have a lot more operators, right. So when you're, when you're dealing with a basically a one dimensional set, it's got length, and it's always going to be the same size, basically, you've got a certain number of operators, but when you're all of a sudden dealing with a two dimensional set, which is not only does it have length, but it has time involved, the ways that you can kind of wrap your head around that are, are much different. So for example, like both of those things have taken like I can take five of these apps, right? But not like you can't do buffer with both of them. Right? Like, because buffer has like the idea. I mean, I don't know how it works with a synchronous set buffering, good for you two hearts or something. Buffer buffering has the idea of some sort of temporal sort of passage of time, like over time, take these values and add them into some buffer. You know, that's just one example. But there's so many more ways that you could utilize interval as opposed to push just have a lot? How would someone like I know, Ryan actually brought up a good site for looking at some of the documentation. But what do you recommend for someone like fresh into RX wants to get like started, what's, how do they get started? I honestly, I would get started the same way people get started with promises, which is try not to worry too much about all the fancy operators yet, like, just take some take some async thing in your app, and rapid rapid in an observable, and subscribe to it and use it use it inherently at first. And then, you know, take advantage of the fact that you can now unsubscribe nothing later. And then as time goes on, you know, get more into like the map and the filter, and especially the merging hat switch, pipe operators, all of your merge strategy operators, because once you get into that, then you're really able to start chaining these, chaining the variables together and getting some really powerful stuff together. Like if your thing the other thing too, is to look at really complicated. hazing activities like dealing with brush selection, or dealing dealing with brush selection or dealing with maybe drag and drop. Multiplex WebSockets like anything where this is, this is actually kind of a complicated activity, that deal with multiple forms of events and trying to like, piece those together is a good good chance to try to do that to start with just using imperatively just see how it works, subscribe to an observable things subscription, you know, unsubscribe or dispose of it when you're supposed to and and go from there. And observables are making the waves a pretty popular libraries framework. Angular two is then using a lot of RSI. So it's a lot of if you even go on Stack Overflow, most of the questions around RX now are very angular centric. Promises. A lot of options. One using houses everywhere. When actually you're probably if they influence on annual observables Yeah, for Angular. Yeah, I have some friends in the team and I, you know, kind of gave him the sales pitch. And they didn't bite so then I took chaufeur there. For those of you who have never heard John Krasinski, he is the used car salesman of He's very, he's very good. Like he's very. I don't even know how to describe it. I think that's sufficient. Yeah. So yeah, I six drop around. And then there was there was obviously some online discussion, unity and trying to convince folks there. One interesting thing is kind of their main czar of that on the Angular team now Rob warm all originally, he was like, this is a stupid idea. Why not use? I swear, that's a real thing. And you know, there's like a, a Google group back and forth between him and I about, you know, here's why observables. implementation using RX five, RX five observable. It's the same symbol. Yeah. Just say.

Jem Young
So I've heard rumors. So Angular two, using the rules, I've heard rumors that react in the future is going to serve as well. So I don't think that's true, really, from sort of.

Brian Holt
So when I was at React Rally, which is, isn't it? He's out there talking to me right now. Yeah.

Ben Lesh
He's standing right outside the room right now doing the cutthroat. Like,

Ryan Burgess
Jem, you're not supposed to mention your confidence.

Brian Holt
What I what I've been hearing, the reacting is the moving less and less, are being truly reactive, which is ironic, given the name, and being more into scheduling rather than being reactive.

Ryan Burgess
I heard and you heard that at React, rally palsar React router.

Jem Young
That was my view. And he told the truth. He obviously, is really funny, because both you guys spoke about seeing this direction. Yeah. That's not so bad. I do think that frameworks. I mean, I know that rendering library. I agree with you there. It is, like, it's, I think you're splitting hairs either way. Yeah, I think that I think that they do need to invest a little bit in scheduling because we've had issues and our React react apps, our team where we were, we were, we had multiple events that were updating, like state icon set state back to back really quickly, either on separate micro tasks or just even synchronously, like right there. And it was actually causing, like, multiple re renders. So we had to implement our own scheduling. It was like, Oh, well, when you call set state, actually just on this next micro task to do it, and then patch all these things like otherwise, it was really kind of becoming an element or performance or apps. Oh, yes. Good. Yeah, definitely. So I had a shower thought. Please, please explain your shower. Tag, just not or Yeah, at the end of the episode is always like, what's gems feet like latest showers off the shower? Got the radio voice? Gems shower. From the shower gel. Like I'll be watching live. I'm not joining you in the shower. We just do like shower some as February so you know you're in the shower. Yeah. Yeah, you're not think about anything but observable, like the the chaining function is very, very emotional, obviously. So then I'll see the rise, but it has to be years of functional versus auditory. You think observable coincides with the rest of functional programming or this like, independent thing? That's I think right now observable is driving a lot of functional programming. I don't know that. Oh, no, that one cause the other the whole I think the entire birth of observable for RX JS anyways. Has to do with this. I was talking with Matt Thomas Zeki actually has to do with a project and I forget what it was called. But it was a project at Microsoft to make C sharp compile into JavaScript. So they wanted Yeah, isn't it like it's a failed project now I think but the so they wanted you know, all of these types as compilation targets for C sharp and C sharp had RX dotnet. And so why not, or exactly the same thing over to arch Jas. So we have this compilation. So like that clearly, if that's the case, Can that type of observable, you know, this is seven years ago, doesn't really have much to do with the rise of functional programming. But you know, the popularity of it? Certainly certain? It I don't know, it seems it seems like the whole functional versus imperative type programming right now it's getting more tribal than it used to be like, I feel like people who really liked imperative programming, find functional programming or observable types is a bit threatening, and maybe it's just because I'm on, like, the front lines of that are I like, publicly know that I have something to do with that. So I get more of it tossed my direction, which I've kind of shrug my shoulders at Anjali, like, program, I'll be like, but yeah, it's i, this seems kind of orthogonal, that you're right. And what's the greatest Microsoft, a finger access, like they still do anything? Are they just like, boom, that message is that there haven't been a lot of, there's kind of, there's been a couple of contributions to ArcGIS. Five. But a lot of it has been just me coordinating with with Matt of Iseki. And that sort of thing. Now, Microsoft's TypeScript team is actually been helping me out recently, because RCS five is written in TypeScript. And we do hit some interesting boundaries with the structural typing that he uses, as far as the typings that are coming out of Ahrefs slowing down build times. So we've gotten some fixes from them around that they've also helped us push through a couple of features and types of support RX, RX fives operator patching that we do, which is a modularity benefit thing. What that is, is to, to give you the short version is people don't really like the idea of having every operator on observable because that means they use observable and like two operators at the bringing all the rest for like their handle. So what we can do instead is say, import observable, now import RX add operator map. And it actually, that just the act of implementing that will patch the vertifight monitors, which is it's both cool and gross at the same time. I'm not a huge fan of that. But it sounds very. It sounds like movies me. The other thing, the way I'm a bit I'm a bigger fan of actually importing observable and then importing the map method directly. And then with Babel, you can use the Yes, yes. It's like stage one function binding proposal, you can actually use that in Babel. So you can just be like observable, my observable colon colon map, and it just doesn't just eat sugars do not call observable. And so I like that much better, because it doesn't make me feel dirty about mutating the prototype monitor a little thing. I love shut your mouth. Yeah, it does look nice, though, in the code like to see, it was weird. Oh, I actually think it looks clean. And you're like, it makes a lot of sense. We should have another podcast just just a feature.

Ryan Burgess
Well, I like the bands on my side, so called band on the next I like I like the I like the pipe operator proposal to I mean, if there's a world where if let's say pipe operator made it, I could see an argument for actually making observable just functions. If you had, if you're like, here's my function, and it takes an observer. And that's all the observable really shakes out to hit with a pipe operator, your nap or your map operator, your map function would be like map and then the first argument would be your source observable. And then every argument after that would be the normal arguments you'd have for math. And that basically means that you can be like my observable height, math, and then your production, or whatever, it ends up being very clean. And now you don't even need an observable type, you could actually just have observable V function, because there's no there's there's no need to have to put anything out of that chain. Now, the part about that doesn't quite work out is you still need to have the ability to make an observable into a subject. So indexing in that but so the second piece to that would be get pipe operator, and you can subclass function. You can do now, hidden about the sub classing function, melt people's brains. But if you can do those two things, I could see a totally different shapes down the road, where now, you don't necessarily need an observable fact that afternoon cc 39, you would however, need some sort of observers, because observer provide certain amounts of safety like, you know, it's not just that you can next err and complete, you shouldn't be allowed to next after. And so there's there's a certain amount of nuance to the observer, as you're passing into it. That needs to be provided all of those things out. I haven't been teacher JavaScript. Yeah, I've been pushing for objects, those are observed for house stall. Yeah. And actually gone. When can we expect to see RX? Gs five? Production, I'd like to have it release in the next three to four weeks. That really, it's pretty stable right now. The real real thing is that there's documentation. There's some minor organizational things where right now, Ajax and WebSocket functionalities included in the core package, and we want to foster that in the same repository flows. But you can actually like specifically call them it's really some IRA, it doesn't really matter that we're bringing it out. Like we're, you know, sending those out with the same package. Not really, but surely. So that's, that's the big game. There's a there's a couple of little bucks here and there, but expect us to have production is mostly production ready? Right? Yeah, he is. Or I'm sure our listeners are like, hey, when can I jump on using it? Yeah, it's honestly, it's pretty safe to jump on using it now. That shaved off a minor issue. I guess you have one less question about anything.

Brian Holt
Drink your water.

Ryan Burgess
Then is Ben is drinking water tonight, is he actually? He's about to do a talk on RX js at Netflix tonight. So he's got a bit of a cold. Yeah, I was I was really sick. Like no other route. Yeah, that makes a lot of sense. But you were still able to join us, which is amazing. So yeah, finish her off with the last question. So you might be walking into something you just keep your hand off.

Jem Young
What are your thoughts on my class?

Ben Lesh
Well, I mean, if you look at our excess lives are so there we last everywhere. I think that a lot of people are very up in arms about class or no class, like, Much Ado About Nothing, doesn't really matter. Here's the thing, most of the engines are optimized for you to use classes. So if if using classes inside of your library gives you some benefit, either, organizationally, because you're used to doing like C sharp or Java type programming, or performance wise, because you're trying to optimize for running things in V eight or something, then use classes. I mean, you know, I think that using classes for like an external API isn't always that great. For example, if I was to give you like, here's my food class, and you want to do something with it every time you want to do some new food and the problem with that is it breaks things a little bit of functional programming, because you no longer use all apply, they don't work properly on your on your this instructor option. So in that regard, you know, all of the classes that I have generally have like a create static create function on them that does the work of Newing up the value or just as the I've gotten on these. I do have a question too. We've been talking about observables this whole time, but I know you've been investigating other async types. So what can you tell us about other async types that you've investigated? Look, do you like not like just asking this because you know, you're gonna have to finish that you're thirsty. So I mean, there's there are, there are some really, there's some really interesting ones out there. Yehuda Katz has one called gremlins. And what that is, is it actually exists as like a screen type in Ember, but only some form of it does. And what that is, is it, you subscribe to it and it pushes, pushes notifications at you that something has changed. But in order to get the value, you actually have to get so like the act of getting the value is lazy. But the notification that I just changed is, is pushed. And so that was pretty interesting. The reason I was interesting is if you're in a situation where, say, some processes and updating a value very, very quickly, maybe via mouse movements or something like that, but you want to render in RequestAnimationFrame, then you can say, oh, we'll signal a signal that something has changed, no matter how many times a signal that sends change, I'm only going to actually get the value and you know, possibly a few things up some chain one time exactly what I needed. So that's a kind of an interesting one. The other one is the RX, global type, which is like the RX Java, RX, Java one, and RX Java to hold our global. And what that is, is an observable, exactly the same shape as observable with one additional event that happens when you subscribe, and onStart event and it gives you the subscription. And then you're required to request a certain number of values. So you say I request 200 values, and it goes up to your producer and says, Give me 200 values, and then it pushes 200 values at you just like an observable. And that was really cool for like high speed back pressure scenarios where it's not, it's not so much that oh, I'm not sure if I can process this at every turn. It's more like I know, I can process a lot but I need some back pressure control. And you don't want to allocate a bunch of objects where then the other one, which is the iterator promise is going to allocate a promise or every single time. So those are those are the biggest ones that I know. Those are those are the biggest ones. I know that I find very interesting channels are another interesting one, which is like the CSP those and I think the reference types are they end up resulting in much more imperative info, dealing with channels, partially because channels have this sort of, like get sort of where you, you're actually calling out, put this across here and then a wait, get this other things, you know, Scott, like had dental, it's not really a promise. I think it's like a reusable animal that just promise shakes. But that's another interesting one, for some reason, people keep taking that one. So what do you think CSP or RX? Cares? Running go, yeah, it's thick ones necessarily better than the other channels have a nice two way. indication. But you know, at the cost of writing code in a more imperative manner. Well, I guess you can end the episode. Thanks so much for joining us in pleasure having you. Again, the episode we've been doing picks where we just choose certain picks that things that either code related or anything that we've just been enjoying that we want to share. So yeah, we'll go around the table and share those picks. Ryan, you wanna start off? Yeah, I want to say about my last weekend, last weekend, I saw on Hacker News, there's a game called Factorio, just like Sim City, but you kind of like build a factory and is just it's cracked my engineering brain that like managing all these logistics and creating these products, then feed into other products that then feed into other products, the observable and it's, it's really fun, but venture in your own risk because you will lose a whole weekend. Sure, learning as you go. You're not You're not learning. Right. Okay, so my first pick is the fin casts website. So if you're them curious and learning them, these are small, little digestible snippets of knowledge. And I still go through them a lot. I transition them and the second one is the reading player one audio book, read the book itself. I highly, highly So this is an audio book read by will be amazing. So that's a great book, you'll get. My picks this week is the ECMO script proposals journal page, which everybody if your job from engineering should go there just like look at it every once in a while see what's coming up with some typos. It's good to say, how are you getting this error? Not that you shouldn't be watching me? Oh, that's what I do. Yeah, there's a lot of noise on it like meaning that there's like a lot of comments or requests and issues and things like that. But that's how I stay abreast of what's going on. And I talked to Jaffer, and he just possibly your office is awesome. Yeah, you get a lot of knowledge just by Oh, yeah, definitely. venue. Yeah, I would recommend that people go check out Egghead io, or at all interested in RX, there's a lot of there's a lot of video content out there. And most of which is free, a good chunk industry. Actually, there is one video that I actually did for them this last week that they released is about 15 minutes long. And it shows how to build an observable, starting with just a function that takes an observer, so it goes from there, and then ends up actually with an observable class. And it's pretty functional. I don't don't recommend taking that code and actually using it as oh, here's my lesson. It's okay. Don't do that. But you're just demonstrating basically what the observable actually is. Right? Yeah. And the goal there is to help people have a deeper understanding what observable actually, that's awesome. And that's, that's totally free.

Ryan Burgess
Yeah, that's really cool. So for my picks, I actually wanted to pick one for the Netflix UI, engineering YouTube channel, especially since then it's eating tonight. The video will be up on YouTube at some point, but all of our talks are up there. So definitely a good one to check out for previous talks that we've done, you know, and actually, he did not want to fluence as well as anyone caught that, but it was really good. And then my second pick is the Amazon Echo. I was a little skeptical on it. At first, my wife caught it, actually, she really wanted it. And it's pretty badass, the speaker and it's really good. And it's interesting to just integrate with, like different things around the house. He was like if this and that. Yeah, it's pretty cool. You got some hacky products? Yeah, definitely some good hacky projects.

Brian Holt
There's an X Reddit Slack channel for everyone that used to work at it. And one of my ex co workers has a Alexa trigger, says, Alexa, tell Brian, what's up and it puts into the Slack channel. Brian, you suck.

Ryan Burgess
That's an amazing one. It's pretty funny. So should I go home and create one for that?

Brian Holt
Yes, you could be trolled across multiple Slack channels. I was at Jusco Henry's house around Christmas time. He's he's got it created. And he was like, watch this. Alexa, turn on the Christmas tree and the Christmas tree. We have gotten to that point where that leaves you reach to plug in. Right. Right, right. Yeah. Why do you just tell someone else? If you have a friend named Alexa turn on the Amazon Yeah, I think you can change the name but I feel like Amazon's probably chosen a name that's very abstracted. Not a lot of people have but who knows? I don't know any Alexa. But you can change this to just be Amazon. Alexa, I can't change a customer. It's only Amazon. Ben, thank you so much for joining us on today's episode. We appreciate you taking the time to speak with us. Well, that's it for our second episode. If you'd like to hear more, follow us on Twitter at @frontendhh. If you'd like to learn more from Ben about RX js, follow him on Twitter at Ben Lesh. Thank you very much.