JS Party #191 Live!

And if you haven't hit request, you can see a massive countdown. Oh yeah, okay, hello internet. Now I think they're still counting down earlier. Uh-oh, oh, dear, we lost. Hey, can you hear us? Yeah, cool, sorry about that. It made me refresh. So, ah, okay, uh. And it looks like we're live on YouTube. Hurray, hello YouTube, hello from the dungeon. As apparently my background looks like. It's like 90 degrees in Massachusetts, and I have like no air conditioning, so that's brutal. The internet can watch beads of sweat form on my bridge, and I'm like, wipe it and try to look cool, you know, okay? Any questions before we get started? Nope, okay. Well, you're starting to really pixel out. That tends to happen, to some people. Jared, specifically for me, when, when we start recording, but I think the audio will be okay. And you're recording locally, if you haven't started locally. Twice, in fact, once on my H4 that I could not get to connect, and once on my laptop just in case.

Nice, okay. And then I'm gonna play when we, I'm gonna play the intro song and then I'll kind of do introductions and we'll, we'll kick off from in there, all right, oh so, Nick, actually super quick. I'm really interested in. Like hearing a little bit of David's backstory. And like the origin story for the project, like how it got started, what was like the inspiration behind it. And from my understanding, like it uses like a spec that's like really old for state machines. And so I'd love to kind of, like, get into that as well, maybe for the first segment. Yeah, I think that's great. I kind of had on the sheet to, like, talk about state machines in general. And I think that's just a perfect place to start. And maybe starting with, with David's background and getting into that, so, yeah, yeah, it's perfect, because David, all I know about you is you worked in Microsoft and you didn't really hit my radar until this project.

So curious to learn about what, what else you've been up to? Sure? Not that's a bad thing, obviously. No, it's all good. My radars, not a bar, all right. Any other questions, or? I'll go ahead and hit the intro cool, let me take that live and [Music] [Applause] Hello Internet. Welcome to JS Party. I'm your host this week. Nick Neesey Ahoy Hoy and I am joined by two wonderful co-panelists. KBALL what's up, K-ball? Oh, good to be back. Hello everyone welcome. We're happy to have you back. And I'm also joined by Amel Amell. How's it going? Hello, hello, I'm having a fangirl moment so I'll have to restrain myself today. Absolutely, I think we all are. It's a very exciting podcast. Today, today we are talking to David Khourshid, David, how's it going? Going good, how are you all doing? Fantastic? And we are talking about you and your fantastic project XState.

Play from 0:00

And so, why don't we kick off, learning a little bit more about you? Tell us, tell us what's up, sure? So, I, you might have noticed my screen name, David K. Piano. The piano is not my last name, as you probably surmised, I. I went to college for a piano and then discovered that doing web development actually pays a lot more than playing piano. So I sort of switched fields, went into that, and yeah, so you know, I started at a startup, you know, as a junior developer, and, it was like the startup where there were just all these crazy workflows and multi-part forms. And like one of those things where, like, you would click a checkbox and then a certain field would show unless this other checkbox was clicked. Then you have to do this and you might go to a different step, etc. And that was just really confusing to me as a junior developer. So I'm like, there's, there's got to be a better pattern for doing all this. So I, I was doing some research and I, I actually just stumbled upon state machines.

So it's nothing that I learned at university, like a lot of other, you know, developers might have learned. It's just like, Wow, this is a nice visual language, and I'm a visual learner. And as a musician like, that's important too, because you have sheet music, which is a visual way of representing, like what you're supposed to play. And so, I was like, Hey, I really dig this visual language. Let's uh. You know, dig more into it and actually find out why it's not more popular today. And so, fast forward a few years. I decided to just put all my learnings into what at the time was a toy project. I, I actually called it estado, like the Spanish word for estate, but I eventually changed that name and so that toy project had all of seven GitHub stars. For many years, until I actually decided to give a conference talk about it. And yeah, so it became XState. And, here we are a lot.

I, I have a lot of really good contributors, working on it, and you know, I'm just really excited. Like, where it's gotten to right now, and you know where it's going to be in the future. Before we dive into it, I'm curious to hear more about piano. Do you still play a lot? I know multiple developers who development is like their, it's their equivalent of serving tables, right? It's how they pay their way for their either professional music or professional, theater, or whatever it is, career. So are you still going strong on the piano? Yeah, I am in fact my pianist right here, actually, I mean, the piano is actually over there, but I have a Lego piano right there. Very tiny. Yeah, yeah, yeah, it is playable actually. But yeah, from time to time I still perform, you know, just at small, like, concerts, things like that. So, yeah, try to keep it up, that's very cool. And is there any kind of correlation between, instruments like that and state machines now that you've really dug into those?

I would say the only correlation is the fact that, like what I talked about sheet music, a visual representation of like you. You have notes and bar lines and like, just a really limited set of notation for expressing a huge variety of music, like centuries worth of music. And I'm like, Okay, is there any sort of visual, you know, whatever it's called visual formalism that exists for application logic in the same way. And so I think that's the connection, like just state machines and statecharts can really describe not everything, but almost everything, yeah. Okay, so I'm like, really digging this analogy. And I don't consider myself like a state machine nerd, because, like I, I'm very familiar with people who really love nerding out about state machines. And a lot of my state machine nerd. Friends who happen to also write JavaScript for a living, love XState, and I'll share some interesting back stories later.

But this kind of analogy of, like the state machine needing a visual representation and how it's similar to sheet music. And if you really think about an orchestra, I mean it is this giant kind of state machine. Between multiple musicians that need to coordinate events and activities in a synchronized fashion, you know, for some a set duration of time, and so, I mean, it's it really is a very interesting analogy. And I think, like, your background and your story is just like one small example of, like, why? Diversity in tech is super important, not just age and race and ableism. A bit like, literally, like, what did you do before this job? You know what I mean, like, that unique perspective that you bring? It's just, you know, it shows in the way you approach problem solving.

Play from 4:00

And so, you know, we're really lucky to have you, and yeah, glad you picked this profession to help pay your bills, because, you know, yeah, thank you. Yeah, so, before we dig too far in, maybe let's take a step back and define what a state machine is, so state machine. It's one of those things that sounds really, really complicated, and it's like, Oh my, I need to go get a CS degree or something, in order to really understand it. But as scary as it sounds, it's actually pretty simple. A state machine is like, you could describe something like even a human. Let's use me as an example as being in one of a finite number of states, and I can't be in more than one of these finite states at a time. And so an example of a finite state would be sleeping or awake. I'm either sleeping or awake. I can't be both sleeping and awake.

Otherwise, I have to go see a doctor and deal with that whole thing. Don't want to do that so I could only be in one of those. States and I could also transition between sleeping and awake, so if my alarm goes up, hopefully I go from the sleeping to the awake. States. And so what finite states really are behaviors, and by behaviors, I mean how you or how some entity reacts to events. So I'm going to React differently to events when I'm sleeping versus when I'm awake. And so finite state machines are just a collection of those behaviors of or finite states and events that come in. So, a more practical example, I mean, this is JS party, after all. So, like, let's talk promises. And fetching data like you're either loading data or the data loaded, or there's an error, but you're not going to have more than one of those happen at the same time.

You can't get both error and success, or you can't get both loading and error. And the problem today is that there's lots of applications where they do that. Like, I'm sure you've run into an application where it's like this loading spinner. I know my internet's fast, but this loading spinner has been going on for like two minutes now. I'm pretty sure there's an error, but it's just not going to tell me. It's going to show the loading spinner indefinitely. So problems like that are solved by C machines where that's impossible. You can't be both in an air state, in the loading state, you have to be in one of those. So wait a second, David, have you? Are you not familiar with a tiny little project called GraphQL? I feel like GraphQL has like broken all the rules there, you know? I mean, you can get your success response, you can get partial response and you get a list of your errors.

And, of course, like, zero respect for HTTP codes. You know, and everything is a post and like, what the f, you know? So like, I mean, you know, I love GraphQL, but like, you know, some things about the spec are really bothersome. To my heart. GraphQL is highlighting David's point, right? So yeah, the web in general, like anything on the web, people will say like, Hey, can this happen? Hey, it's the web, anything could happen. You could ask for things in order they could come back out of. Order all these other things. And what the state machine lets you do is like, collapse that infinity down to a few manageable states. You can think about, right, some determinism, right, you want determinism. Yeah, so then you use like, word finite, and does that? Is that just synonymous with state machine? Like, if you're talking about a state machine, is it always a finite state machine?

And does the word finite mean there's a finite number of states? Or there's a finite number of states I can be in at once? So finite is basically how you organize all of the possible, you know, states that your application can be in. And so it's. It's more of a communication mechanism than reality. Because obviously in this world, like, you know, there's infinite number of, you know, different states that things can be in. But like, finite is just for, you know, grouping. So, for example, sleeping versus awake, like my body is still the same number of cells, it's just that some are down to sleep. I don't know how I didn't take anatomy so like, however, the body works. But yeah, it's just that we discreetly define sleeping and awake as two separate states. And so again, it's a communication mechanism, and it's a necessary one too, because we as developers want to talk about what can happen in certain states.

Instead of like, oh, just check this boolean flag. And if this is false and that's true, and you know this and this are false, then do this. Like, that's really confusing. And so, yeah, it's a social construct sort of. I think you have to be careful too, right? So sleeping in a wake is a really convenient, pair to talk about, some sort of way to capture this, the state of mind, which is. I fell asleep on the couch, but now my eight-year-old has jumped on top of me. I'm definitely not all the way awake, but I don't think sleep captures that either, right? So, and I mean, we're going really forward here. But that's where you get into statecharts, where now you have all of these little states. Like this half sleep, half awake state, where you're definitely not sleeping, you're definitely not fully awake. But you're like, in between there.

But you could say. That's a subset of being awake, or maybe a subset of being asleep. However, you want to categorize that, and statecharts help you organize that. I like that, so I haven't dealt that much with layered state machines in that way. So how do you think about that when you have these sort of sub states that are going on are, is it kind of similar to? You might think of a class hierarchy or something where you inherit things from the above state, but you can override things. Or how else would you address that? It's not so much inheriting, it's more, just grouping similar behaviors together, and, yeah, just um. The way it works is, by event propagation, too. So basically, when you have a state and that state has nested states, those nested states take priority. So if an event happens, those smaller child states are going to respond to it first, and if it doesn't handle it, it goes to the parents, etc.

But all statecharts can be made into state machines. It's just that when you convert this HR to a state machine, you get what's called state explosion. Because you get all of these unorganized dates and so, honestly, I think this is sort of, but that's one of the biggest, um. Reasons for the learning curve behind XState is that there's so much to learn with statecharts. But I want to emphasize that statecharts are just an organization mechanism. It's one of those things where you don't have to learn it all before you start using it. Just know that there are tools there that help you, you know, better. Organize your states, and all of this is a lot better than you know, of course, organizing like a ton of boolean variables. So if I was to play that back to you, the state machine is essentially the flattened version. It doesn't have all the context of how these states relate to each other, except in the rules that are written out.

And so it can be potentially hard to understand that higher level structure. Whereas the statechart is kind of a grouped set of state machine pieces so that you can see that bigger picture a little bit more. Oh, these are really sub states of this and this is. How they relate to each other, and what priority is that assessment? Yeah, exactly. I mean, imagine making like a web page where you have no nesting of elements. That would be your state machine. So statecharts are sort of the revolutionary thing that says, hey, you could nest elements however you'd like. Yeah, so I mean, it's a really great summary and analogy. David, David, great summary. Cabal, great analogy David. So, props points for both of you, so for me, like, I think this, like this concept of like encapsulated states, is, you know, maybe something that isn't explicitly said here. Like, you know, having kind of, that encapsulation where nested states are not necessarily, triggerable by higher level, kind of state machines, right?

So you have to get to this path and take this, take this left and take this right in order to trigger this nested state. Like, that's kind of cool, but I think for me, it kind of like it still goes back to that. Like age-old question of like local state versus global application state, and like, when to encapsulate what, right? Like? If you have a calendar icon and another icon, a calendar widget, and you know a user is picking their dates. And that maybe that's part of a form, and let's say you want to have some form. State. What are you persisting? What are you saving? What's that? What's application? State? If the user wants to rehydrate, you know, you know, after a refresh, like, where are you bringing them back? Right? Like, and I think, you know, for me, that's something that X stay doesn't have a strong opinion on, right?

Play from 9:00

Like, it's kind of like you design it how you want to. But however like, I do think like there are still some principles around encapsulation. When something is can be shared by other things and when it should trickle down. And also, like the directional management of state events like that's still a little bit fuzzy, I think. For most folks, including me, you know, like I always have to think about it. It's never like a. It's not always like an automatic thing for me, where I know how this is supposed to flow. You know, yeah, it's okay to also refactor, and you get. It wrong, you know? And so that's where we get into, the actor models. So that's sort of like the second half of backstage, which again, people think it's a big learning curve. But it's actually a lot simpler, you know, than you might think. So with the actor model?

Instead of having just this one giant statechart, like just sort of determining, or even like ad hoc machines, like, just figuring out, like the logic for different components. You have this, actor model where you have individual actors, where you could think of them like class instances, or just like things that you could send messages to. And, the behavior of each actor is guided by a state machine, so, an actor can send a message to another actor. So, for example, you could consider like, if you're listening for mouse move events on a DOM element, that's an actor. And so when you're setting up ad event listener and checking for those mouse moves, you would send those events probably to something else. And so that would be another actor and so that actor might be in charge of, like, coordinating all this movements. Like, you know, if it's a drag drop actor or something like that.

And so, that's another conceptual shift, at least in front of developments. Is thinking of, everything in your app as like just little entities talking to each other. And it's also something that's very different than, for example, Redux, where Redux it's like, okay, everything is in this one global store, and if you don't have, you know things that fit in this global store. Good luck, find somewhere else to put them you. They can't live in Redux. And so XD takes a different approach. And it's like, it doesn't matter whether it's local or global. You could set up that actor hierarchy however you want, and access it, wherever you want. And yeah, sounds to me a lot like the type of encapsulation we're used to thinking about. In terms of data, for you know, component level data, but in this case, it's not just data. But it's this whole state machine of like, what are the potential states?

Are there? Can you compile that set of actors up into like, is this once? Again, sort of syntactic sugar to help us think about this. Could you compile that up into a single global state machine, if you wanted to? And if so, are there any sorts of interesting like analyses or invariant checkings we can do on that? That's such a great question. Yeah, so, as far as like compiling like a bunch of actors into a single state machine, I would say, not really. It's sort of like asking, like, can we compile all four of us into a single mega human? Doesn't really work that way, but as far as state machines itself, that could compile down to, just like normal code. You don't need to use the library. In fact, I wrote an article, you don't need a library for state machines. But actors sort of work the same way, too. It's just it's just this contrast between objects where you could just talk to different objects.

So, what? What constitutes an actor? And also, by the way, does this mean cable? That, like nine women can't make a baby in a month? Because that just like ruins my plans. I have heard that. Yes, no, I guess where I was trying to get to is like, conceptually, where are the? Where are the lines of the state machine? And because one of the real benefits of state machines is that they're like, extremely analyzable, right? You can, you can put something state, you can reproduce that state, exactly, you understand what's going to happen here. And when we talk about breaking apart into actors, I think that, you know, there is in and of itself, kind of a useful abstraction there, right? The actor model for thinking about things is quite useful. Message passing is a nice way to delineate things, and within each actor you have that property of.

There's a nice analyzable state machine. But it does make me wonder, right if we put in the restriction of only actors can send messages to actors? So we're keeping everything is within our sort of model of XState state machines and XState. So this is all hypothetical in my head, I don't I. You have a much more concrete model. At that point, you know, every message is potentially the result of. An action with or of a state transition, or something along those lines, so conceptually, these state machines are part of a more, a larger. If we. If we say only actors can send messages to actors, all actors are themselves state machines, then we should be able to do some amount of combination of actors. And say, okay. Even though it's a useful, organizing technique to have these be isolated, we can model them as one larger thing so that we can run global checks. And say, are there, you know, are there loops that we might get into?

Or other situations where this is not a valid state machine? All right, I, I understand you now. So yeah, this is more along the lines of orchestration, so, with orchestration. You have like this hierarchy of actors, where again, this is not global state like Redux, but you have like a global orchestrating actor. And then you have maybe child actors that respond by it, and those child actors could also spawn child actors, and all of these actors could be talking to each other. But you, are ideally organizing your app in a way that you have a central orchestrator, you know, just like an orchestra conductor. That is receiving messages and maybe delegating to other actors. Okay, you do this and you do that, sort of like working at a company where, it's not co-workers telling each other what to do. At least, hopefully. It's more like the manager is understanding what needs to be done, is getting changes as they happen and other signals.

And then is telling, their, you know, employees, like, Okay, you do this, you do that, and yeah, so doing it that way, you could think of like, just this massive network of actors is just like you have a central orchestration unit and events come in from the other actors. So you don't need to worry about, like, okay, well, how do we, like, combine those actors together? Just know that there's a potential number of events that are going to come from somewhere. And so with that, you could, you could fully test the system, or you could fully test your orchestration and ensure that. Hey, if this event comes in, this is going to happen if this. Other event comes in, then this behavior might change, and then this might happen. But yeah, so abstracting it that way, it actually makes it a lot easier to test, and that's sort of one of the central ideas behind model based testing.

It's called where you're not even thinking about, like, Oh man, I have to mock this, I have to make sure that this is integrated with that. It's more like, okay, everything is just events, so you receive those events and you receive like, just a whole bunch of combinations of events. And you ensure that the states resulting from those events is as expected, according to your model. Yeah, what's up, let's break there. Yeah, yeah, so I, I'm still a little fuzzy on, like, what constitutes an actor?

Play from 18:00

And just also, I think, kind of the responsibility of orchestrators versus whatever. So, I think maybe we if we could dig into that a little bit more, I think. And flesh out, just kind of the moving pieces of XState. That would be great. And then we can maybe get into, like tooling and all of that other fun jazz. Yeah, story time, maybe a third segment, but anyways, here I am. I'm being bossy. Nick, tell me to shut up. No, it's crazy. We sort of jump like way straight into actors and like, Wow, this is, advanced stuff, but that's okay. Yeah, yeah, I think it's sorry. That's probably my bad. No, it's all good, I get it. I get excited about some questions. Gosh, restrain yourself. Okay, I'll let your level. Okay, Kevin, does anyone need a break? Again, I need air conditioning, that's about it. Can't help you there, unfortunately.

Okay, Emel, do you want to lead us into the next year? Yeah, yeah, sure, sure, all right, ready? Uno dos Esteto so, yeah, I definitely just said, Uno dos esteto. That happened because, you know, X day was originally for it's a formerly known as Esteto. That's not to derail, but I would love to know why you didn't stick with that. Yeah, exactly. Who made you change it? Darn it, okay, there was Redux Mob X, like, there's the whole X thing was going on, so I'm like, Okay, I have to find something with X and. X8 was available, so I took it and then I backpedaled. And like, added meaning to the x, like it means like a transition, like a crossing of some sort. So I'm like, I, I have no idea what they mean in Redux and Mob X, but at least I came up with some sort of meaning. Yeah, they mean nothing. Yeah, it's, it's just cool. It's clear they're remixes, they're remixes. And available domain names, you know what I'm saying?

And GitHub names, but anyways, so back to question time, back to the interview. So so we talked a little bit about orchestration and actors, we kind of did a little bit of a deep dive. So I'm just gonna ask you to, just like, take a few steps back, because I'm I'm a little lost. So can we talk a little bit about, like, what actually constitutes an actor, what is an orchestrator, and really like, what are the general moving pieces for? You know, a production level XState station, you know, yeah, so actor, think about ourselves, really. I'm an actor, not like an actor, but like, I'm an entity, and I'm just calling us an actor, you know, Nick's an actor, K-ball's an actor, a mole urine actor. So what we're doing? Yeah, so I'm, I'm actually a diva. Thank you very much. All right, well, subset of actor, yeah, specialized subclass of actor. Thank you, thank you, thank you gentlemen, thank you.

Play from 26:00

So with actors. What we're doing right now is we're talking to each other, we're sending each other messages. And so that's like one of the primary functions of an actor. The way that actors communicate is by sending messages. And so, actors can send messages, actors can, receive messages, of course. Can they can, they choose what they want to listen to? They can. Yeah, and so that's, that's an actor's behavior, so I have a behavior, and that behavior can change depending on the message that I get. You know, like if someone offends me on Twitter, then my behavior might be a little bit different. So, you know, it depends on the messages you receive. And also, actors have their own local private state. So, with this whole analogy, I have thoughts in my head right now, you're. All thinking something, I don't know what those thoughts are, I can't read your mind, so how do I get that information out of you?

Well, I ask you, just like you're asking me questions right now. We're sending a message and we're hopefully anticipating a message back. Otherwise, it would be really awkward. And so that's how actors communicate, and so actors are just things that send and receive messages. Now, actors could also do things like spawn other actors and just create this network of actors. But those are the three basic, parts of actors. And so, if you haven't, I guess. To recap, it's sending messages, listening to messages that you, you know, subscribe to, and then spawning other actors, exactly, and that's all there is to it. Actors are, state machines as well, right? Yeah, actors, they think state machines, right? Yeah, yeah, you can think of it that way. So actors exhibit state machine behavior, whether it's implicit or explicit, just because state machines and actors go really well together. Since actors define their behavior based on the events they receive, and that's exactly how a state machine works.

Okay, you have an area where there's no actor, it's just a state machine. Well, so a steam machine, it's. It's like a blueprint, it's a description, it's like saying, you know, there's a blueprints of a house, but there is no actual house. So yeah, so then, like, can an actor contain an actor? contain an actor? Like, like infinite levels of nesting, and so like actors. Even if they're nested and encapsulated, they still can listen to messages that are outside of their immediate scope. In the upper levels of the bubble versus the inner. Yeah, so, first of all, yeah, actors could spawn actors all the way down, but as far as receiving and sending messages, that's another constraints of actors. And that I can only send messages to someone that I have contact with, so right now, I could talk to all of you. But if I want to talk to someone in like the YouTube chat or some other live stream somewhere.

I don't have a direct connection with them, so I cannot do that right now. And likewise, if you don't have a connection with me, then you can't send messages to. Me, same thing with actors, so the way that actors talk to each other is by having reference to other actors, like having their email address or phone number. That raises a question that I had, which is, are all of these messages point to point, or can you like subscribe to messages? So you could get like, a multicast type of phenomena going on? Yeah, so actors are just the building block, and you could create abstractions on top of that. So, one of the most popular libraries for, just the actor model in general. Is Akka really popular in the Java and the Scally ecosystem? And, they also have the notion of subscribing and topics, and, other things you might find, like multicasting and all of that.

And so, yeah. You could definitely build abstractions on top of just those basic actor model rules, like, for example, if you want to build your own subscription mechanism on, you know, actors. It's nothing new, it's just okay. As part of my internal state. I might have a list of subscribers, and whenever a subscriber sends a message saying I want to subscribe to you, I added to that list of subscribers. So now I have a reference and so when I feel like emitting or multicasting something, I will go to my list of subscribers. And just, you know, iterate through and message each one of them. Okay, so, I think I'm I'm still a little confused. Sorry, if I'm like, super slow-brained today, but I'm still a little confused. At. Like, how an actor is supposed to know about another actor before they can communicate. Like, you can't just publish a name of an actor, like with like, or is that? Is that what you mean by? That? They need to know the name like, or that they need to have context.

Well, it's more like they have to have, you know, reference. For example, how did you all know about me? How did I know about you? Someone probably told you, or you saw something on Twitter, which Twitter, you could think of Twitter as its own, uh. Actor so, yeah, and actors can come to know of other actors by two basic mechanisms either. They're born with it, so when a parent's. Actor creates a child. Actor could say, by the way, you know this actor. Or, you know, even as simple as you know me as your parents, or I. I could send them a message and say, Hey, you should check out this other actor. This is a reference to that actor. Yeah, so you're okay, messages that makes sense, that's awesome. I also love the like, maybe they were born with it, you know? It's like a good reference to, like, Lady Gaga's.

You know, I was born this way, and then what was the other Maybelline? Maybe she was born anyways. So, so. I think the question I have is like, in terms of event flow, right? Like the thing that flux architecture is popularized in. The front end was this kind of downwards data, proper event propagation workflow, right? And it kind of was an attempt to wrangle all of the spaghetti events that were flying everywhere in the front end community before that. Like, think of Java, you know, JQuery code bases that didn't use like frameworks, right? JQuery as a library, and codes just, you know, whatever things are using iffys and function scope in order to encapsulate. And so, so there just was never a predictable way to, like, debug a problem, because you never knew, like, what was talking to, what you know, right? Yeah? And then we introduced the same pub sub pattern in the front end, then downwards.

Data flow and like good component architecture and hierarchies. And so can you talk to like, are there some best practices? Or just like recommended flows for events? Or? Or is that just like something that doesn't matter in the world of XState? Because, you know, once you are in a given scenario, there is going to be a level of determinism. Regardless of whether that arrow came from above or below, or from the side, you know? So I think one of the most important things is separation of concerns. And, like with Flux libraries that love to just put everything in one global store. It's like, you're sort of you're either making an artificial separation of concerns, or you're completely eliminating it entirely and saying everything is either global. Or figure it out, like, I talked about, and so. With exit, it really encourages you to be like, okay? If there is some like actor that's concerned with this and another actor concerned with that, then those should be two separate state machines or actors.

However, you want to make it, and it's also forcing you to abstract everything via events, and so that further reinforces separation of concerns. Because now it's no longer about, like, oh, what's the right method name, or what part of the data do I have to read from this state? And when's the right time to read it? It's like, no, it's all just events, you're just sending in, sending in events and hoping that the actor, you know, does the right thing with it. And, as far as getting state, it's receiving an event. Whether you're subscribing to it implicitly or you're actually, you know, explicitly, getting that events sent directly from the actor, to the other actor. And so with XState, the architecture is really about simplifying and having everything in terms of isolated behaviors and message passing. And that's pretty much it. And so I, I feel like that makes your logical lots more, predictable, and it's something that you could even extract and communicate with, you know, non-technical people too, for sure.

Yeah, I think that's like the whole UM. It helps you kind of decouple your design and discovery process. And I have to give credit to U.m. Alec Lavoy, who's a teammate of mine at Indigo, who was the first person to introduce me to XState. I had spent a few years kind of away from front end, explicitly because I was at npm and I was just doing things with Electron before that. And so I kind of came back into the front-end world. Like, and then all of a sudden XState was a thing and my Alec introduced me to it. And he was really trying to push us. Creating state machines with our designers and incorporating that into our development process. Because it's like, you get this artifact that you can then code against, right? Because here's your spec, here's this flowchart. You know, you can host it somewhere, you can put it in a GitHub issue, you know.

And it's this thing that helps you decouple the design and discovery process. And just. Make sure that you've got all your error states. You've kind of thought through all the different scenarios. And then you know, you can decide what you want to support in this iteration, what you don't right. Build in place holders. And it's just a really great communication tool. You know, so really. Kudos for doing that and kudos to Alec, you know?

Play from 29:00

And kind of, yeah, yeah, sorry, like, I think, touching on that a little bit. Emily, you mentioned, like an artifact, being able to look at there. One of the first things that you'll see and like, if you go to the XState site. One of the four links on the page is to the visualizer. And that's this tool that lets you visualize the state machine in a non-code way. That's like a, like, a statechart. Is that what you would consider a statechart? DAVID yeah, that's a statechart. Okay, cool, and I really like that. Because it's like, that is something that you can take to your non-technical stakeholders and show. Like every possible state of an application or a component. And then you have this, this hard coded diagram that then you can code against to. To actually produce the intended output, and it will only ever be the intended output. Because you can't be in any other non-defined state, which is exactly really cool.

And it's interactive, so it's like hard-coded, but it's like it's interactive. There's, you know, an interactive GUI to it that can all be run in memory, like you don't even need to be online. You know? Yeah, how that kind of sets up a question. Oh, sorry, go ahead. KAYLA yeah, no. So the visualizer was also on my list of things to talk through because I love it. I think it is, a key for thinking about these things, and, as you all are talking about, lets you bridge between things. The thing I'm curious about is, does it handle kind of multi-actor, multi-state machining systems or these sort of higher level architectures with orchestrators and things that you were talking about? Is that something the visualizer can show for us? Yeah, definitely. Not the visualizer. The Xc.js..org slash, viz. That's actually an older version of the visualizer. And we're working right now on making a brand new version. But, there's also the XState inspector, which works as a visualizer, but not for code that you paste in, but rather for code that's actually running in your application.

And so what you do is you would hook it up to an application that's using XState. And that might be a actor with a machine, which might be spawning other actors. And so, there's a sequence panel where you could actually see how those actors are sending messages and talking to each other. And this is actually another classic thing that you might have used before, I'm pretty sure, called sequence diagrams, just like those, you know, line diagrams. Where it's like, all right, this is going to here and that's going to there. And by the way, the little figures at the top, those are called actors in the sequence diagram, too. Exact same thing, um. And so those are really useful for communicating, like how different systems or different actors are talking to each other and what the potential scenarios are. So the inspector can do that, and right now we're working on, just like a completely revamped, visualizer slash inspector that's just going to let you do everything, whether it's copy paste code in or, you know, inspect applications in real time.

Play from 39:00

That's super cool, so, so. So, X8 is like, framework agnostic, right? You can use this with any framework, it's not, there's no, it's similar to Redux. Does it have a bunch of dependencies, or is it like a zero dependency library? Zero right now, there's zero, and it's always going to be zero. Don't quote me on that, but I'm really that's a high level goal. And like, like, in terms of the sort. Because obviously there's a bunch of developer tooling that's not going to ship with your production source code, but like, right out of what ships to production. Like, how big are we talking of a footprint? Like, so, yeah, that's a good question. X8 is about the same size as Mob X in that regard, around between, I think, 15 and 17 kilobytes. Minified, um. However, in version 5 we're working on making it smaller. And if you want to just use basic state machines and you're like, I. Really don't want to pull in all of that, say for it. Even though it's only 15 kilobytes, there's something called X8 FSM, which weighs in at 1.5 kilobytes.

It's really, really, really tiny, like XState light. Yeah, yeah, it's, it's a flatter version backstage. So you're not going to get your, you know, nested states or any of the fancy like history states or invocations or things like that. But for a basic state machine, where you're, like, Okay, we, we could draw this clearly. As a flat state machine, X8 FSM is going to be your best bet. So have you considered calling it diet Estado? Like, because that would be a really good name, I don't know, I'm just saying, it's such a good name. I mean, you know, I don't speak Spanish, you could call it. There we go. I think I still have the npm name, so you know what, I, I might do something with it. This is some, yeah, something just, you know, just publish copies of what's the latest map, you know, main branch and onto there too.

So people can, can choose to use that package. It won't get confusing at all. [Laughter] it's like how React used to be called facts JS and no, yeah, yeah, no, no one really uses that anymore. It's called it used to be called facts, like TA, like a fax machine. Oh facts. Oh, that's so weird. Yeah, so okay, so so in terms of, like, what XState offers? Like, you know, there's the visualizer, there's obviously the core source library, like, what else is there? Oh, there's a lot, so, there's the visualizer, the inspector, the core library. There is something called XState test, which, like I was talking about earlier, it's a model-based testing library. Where you give it a state machine describing your application. And it will automatically generate, like all the hundreds of different ways that someone can interact with the application. And then you just run that through jests, or, you know, add puppets here, or play right to that too, and it's going to basically write the tests for you.

There's also, what else do we have? X8 Immer if you want to use Immer with XState FSM, XState graph, which is just graph based utilities. For X8, that's really useful for, like, all of our visualization and graph drawing parts of XState and actually mapping out all the states. And we're we're thinking of some future packages, too. Besides, like the adapters to React and view and Svelte and all that we're thinking about, like a XState router and an XState form. So what? We're still planning? Those, yeah, it's going to become a big, you know, ecosystem goodness. As an example, would XState Router be like a replacement for, like, like, a React router type component, or would it work in tandem with that? It would probably work in tandem? Whereas with a React router? It's like, all right. Just define your routes as components, and if you don't want a route showing, then just don't render it on the screen.

X8, rather, is more like, give us all of your routes up front, we're going to map it out for you so that you could either navigate directly.

Play from 42:00

Or, if you click next, then the state machine knows exactly where that next link is going to be. Instead of hard coding it into your application view layer. Oh my god, that's like, mind-blowingly, but just like, even just like hearing that makes me feel good. But yeah, I know, I think there's a lot of stuff around URL management. Source of truth for state, kind of server needs, client kind of transitions for SSR apps, like all that kind of stuff. I want to get into like middle or middle world patterns that were popularized with Redox, like, what's the kind of XState equivalent? But yeah, I guess we'll maybe, we'll get into all that good stuff right after these messages. Mm-hmm, nice, cool, right at 20 minutes, all right. Okay, anyone need a break? My water? I'm good, cool, still sweating. [Laughter]. So do they not have AC up there? No, it's no. We, we live like we live in the mountains and we don't really need air conditioning.

It's just like climate change is giving us more hot days than normal. And then our like windows were like awkward shapes. It's not like I can just like stick a window unit in there really easily. But if it keeps up, I'm probably gonna get like, a portable air conditioner like, and just. Cave in. But we're definitely not getting HVAC or anything observantly. Like, extravagant, like, like that, you know? So keep this house rustic, all right. So yeah, so I'm happy to kick us off, but I also feel like I've been talking a lot. So I don't know, that's fine with me. I'm trying to map. We've been kind of jumping in and out of different sections, so unintended, it's totally fine. [Music] if you want to, unless cable you have any, you want to kick off at all? Well, I mean, I'd love to dive deeper into this idea of state-driven routing.

Straight, different applications, and how that relates to the whole age-old, declarative versus imperative approaches to things. But email if you had something more pressing you wanted to kick off with? Yeah, yeah, I mean, basically what I want to talk about is can be segued from there. So if you want to go for that, let's let's do that. So I want to get into, like, you know, my personal velocity, which is like your application URL should be your state of truth. You know for um. And you should be able to rehydrate your application just through that URL. And kind of want to talk about persistent states in the client, and then I want to talk about like middleware patterns and. And then also cover like the server-side workflow, like whenever, because, servers are state, they're bug farms, and they're huge state machines. So like, how could, like, how can we use X8 in the server?

But also, I think calling a server a state machine, maybe that's the infinite state machine [Laughter], and they're bug farms. Because they're really badly written, right? Yeah, so encapsulation is another huge problem. Yeah, it's software, right. No judgments, everybody has embarrassing code. So, so, yeah, I mean, so. But I would say, like, what you want to talk about is a good segue into that stuff. And I think the only thing I want to maybe shout out is like one of my friends who I really respect like as an engineer. But you know, he's very back end heavy, and he's really into kind of pre-rendered views and static kind of clients. And so, you know, he doesn't believe in, like he doesn't. Understand why JavaScript like apps need state machines or state management at all, he thinks it's overkill. So I'd love to hear, like, what David has to say about that? Ooh, that's, that's a fun topic. Yeah, so, yeah, so anyways, floor service cable, all right.

So let's let's bring it back and talk a little bit more about what we're just leaving off on around. State machine driven, state machine driven routing. And the piece of this that I want to kind of dive into is one of the age-old pendulums in software development generally. And that we've seen between imperative and declarative approaches to programming, and I think we see this in our front end frameworks, React is very imperative. Even though it enables a more declarative view of components, Vue is actually a much more declarative model for programming and mental model. But I think when it comes to stuff like routing and application state, one of the nice things that you can get with a state machine approach is it. It feels once again very declarative, something where you can say these are the ways that the world should be, go and make it happen.

And I'm curious, is that something that, you're seeing people use XState to do? How do you think about that? How much of that kind of mapping from? Here's the declaration to what does the app need to do? Does XState do for you? Versus you have to implement? So, yeah, people have been experimenting with using XState and routing, and there's a handful of libraries just sort of playing around with this idea. And it is something that we need to think about more. Just because there's something that seems to go against what a state machine is. Which is the fact that I could, I can navigate to any routes I want just by changing it in the address bar. So it's not exactly an event, it's more like, Hey, just teleport me directly to this date. And so now it. It's not really super against what a steam machine is. It's more like there's these implicit transitions where you could just transition to any state at any time, but those still need to be made explicit.

You should know, like, what are all the routes you could go to? And also, as. State machines are, you know, very founded on, like, just having your application logic be safe. There has to be some safeguards for. Like, if I go to Slash Admin, it's going to check am I logged in? Otherwise it needs to boot me to a login screen. Well, all right. Ideally, I should be logged in an admin. I can just be logged in and do all sorts of crazy stuff. But yeah, so, yeah, um. Some of the earliest examples I've actually seen of using statecharts, was actually before I even started programming. It was with ember, or when ember used to be called sprout's core. Sprout core used statecharts a lot. And so this was like, again, before I even touched, well, I touched computers before then, but before I, like, was really hardcore into programming.

And it was really interesting. There there's actually this experiments, with ember and routing, and using statecharts for routing, and it actually has some pretty cool states, statechart diagrams. And that dates back to 2013, I believe. So, yeah, this problem has been thought about a lot before. Well, Amber was a big advocate of what you were talking about. On the break of everything stateful, about your UI being driven by your URL and your URL representing your state. Yeah, I'm I'm convinced that, like Ember developer, like the core team, they're like the game developers of the JavaScript community. Because, like, you know, there's like that saying that, like, hey, every, everything you thought of like as your big new idea, like game developers invented 10 years ago. Like, I feel like ember, like they just so many things that like, they did right, you know, they have they right, but like. But the point is, it's just amazing to see how, certain patterns were in the Zeitgeist very early on.

Play from 46:00

But they just didn't get the traction. Until people like, burn their hand in the pot and then, like, learn the hard way, you know, that's the thing. Sometimes people just don't like you can preach all you want, but until they get burned and or see the merits for themselves. You know, with increased velocity, reduction of bugs, you know, better predictability, like faster onboarding, right? So this isn't. Just actually about how your users experience your application, because, quite frankly, it's like an invisible thing for your users, right? But it, you know, it's really kind of a tool for how we do our internal data, and, you know, code management. So, communication is a big part of that, I think, you know. Both for onboarding as well as just external stakeholders that are non-technical. It's funny. I wanted to mention, even with game developers, you talked to them about state machines. You're like, yeah, I've been using them, we've been using them for decades, like, why do you think it's a new thing?

It's not right. Yeah, yeah, they're like, Oh, we have something. It's called Estado. Just kidding, just kidding, just kidding, just kidding. I'm gonna stop trying to make Estado happen. I'm like, this is like my fetch, you know, trying to make fetch happen. Bone skull, uh. One of our regular panels was commenting in the chat about this. He's like, why are there so many state libraries and ceremonies around state libraries? In the front end of JavaScript world like this is a solved problem, the solution is state machines. This has existed for a long, long time. I'm actually kind of curious, David, as you've been kind of marketing XState, bringing this to the world. Do you have any insight into why the front end world, in particular, has been slow, so slow to adopt state machines? And and be interested in this, yeah, and trust me, it's been an uphill battle. Because, first of all, we don't like being told that the way that we're doing things is like, not the best way to do them.

You could have, you could have just stopped right there where you're like, we don't like being told anything, right? Yeah, and so, you know, people are like, Oh, amazing, we even have people listening to this podcast. Quite frankly. Yeah, yeah, no, there's people who are like, no, you're being a thought leader, you're trying to introduce something new, you know, etc. And what I'm doing works, and it's just fine. And so I'm, I'm over here trying to say. Like, first of all, what we're doing is just a pale imitation of what we should be doing. Which is, you know, modeling these things as state machines, or at least some. Sort of events driven architecture, rather than trying to manipulate state directly and notice, I didn't say mutate state directly. Because all of these date management libraries are like, okay, we're technically not allowed to, like, imperatively, mutate states, so we're just going to give developers a really easy way to manipulate states.

But it's still sort of the same problem like all right now. You. You avoid the problem of having shared data access, but you're introducing a new problem of like, you don't know when things are going to change, just because they could change from anywhere.

Play from 54:00

And that's a huge problem, but yeah, X.C. Takes the approach of, you know, something that's been around for, you know, just many, many decades. And also, we were talking the break about, like, how, someone was like, why do we even need state machines anyway? The way I'm doing things works just fine, so I'm sort of rallying against that, works just fine, because that's only half the battle. Like, we don't code just to make something work, we code to make it work to prevent it from not working. And to also communicate to the rest of our team, and ideally even to users and designers and other people how the app is supposed to work. So I could code something in assembly, actually, I can't die on no assembly, but I could code something and see where it's like, Okay, like, I, I made this complex thing. It works, don't touch it, but no one else will understand it. And I feel like my job is incomplete if the code I write is not understandable by others.

Oh man, can we just take a moment of silence, just preach on, brother? Seriously that I couldn't agree more. Honestly. Like the other really big thing is that, you know, you know, when you read code sometimes and you're like, Oh my God, like, what's up with the paranoia level in this code? Like, you know, it's like everybody, like all these shields, from all these angles, it's like Jesus Christ. Is this like some function that's used in every file and every method, like, why are you being so like, shielded? Like, you know, you can kind of reduce that paranoia level as well in your code, and for me, more importantly. This enables you to optimize your code to be easily changed and extensible, right? And like, we don't talk about that enough. I've been on this kick lately where I'm like, optimized for change. Everybody, you know, I've, like, said that, like, literally a hundred times this week, you know? Because if we, you know, we have to optimize our code for change.

Like, if we think that our code is not going to change or that this thing should stay the way it is. Like, you are not living in a reality that is like, like, real world. You know, application development, right? Code is living, breathing craft, you name it. Like, people, you know, come and go, and you know, libraries die to. You know, things need to kind of move on. You know, and you know, you just you, you know, you. Ha. You have to, like, be able to, kind of weather that change, and you know, support. Easy pivots, right? Especially if you're a startup or a small company, that's still like trying to validate your product market fit. You know, right, and you know, so, so, yeah, like, I mean, it's. It's just huge, for kind of, I think, bringing that ease of communication and determinism, you know, into your, into your applications. Like, yeah, and that's the points.

I wants, our laptop, our lap, app, logic that we writes. I want that to be a communication mechanism, like something where we could create that visual artifact and share with other people. Like, Hey, this is how it works. And then if they're like, well, like you were talking about, this is gonna change. Or I need to add this feature. We could know exactly where the app is going to be affected. Whereas if you just do things the normal way, we've been coding for many years, it's like, Okay, this is another boolean. That's going to go in a dozen of our IF statements somewhere, and we're going to have to check it all. And let's hope we have tests, but there's a really good chance that we don't have tests to capture this behavior. Well, I find that I think there is a level of to which, like this, is another thing to have in your mind, another learning curve to climb. And part of the challenge here is we're still navigating this transition mentally, from front ends being simple to front ends being where most.

Much of the complexity of our applications lands, and that transition is playing out in many, many different domains. But I think even within an application, right? Like, to your point, managing one boolean is not very hard. It's not very much mental overhead. And is, if that's all, it's ever going to be probably simpler than incorporating a state machine. Library. Yeah, so a question I have for you is, do you have a rule of thumb, or of kind? Of? What level of complexity, what number of different factors or states does it start to become worthwhile from a mental overhead standpoint to incorporate a state machine? So there's no hard and fast rule. If there was, I would say, like, as soon as you're getting to three booleans or more than you know. Maybe consider how the different behaviors of your app, you know, can change, and you know just what they are.

But yeah, so, you know, I, I, I always say, like, you don't need a state machine. If your app isn't complex, I also say that your app will never stay complex. Unless you're doing some sort of toy project that you forgot about. Or, you know, like, just a simple app, like, I don't know even I, I was thinking of, like, the Yo app, or you just like, press yo to your friends. Like, even that has enough complexity that merits a state machine. But yeah, we're not writing simple apps, we're not paid to write simple apps. We're paid to write apps. That are eventually going to grow in complexity and features and edge cases. And we need some sort of scalable way of managing that. Yep, yes, oh, I'm sorry, go ahead, Nick. Oh, I'm gonna tangent a little bit, so go ahead. Okay, well, so I just I wanted to say so, we kind of said this a little bit quickly, but like, so, I'm a fan of.

You know, your source of truth in your application being in your URL, your applications should always be able to rehydrate from a URL refresh. You know, somebody refreshes their screen or they're in a li-fi, Wi-fi situation, you. Know like they should be able to refresh and like, stuff shouldn't break, you know? And so I, I, you know, I'd like to kind of understand, you know how X8 makes that reality easy. And you know, the whole kind of like rehydration states, and you know also in particular when working with clients, and local storage, you know if there are tools or utils or kind of patterns around, like rehydration of your application state. And yes, I am a little bit to what I was going to ask, too, so I'll just kind of throw it out there as well. Sure, but I was going to kind of ask about, maybe I'm not fully seeing, like how it's implemented, or how it's like, implemented in practice. And like, if I were going to try and implement a state machine in my existing app, that has a lot of already kind of managed state.

With a bunch of different things, like, you know, maybe a lot of stuff in contexts and providers and all of that.

Play from 57:00

Does. XState is XState like a way to manage that component state that it might exist out there or like some other global state? Or is it more? It should take the reins from that? Yeah, that's two really good questions, so I'll talk about the persistence, one first. X8 does have a way to basically take whatever state your state machine is in, including any extra data, which it doesn't really fall into the finite state category. You could persist that, and then you could restore the same machine, at that given state. So, in a way, it sort of acts like, you know, any other state management library where you could do that? And, right now we're working on, and this is a hard problem to solve, but we're working on a way of also persisting actors so if your state machine is in a state where there's other child actors who also might have other child actors.

Then pretty soon you'll be able to persist those as well and restore those actors to those dates. Or at least try like, for example, if you have a promise request or something, then chances are you're going to need to rerun that promise request when you reload the page. And yeah, but. You know what, it? This kind of brings me to my next thing, which is kind of actually middleware patterns, because, you know, I could very easily see there being a middleware that was activated. Anytime there's a promise and it knows how to handle a cancellation state, or like a failed state. Or, you know, so you're not like repeating a bunch of code everywhere in all these different actors. And so, you know, because Redux kind of popularized the middleware model, right? So did express. You know, if we're like, really, go back a little bit further, but you know, it just kind of was like, here's a bunch of things that'll run every time there's a state update.

And if it gets triggered, if it, it may or may not trigger some business logic. That's in your middleware, you know, for example, like if there's an error like log to sentry, right? That's one thing you put in your middle middleware. If you want to normalize some data, if you want to do some analytics, or, you know, right, whatever. Yeah. So what's the state path for that? And this sort of leads into Nick's question, too. But, you might be either happy or sad to know that there is no such thing as middleware in the next state, and there never will be. And that's because XState has this abstraction of state and events, and that's pretty much it. And well, also actors, which encapsulate those dates and events, and so everything works through that. So if you want to add analytics to something, then, your state machine, it has a subscribe method, just like you know anything in RxJS.

And you could do whatever you want with those state updates, so you could send it to some analytics or some logging service and do things that way. Now, Redux and libraries like it, they need middleware to handle side effects, and that's because they are completely hands off with side effects. X8, on the other hand, says no side effects, which XCA calls actions are extremely important. Like your. Your app will not work without side effects, so we need some declarative way of managing side effects, and so that's exactly what X8 provides. And so it does so, in terms of spawning or invoking. Actors or even just performing one-off actions? So yeah, it has that built-in notion, so instead of requiring middleware for that, that's just part of. Like, just the notion of actions and services which you can provide externally to. And so well, I guess my thing is, how do you avoid duplicating subscribes or events everywhere, right? Like, if I want something to happen?

Every time a data fetch is triggered, you know, how do I avoid needing to update like all of these different state machines in my app? You know what I mean, like, is there a way to centralize that? Is there like a hook for before all or after all? Or, you know, I, yeah, I mean, yeah, there's, there's different patterns, and this gets sorted more into advanced sex state. But you could have, like, parallel states, and you could also have actions that happen on every event and things like that. But the easiest way to get started with that is just, you know, calling, thought, subscribe and handling state changes. That way. Okay, so yeah, very cool. Does, does that state work? With suspense in React, Oh my God, can we not talk about suspense? This is a broken API. I don't think that's a better question, I suppose. No, so, yeah, suspenseful and concurrent mode, that was a yeah, something tricky that we were trying to figure out for.

Oh, well, I mean, yeah, I, I won't say it out loud, but yeah, okay, I can say it. That's why I'm really glad that concurrent mode sort of just didn't become a whole mode and it became like, you know, more isolated things. But, X8 does not work with suspense yet. By working with suspense, uh.

Play from 1:04:00

We mean, like, just having these built-in things where it could actually throw promises and say, hey, I'm in some sort of pending states. I think that's a good idea, at least to support, so we're going to just experiment with that. Definitely not priority. But yeah. And so going back to your earlier question, Nick, about like, how it integrates with, like, existing code. In other libraries, you could use XState like, either at the smallest level or at some, you know, global orchestration level it doesn't need. To encapsulate, or like, just take over your entire application states. You could definitely do it incrementally, and that's that's a good way of using X data as well. Yeah, that's actually a good point, because that actually helps with incremental kind of adoption and refactoring, refactoring in place. You know, yeah, some, obviously. You're slowly, you know, refactoring your views and components to slowly be managed by XState. That's pretty cool. So as we're kind of winding down here.

You know, how can folks contribute to the project? Sounds like, you know, you have definitely have a road map, you've got an active, you know, kind of healthy, project, and so how can folks contribute? And, get in touch with you? Sure, we're, well, we're. We're always accepting, you know, pull requests, especially for documentation, and we actually have a new. I mean, I showed done this years ago. But we have an examples directory on the page where we're just filling it up with as many useful examples as we can. Yeah, yeah, so the recipes are also in the documentation as well, like how to use this with Vue or Angular, etc. Yeah, so that. And also participating in the discussion forum. So if you go to Discord dot GG slash XState. There's just a whole lot of really helpful people in there. Either sharing crazy ideas or offering help at all hours of the day. And I know because I'm one of those people offering help at all hours of the day over there.

So yeah, just participating and trying it out on your projects, that's so awesome. And where is Xtape being used right now? Because I remember, you know, this goes back to my conversation with Alec. I have a very healthy skepticism for new technologies, and especially when to adopt them at a large corporation. Because I have to. If I'm going to push a tool, then I have to take on the maintenance burden of making sure everybody's aligned and trained and everything is updated and standardized. So it's yes, it's not, it's not an easy thing. Or something I take lightly. And I remember, because I hadn't heard about XState when Alec LaVoy introduced it to me, I was really like, I. Don't know where is this being used? You know, like, especially like, you know, I don't want. I don't know if this is like JavaScript's new hot thing, you know what I mean? So, yeah, can you give us kind of a sense of, like, what that adoption curve has been like for you?

Yeah, sure, so, I actually asked this question on Twitter a few months ago. And, I was surprised to learn that.

Play from 1:09:00

There's a lot of companies using XState in production, notably, I mean, Microsoft, even I, I didn't work in any projects at Microsoft that use XC. That's just like, Microsoft's a huge company. So they've used X data in various projects, including, one of their education tools, and also the Microsoft to do app. Netflix is using it, LeGo, Amazon is using it in their AWS amplify service to handle authentication. So you could say that X data is being indirectly used by just hundreds of thousands of developers, you know, that way, it's, it's part of Gatsby as well. Honestly, there's, yeah, there's a lot of places that I can't think of. A project that isn't in Gatsby, Gatsby's like the kitchen sink, it's either Gatsby or next. JS so yeah, that's so cool. Well, thank you so much for your time, David. It's been an absolute pleasure. And yeah, I'm excited to try this in production, you know, it's definitely. It's easy, it's not. It's on my recommendation list for the UI architecture at Indigo.

All right, awesome. Yeah, pretty soon I'm going to write a like, getting started with x even three minutes article. So zero excuses. Well, let us know we'll retweet it. All right. Well, thank you so much for coming on. Thanks Kball and Amel for joining, and, we will see you next week. Bye kids. [Music] David this is so fun. Thank you. It was, yeah, thank you so much for having me on. It was a blast. Thank you for putting up my sometimes obscure, hypothetical questions. No, they're, they're really good questions. Yeah, I appreciate it. You're so smart. I want to be you when I grow up, you know that, right? I, I've literally, it's literally been on my list to, like, ping you and tell you this.

Play from 1:12:00