# X gon' State it to ya Canonical: https://davidk.dev/talks/x-gon-state-it-to-ya/ Video: https://www.youtube.com/watch?v=br4qhVRtkU0 Speaker: David Khourshid (@DavidKPiano), creator of XState Type: Podcast · Event: JS Party (Changelog), "X gon' State it to ya" · Year: 2024 · Duration: 1:05:30 · Views: 20 (as of 2026-10-19) Topics: XState, Actor model, State machines, Event-driven architecture, Statecharts ## Summary Amal, KBall, and Nick welcome David Khourshid to the show to talk about his project, XState. XState brings state management to a new level using finite state machines and is compatible with your stack. We talk about how the idea came to fruition, its practical uses, and where it’s going. ## Key takeaways (quoted from the transcript) - Before we dig too far in, maybe let's take a step back and define what a state machine is, so state machine. (8:00) - You can put something in an exact state, you can reproduce that state exactly, you can always understand what's going to happen here. (19:00) - Actors exhibit state machine behavior, whether it's implicit or explicit, just because state machines and actors go really well together. (27:00) - 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. (32:00) - 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. (43:00) - I always say, like, you don't need a state machine if your app isn't complex. (53:00) ## Chapters - 0:00 Introduction - 3:00 I would say the only correlation is the fact that… - 8:00 An example of a finite state would be sleeping or awake - 16:00 Actors sort of work the same way, too - 23:00 Alzero is a for developers by developers identity platform built for… - 25:00 The way that actors communicate is by sending messages… - 35:00 XState Immer if you want to use Immer with XState FSM… - 42:00 Some of the earliest examples I've actually seen of using statecharts… - 47:00 In JavaScript world like this is a solved problem… - 50:00 You can kind of reduce that paranoia level as well in… - 52:00 I always say, like, you don't need a state machine if… - 1:00:00 I remember, because I hadn't heard about XState when Alec Lavoy… - 1:03:00 We have Amelia teaming up with shop talks… ## Transcript [0:00] Anything on the web, people will say, like, 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. What the state machine lets you do is like, collapse that Infinity down to a few manageable states you can think about big. Thanks to our partners LeNow, Fastly and Launch Darkly, we love Len. They keep it fast and simple. [0:00] Get a $100 in credit at Lin..com Changelog. Our bandwidth is provided by Fastly. Learn more at Fastly..com and get your feature. Flags power by Launch Darkley. Get a demo at Launch Dark..com. More and more startups are using Retool to focus their time on their core product, and that's exactly why they launch Retool for startups. This is a program that gives early stage Founders free access to a lot of the software needed for great internal tooling and retools work with thousands of startups. [0:00] And the trend line they noticed, was technical Founders spending tons of time building internal tools. That means at this critical stage, these Founders were distra active from their core product. The goal is simple make it 10 times faster to build the admin panels, CR apps, and the dashboard's most early stage teams need. And Retool has bundled together a year of free access to Retool with over $160,000 in partner discounts to save you money. [1:00] While building Retool apps with common Integrations like AWS, MonGod, DB, Brex, and Segment, there is so much you can do with Retool. You can use these free credits to build tools that join product and building data into a single customer view. Tools that convert manual workflows into fully featured apps for your team, or tools that help non-technical teammates. Get access to your database to read and write data, analyze and query, these are just a few examples. [1:00] Learn more, apply and join lightning demos at Ret.com startups again. Ret.com [Music] startups. This is JS Party, your weekly celebration of JavaScript and the web. We have some awesome episodes in the queue front end, Feud one, Passwords, web Stack, Fastify with Mato Kina and a whole lot more. Subscribe today at JSP Party. FM and follow the show on Twitter. We are at JSP Party FM. All right, let's transition the state machine. [2:00] Hey, it's party time. [Applause]. Y'all hello Internet. Welcome to JS Party. I'm your host this week. Nick Nii Hoy and I am joined by two wonderful co-panelists. Kall, what's up Kall? Hello, good to be back. Hello everyone, welcome. We're happy to have you back. And I'm also joined by AML. AML. How's it going? Hello, hello, I'm having a fan girl moment, so I'll have to restrain myself today. [3:00] Absolutely, I think we all are. It's a very exciting podcast. Today. Today we are talking to David Ked David, how's it going? Going good? How are you all doing fantastic? And we are talking about you and your fantastic project XState. And so, why don't we kick off, learning a little bit more about you? Tell us, tell us what's up, sure? So you might have noticed my screen name, David K. Piano. The piano is not my last name, as you probably surmised. [3:00] I went to college for piano and then discovered that, doing web developments 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 as a junior developer, and it was like the startup where there were just all of 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. [3:00] 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 got to be a better pattern for doing all this. So I, I was doing some research and 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. [4:00] 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, dig more into it and actually find out why it's not more popular today. Fast forward a few years, I, decided to. [4:00] Just put all of my learnings into what at the time was a toy project. I actually called it estado, like the Spanish word for estate, but I eventually changed that name. Yeah, it's awesome. So that toy project had all of seven GitHub stars for many years, until actually decided to give a conference talk about it. And yeah, so it became XState, and, here we are. I have a lot of really good contributors working on it. [5:00] 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 XState, 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. [5:00] So are you still going strong on the piano? Yeah, I am in fact my pianoist right here, actually, the pianoist actually over there. But I have a Lego piano right there that did look very tiny. Yeah, yeah, tiny piano. It is playable actually. But yeah, from time to time, I still perform, you know, just it's 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? [6:00] 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, whatever it's called visual formalism that exists for application logic? [6:00] 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 estate, uh? [7:00] And I'll share some interesting back stories later. But this kind of analogy of like this 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 a set duration of time. It really is a very interesting analogy. [7:00] And I think, like, your background in your story is just like one small example of, like, why? Diversity and Tech is super important. Not just age and race and ableism, but 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. And so, you know, we're really lucky to have you. [7:00] And yeah, glad you picked this profession to help pay your bills, cuz, yeah, thank you, yeah. [8:00] 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. [8:00] Let's used 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. [8:00] 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 state. 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 seat machines are just a collection of those behaviors of or finite states and events that come in. [9:00] 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. [9:00] Like, I'm sure you've run into an application where it's like, I know my internet's fast. But this loading spinner has been going on for like 2 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 SE machines where that's impossible. You can't be both in an eror state and a loading state, you have to be in one of those. [10:00] 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 I mean? You know, I? [10:00] I love GraphQL, but, like, you know, some things about the spec are really bothersome to my heart. I think 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. [10:00] You can think about, right, right, some determinism, right? Mhm, you on determinism. You use that word in finite, and 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. [11:00] And so 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. I. I don't know how I, I didn't take Anatomy, but yeah, it's just that. [11:00] 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 this and this are false, then do this. Like, that's really confusing, and so, yeah, it's a social construct sort of. [12:00] I think we do have to be careful too, right? So sleeping and awake is a really convenient pair to talk about. But we need some sort of way to capture the state of mind, which is. I fell asleep on the couch, but now my 8-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. [12:00] 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 kind of layered state machines in that way. [12:00] So how do you think about that when you have these sort of substates that are going on? 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, or how else would you address that? It's not so much inheriting, it's more, just grouping similar behaviors together. The way it works is, by event propagation, too. [13:00] So basically, when you have a state and that state has nested states, those nested states take priorities. 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. All statecharts can be made into state machines. It's just that when you convert a statechart to a state machine, you get what's called state explosion. Because you get all of these unorganized dates. [13:00] Honestly, I think, this is sort of met, but that's one of the biggest 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 at all before you start using it. Just know that there are tools there that help you better organize your states, and all of this is a lot better than you know, of course, organizing like a ton of Boolean variables. [14:00] 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 state is kind of a grouped set of state machine pieces. So that you can see that bigger picture a little bit more. [14:00] Oh, these are really substates of this, and this is how they relate to each other. In what priority? Is that? A fair 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, U. It's a really great summary and analys alogy. [14:00] David. Great summary. Kall, 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 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 left and take this right in order to trigger this nested state. [15:00] Like, that's kind of cool, but I think for me, it kind of. 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 widget and you know a user's 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? [15:00] What's what's application state? If the user wants to rehydrate, 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 XState doesn't have a strong opinion on, right? [16: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, then it's okay to also refactor and you get it wrong, you know? [16:00] MHm. And so that's where we get into, the actor model. So that's sort of like the second half of XState, 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 day chart, like just sort of determining, or even like ad hoc machines, like just figuring out, like the logic for different components. [16:00] You have this actor model where you have individual actors, where you. 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. [17:00] 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. That's another conceptual shift, at least in frontend 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 things that fit in this Global store, good luck. [17:00] Find somewhere else to put them you. They can't live in Redux. And so XState 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. So that sounds to me a lot like the type of encapsulation we're used to thinking about. In terms of data for component level data, but in this case, it's not just data. [18:00] But it's this whole state machine of, like, what are the potential states? Is this once again sort of tactic 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? As far as like compiling like a bunch of actors into a single state machine, I would say, not really. [18:00] 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. As far as STE machines itself, that could compile down to, just like normal code. You don't need to use a library, and in fact, I wrote an article, you don't need a library for state machines. Actors sort of work the same way, too. It's just this contract between objects where you could. [19:00] Just talk to different objects. So what constitutes an actor? And also, by the way, does this mean Kall 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 a statement machine? And cuz one of the real benefits of state machines is that they're extremely analyzable, right? [19:00] You can put something in an exact state, you can reproduce that state exactly, you can always understand what's going to happen here. And when we talk about breaking apart into actors, 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. [19:00] But it does make me wonder if we put in the Restriction of only actors can send messages to actors. So we're we're keeping everything is within our sort of model of XState state machines, and to be fair, I've never played with XState, so this is all hypothetical. In my head, I don't. That's fair. You have a much more concrete model. At that point, you know, every message is potentially the result of a state transition or something along those lines. [20:00] So conceptually, these state machines are part of a more, a larger Global state machine. Yeah, 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 loops that we might get into? [20:00] Or other situations where this is not a valid state machine? All right, 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 were spawn by it and those child. Actors could also spawn child actors, and all of these actors could be talking to each other. [21:00] 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 re 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 in other signals. [21:00] And then is telling, their, employees, like, Okay, you do this, you do that, so doing it that way. You could think of, like, just this massive network of actors as 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. [22:00] And so with that, 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. 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, modelbased 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. [22:00] It's more like, okay, everything is just events, so you receive those events and you receive like a just a whole bunch of combinations of events. And you ensure that the state resulting from those events is, as expected, according to your model. [23:00] What's up, party people? This episode is brought to you by Alzero. Alzero is a for developers by developers identity platform built for the cloud era. They secure billions of logins every year. Identity is the front door of every user interaction, and the login experience can make or break a user's first impression. Identity and authentication is never a set it and forget it thing. That means when teams decide to roll their own, they are taking on. [23:00] The full burden of constantly evolving industry standards, customer expectations, and data breach tactics. And they often don't have the time, expertise, or resources to meet those needs. This takes away from critical time needed to innovate and to improve their core product. Off zero has solved this problem for every developer to give teams their time back, and to make applications more secure with off zero security compliance and industry standards. They're always up. [23:00] Todate. Developers are free to provide the login options their users want with the security their application demands. Make login off Zeros problem, not yours. Learn more at off Zero.com. Again [Music] Offer.com. U.N. ESTTo. So, yeah, I definitely just said Uno EST that happened, cuz, you know, XState was originally for it's a formerly known as EST. Not to derail, but I would love to know why you didn't stick with that. Yeah, exactly. [24:00] 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 XState was available, so I took it and then I backpad and like, added meaning to the X. It means like a transition, like a crossing of some sort. [25:00] So I have no idea what they mean in Redux and Mobx, but at least I came up with some sort of meaning they mean nothing. It's just cool, it's the coolest letter. They're remixes and available domain names, you know what I'm saying? Yeah, and GitHub names, but anyway, so back to question time. We talked a little bit about orchestration and actors, we kind of did a little bit of a deep dive. [25:00] So I'm just going to ask you to, just like, take a few steps back, cuz 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 a production level? XState state machine. Yeah, so actor, think about our ourselves, really. I'm an actor, not like an actor, actor, but like, I'm an entity. [25:00] And I'm just calling us an actor. Nick's an actor, Kall's an actor. Am, you're an actor, so I'm an actor, actor. I'm actually a diva. Thank you, very. Much, all right, well, subset of actor, yeah, specialized, subass of actor. Thank you, thank you, thank you, gentlemen, thank you. 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. [26:00] The way that actors communicate is by sending messages, and so actors can send messages, actors can receive messages, of course. But could they choose what they want to listen to? They can, 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. [26:00] 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? 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. [27:00] That's how actors communicate, 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. So, just like to recap, it's sending messages, listening to messages that you subscribe to, and then spawning other actors, exactly, and that's all there is to it. Actors are state machines as well, right? [27:00] They encapsulate state machines, right? 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 events they receive. And that's exactly how a state machine works would. You have a scenario where there's no actor, it's just a state machine? Well, so a state machine, that's. It's like a blueprint, it's a description, it's like saying, there's a blueprints of a house, but there is no actual house. [28:00] So yeah, so then, like, can an actor contain an actor contain an actor like is? There, 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. Like 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 constraint of actors. [28:00] In 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. [28:00] 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 pointto point? Or can you like subscribe to messages so you could get like a multicast type of phenomenon going on? Yeah, so actors are just the building block, and you could create abstractions on top of that. [29:00] So one of the most popular libraries for just the actor model in general is AKA, really popular in the Java and the Scalla ecosystem? They also have the notion of subscribing and topics and other things you might find, like multicasting and all of that. So, yeah, you could definitely build abstractions on top of just those basic actor model rules, like, for example, if you wanted to build your own subscription mechanism on, you know, actors. [29:00] 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 iterate through and message each one of them. I'm still a little confus, sorry if I'm like, super slow brain today, all good, but I'm still a little confused at how an actor. [30:00] Is supposed to know about another actor before they can communicate, like you can't just publish a name of an actor, or is that? Is that what you mean by that? They need to know the name like, or that they need to have contact, 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? [30:00] You could think of Twitter as its own 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 parents 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 could send them a message and say, Hey, you should check out this other actor, this is a reference to that actor. [30:00] Okay, yeah, so you could send through 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. You know, I was born this way, and then, what, the other Maybelline? Maybe she was born anyways. So I think the question I have is like, in terms of event flow, right? Like the thing that flux architectures popularized in the front end was this kind of downwards data prop, event propagation workflow, right? [31:00] And 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 is a library and codes just, you know, whatever things are using IES and function scope in order to like encapsulate, and so there just was never a predictable way to like debug. A problem. Because you never knew, like, what was talking to what, right? [31:00] You know what I mean, yeah. And then we introduced the same pups up pattern and the front end and downwards, data flow and like good component architecture and hierarchies. And so are there some best practices? Or just like recommended flows for events? 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. [32:00] 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, with 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? [32:00] 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? [33:00] And once the right time to read it, it's like, no, it's all just events. You're just sing in, sending an events and hoping that the actor does the right thing with it, and, uh. As far as getting state, it's receiving an events. Whether you're subscribing to it implicitly or you're actually explicitly getting that event sensed directly from the actor to the other actor. 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. [33:00] And so I, I feel like that makes your logic a lots more predictable. And it's something that you could even extract and communicate with, you know, non-technical people, for sure. Yeah, that 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, um. Alec Lavoy, who's a teammate of mine at Indigo, who was the first person to introduced me to XState. [34:00] I had spent a few years kind of away from front end explicitly, because I was 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 worlds. Like, and then? All of a sudden, XState was a thing and 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. [34:00] 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. 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. [34:00] Build in placeholders, and it's just a just a really great communication tool. So really, Kudos, for doing that, M, and kudos to Alec, you know? [35:00] Yeah, yeah, I think touching on that a little bit. Ail you mentioned like an artifact, being able to look at there 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? [35:00] DavId yeah, that's a statechart. 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 hardcoded, diagram, that then you can code against 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 really cool, exactly. [35:00] And it's interactive, so it's like hardcoded, but it's like it's interactive there, an interactive guy to it. MHM, which can all be run in memory like you don't even need to be online, you know? 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 yall are talking about, lets you bridge between things. The thing I'm curious about is, does it handle kind? [36:00] Of multiactor, multi-state 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 XT.. J..org SLV 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. [36:00] 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. [37:00] 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 a sequence diagram, too. Exact same thing. 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 inspector. [37:00] That's just going to let you do everything, whether it's copy paste code in or, you know, inspect applications in real time. So X8 is like, like, framework agnostic, right? You can use this with any framework, it's not, 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. Awesome, don't quote me on that, but I'm really. [37:00] That's a high level goal. And, like, in terms of the S. Because obviously there's a bunch of developer tooling that's not going to ship with your production source code, but like, out of what ships to production. Like, how big are we talking of? A footprint like Hex is a about the same size as Mobx in that regard, around between I think 15 and 17 kilobytes minified, however, in version 5 we're working on making it smaller. [38:00] And if you want to just use basic state machines. And you're like, I really want to pull in all of XState for it. Even though it's only 15 kilobytes, there's something called XState FSM, which weighs in at 1.5 kilobytes. It's really, really, really tiny, it's like XState light. Yeah, yeah, it's a flatter version of XState. 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. [38:00] But for a basic state machine, where you're like, Okay, we, we could draw this clearly as a flat state machine, XState. FSM is going to be your best bet, right? So have you considered calling it Diet Estado CU? That would be a really good name. I don't know what FSM is. You're not letting go of this, are youl? I'm just saying it's such a good name. I mean, you know, I don't speak Spanish, but like you could call it Esto, esto, esto, there we go. [39:00] I think I still have the MPM name, so you know what, I, I might do something with it, just as an Easter egg or something. Just publish copies of what's the latest M, you know, main branch and onto there too, so people can choose to use that back. That won't get confusing at all. No, not, not at all. It's like how React used to be called Fajs. And oh, no way, I didn't know that. [39:00] Yeah, yeah, no, no one really uses that anymore. It used to be called fax, like a fax machine. Yeah, oh, fax. Oh, that's so weird. Yeah, yeah. 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. 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 modelbased testing library. [40:00] 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 just or add Puppeteer play right to that too, and it's going to basically write the test for you, there's also what else do we have? XState Immer if you want to use Immer with XState FSM, XState graph, which is just graph based utilities for XState. [40:00] That's really useful for, like all of our visualization and graph drawing parts of XState and actually mapping out all the states. We're thinking of some future packages, too, besides, like the adapters to React and View and Spelt and all of that. We're thinking about, like a XState router and an XState form, so we're still planning those. Yeah, it's going to become a big ecosystem, just deep Machining goodness. As an example. Would state Router be like a replacement for, like, like, a React router type component, or would it work in tandem with that? [41:00] It would probably work in TANDM? 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. XState Router 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 or, if you click next, then the state machine knows exactly where that next link is going to be. [41:00] Instead of hardcoding it into your application view layer. Oh my God, that's like, even just like hearing that makes me feel good. But yeah, know, I? I think there's a lot of stuff around URL management, source of truth for state kind of server meets, client kind of transitions for SSR apps, like all that kind of stuff I want to get into. And like middle world patterns that were popularized with Redux, like, what's the kind of XState equivalent? [41:00] [Music] what's up, party people? [42:00] This episode is brought to you by micro. AKA. M30 is a new Cloud platform built for developers by developers. Our good friend Asam is leading this. And if you're tired of AWS and feeling overwhelmed by the cloud, infinite billing and an Endless Sea of Docks, it is time for a change. The micro team is reimagining the cloud for the next generation. M30 is a new, developer friendly platform to explore, search, and use simpler APIs for everyday consumption all in one place. [42:00] Get access to the APIs you need in one click and test. Them right there on the web before using them. Simple, fast, and affordable, you won't get burned by bottomless billing. You top up your account and pay as you go. And right now, they're in early development and building up the first set of APIs, and they're looking for feedback from developers. Sign up and get $5 in free credits. Kick the tires, give them your input so they can build the best AP you want to use every single day. [42:00] Learn more at M3.com again M3.com [Music]. Let's bring us back and talk a little bit more about what we were just leaving off on around state machine driven routing. And the piece of this that I want to kind of dive into is one of the ageold pendulums in software development generally. And that we've seen in the front end is between imperative and declarative approaches to programming, and I think we see this in our front-end. [43:00] Frameworks. React is very imperative. Even though it enables a more declarative view of components, view 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. [44:00] 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. [44:00] Just because there's something that seems to go against what a state machine is, which is the fact that 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 state. It's not really super against what a state machine is, it's more like there's these implicit transitions where you could. Just transition to any state at any time. [44:00] 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 and an admin, I can just be logged in and do all sorts of crazy stuff. [45:00] But yeah, 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 Sprouts core, Sprout core used statecharts. A lot. And so this was like, again, before I even touched, well, I, 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 statechart diagrams. [45:00] And that dates back to 2013. I believe so. Yeah. This problem has been thought about a lot before, when Ember was a big advocate of what you were talking about. ML on the break of everything stateful about your UI being driven by your URL and your URL representing your state. Yeah, I'm convinced that, like Ember developer, like the core team, they're like the game developers of the JavaScript community. Cuz, like, you know how, there's that like that, saying that like, hey, everything you've thought of like as your big new idea, like game developers invented 10 years ago. [46:00] Like, I feel like Ember. They they just so many things that like, they did right, Dojo already did that. Yeah, yeah, yeah, yeah, do Dojo too, right? But like. But the point is, it's. It's just amazing to see how certain patterns were in the Zeitgeist very early on. 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, and that's the thing. [46:00] Sometimes people just don't like you can preach all you want, but until. They get burned and or see the merits for themselves. With increased velocity, reduction of bugs, you know, better predictability, like faster onboarding, right? [47:00] 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, you know, it's. 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 on boarding as well as just external stakeholders that are non-technical. It's funny. I wanted to mention, even with game developers, you talk to them about state machines. [47:00] 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, 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, I keep trying to make fetch happen. Bone skull, uh. One of our regular panelist was commenting in the chat about this. [47:00] He's like, why are there so many state libraries and ceremony around state libraries in the front end? In 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 frontend world, in particular, has been so slow to adopt state machines? [48:00] 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 just stopped right there where you're like, we don't like being told anything. Yeah, right, yeah, it's amazing. We even have people listening to this podcast quite person. So yeah, yeah, no. [48:00] There 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 is just fine. And so I'm over 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. [49:00] State directly and Noti. I didn't say mutate state directly, because all of these state 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, and that's a huge problem. [49:00] But yeah, actually takes the approach of, you know, something that's been around for, you know, just many, many decades. And also we. We were talking in 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. [50:00] And ideally, even to users and designers and other people how the app is supposed to work. [50:00] So I could code something in assembly, actually, I can't tell on no assembly, but I could code something in C. Where it's like, Okay, I made this complex thing. It works, don't touch it, but no one else will understand. And I feel like my job is incomplete if the code I write is not understandable by others. Amen. Can we just take a moment of silence, just preach on, Brother? Seriously, that I couldn't agree more honestly. [50:00] Like the other really big thing is that, 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 all these shields, from all these angles, it's like, is this like some function that's used in every file, in every method? Like, why are you being so like, shielded? Like, you can kind of reduce that paranoia level as well in your code, and for me, more importantly, this enables you to. [51:00] 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, optimize for change. Everybody, you know, I've, like, said that like, literally 100 times this week. Because if we're, you know, we have to optimize our code for change. Like, if think that our code is not going to change or that this thing should stay the way it is. [51:00] Like, you are not living in a reality that is like, real world. You know, application development, right? Code is living, breathing, cruft, you name it, like people, you know, come and go, and you know, libraries die. Things need to kind of move on, and you have to be able to, kind of weather. That change and support easy pivots, right? Especially if you're a startup or a small company that's still like trying to validate your product. [51:00] Market fit. You know, right? It's just huge. [52:00] For kind of, I think, bringing that ease of communication and determinism into your applications. Like, yeah, and that's the point. I want 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 going to change. [52:00] Or I need to add this feature. We could know, 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. [52:00] To capture this behavior, 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, is not very much mental overhead. [53:00] 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'd 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, then you know. [53:00] Maybe consider how the different behaviors of your app can change, and you know just what they are. 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 just a simple app like, I don't know even I was thinking of, like the Yo app, where you just like, press yo to your friends. [54:00] 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. We kind of said this a little bit quickly, but like, so, I'm a fan of, you know, your source of truth and your application being in your URL. [54:00] Your applications should always be able to rehydrate from a URL refresh. You know, somebody refreshes their screen or they're in a Wi-Fi situation, you know, like they should be able to refresh and like, stuff shouldn't break. You know, you know, I'd like to kind of understand how XState 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. [55:00] You know if there are tools or UTIls or kind of patterns around, like rehydration of your application state. And this might tie in a little bit to what I was going to ask, too, so I'll just kind of throw it out there. As well, 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 context and providers. [55:00] And is XState like a way to manage that component state that might exist out there, or like some other Global state, or is it more? It should take the rein from that? Yeah, that's two really good questions, so I'll talk about the persistence one first, XState does have a way to basically take. Whatever state your state machine is in, including any extra data, which ITES, doesn't really fall into the finite state category. [55:00] 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 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 St. [56:00] Or at least try, like for Examp, 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. Yeah, but you know what? 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. [56:00] Or, you know, so you're not like repeating a bunch of code everywhere in all these different actors. And so, you know, CU 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, it may or may not trigger some business logic. [57:00] That's in your middleware, for example, like if there's an error like log to Sentry, right? That's one thing you put in your middleware. If you want to normalize some data, if you want to, yeah. So you might be either happy or sad to know that there is no such thing as middleware in XState 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 states and events, and so everything works through that. [57:00] 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. 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. [58:00] XState, on the other hand, says no side effects, which XState 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 oneoff 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, too. [58:00] And so, yeah, 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, 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 before age? [59:00] I mean, yeah, there's different patterns, and this gets sort of 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, do subscribe and handling state changes. That way. Okay, wow, very cool. Does XState work with suspense? In? React? Oh my God, can we not talk about suspense? [59:00] That is a broken API? Does anything work with suspense? That's a better question, I suppose. Yeah, suspenseful and concurrent mode, that was a, something tricky that we were trying to figure out for bad idea. I, I won't say it out loud, but yeah, and that. 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 XState does not work with suspense yet. [59:00] By working with suspense, 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 state. [1:00:00] I think that's a good idea, at least to support, so we're going to just experiment with that. Definitely not priority. 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 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 a good way of using X Dat as well. [1:00:00] 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 of you, some of you slowly 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 definitely have a road. MAPAp. You've got an active, kind of healthy project, and so how can folks contribute and get in touch with you? [1:01:00] Sure, we're, we're always accepting, you know, pull requests, especially for documentation, and we actually have a new. I mean, I should have 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. Like, recipes, yeah, yeah, so the recipes are also in the documentation as well, like how to use this with View or Angular, E.t.C. Yeah, so that. [1:01:00] And also participating in the. Discussion forum so if you go to discord...gg, Exate, 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 Xap being used right now? [1:01:00] Cuz 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, you know, it's not an easy thing. Or something I take lightly. [1:02:00] 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, 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. [1:02:00] And, I was surprised to learned that. There's a lot of companies using XState in production, notably, I mean, Microsoft, even I didn't work in any projects at Microsoft that use XState. It's just like Microsoft's a huge company, so they've used XState in various projects. In, 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. [1:03:00] So you could say that X Dat is being indirectly used by just hundreds of thousands of developers, you know, that way. [1:03:00] It's part of Gatsby as well. Honestly. There's, yeah, there's a lot of places that's being used. I can't think of a project that isn't in Gatsby. Gatsby is like the kitchen sink of like Framewor. It's either Gatsby or Next.js. So yeah, so cool. Well, thank you so much for your time, David. It's been absolute. Pleasure. And yeah, I'm excited to try this in production, you know, please do. It's on my recommendation list for the UI architecture at go Likewise. [1:03:00] Yeah, all right, awesome. And pretty soon I'm going to write a like, getting started with XD in three minutes article. So zero excuses. Nice, cool. Let us know, we'll retweet it. All right? Well, thank you so much for coming on. Thanks Kall and AML for joining, and, we will see you next week. Bye [Music] kids frontend Feud returns next week. We have Amelia teaming up with shop talks, Chris Coer and Dave Rert to battle it out with Divia West boss and Scott Tulinsky from syntax. [1:04:00] I won't spoil the ending, but I will tell you it all comes down to the final round of play. Subscribe now so you don't miss it at JSP Party. FM or in your favorite podcast app, you'll find us. JS Party is produced by Jared Santo that's me with music by break master Cylinder that's not me. We are brought to you by our awesome Partners. Shout out to Fley, Laun, Starkley and Lenoe. [1:04:00] That's JS party for this week. We'll talk to you again next. [Music] listen, listen. X gone, state it to you. Wait for you to state it on your own. X gone, deliver it to you. Knock, knock, open up the door. It's real, with the non-stop pop, pop and stainless.