How State Machines Create Robust Software (Deep Dive)

Welcome to the Contagious code podcast, where we dive deep into code, learn practical skills, celebrate the beauty of engineering, and eliminate imposter syndrome. I am Tes Kumar and I've been building on the web for over 20 years at places like Versel, Spotify, Zeta and more. Today, my guest is David Ked, or as some know him, David Kpano, or as others know him, the state machine guy. David is the founder and CEO of a company called Stately Stat. that is a sponsor of the podcast. And is also the author of popular state management library for React XState. David is a subject matter expert on state machines, sometimes called finite state machines, or finite state automata and statecharts. And really, everything in that space. What's also less known about David is that he is a CSX CSS, excuse me, expert who creates really great things with CSS. And this is somewhat overshadowed, unfortunately, by his state machine activity. In any case, STLE and David, it's found, are just brilliant software and human, respectively.

And in this episode we uncover a number of things. We uncover XState, the need for state management libraries, around in the JavaScript ecosystem. But specifically in React, we talk about when you might need a state management library, and we talk about resolving conflicts with parallel state management, things like CRDTs and so on. We then pivot and talk about Stately, its unique offering through its visualizer, and it's way to model state through your application. We then move to the future of Stately, including, using AI for state machines. And we talk about David's Newish project called Stately agent, which is a way to create AI based agentic workflows using state machines using XState. And so all of this discussion is for you. If you've ever wondered about state management, statecharts, the distinction between statecharts and state machines, React, AI agents or more, this episode is for you. I'd like to offer this to everybody at zero cost.

In fact, this is zero cost, and the way we can keep it zero cost is through sponsors.

Play from 0:00

So let's take a moment and acknowledge our sponsors and then we can get into the discussion. This podcast is partnered with Codec Crafters. Codec Crafters teaches you how to do things using a language. You know, so. Cementing your programming language knowledge and the things that it teaches you how to do, cements your understanding of various tools. Because Codec Crafters teaches you how to build, like Redis and Git and Docker from scratch in a language, you know, so that you better understand those tools by implementing them, and you also better understand your programming language by implementing those tools in them. It's a great way to learn. And they've offered all listeners of the Contagious code podcast 40% off if and when they start paying. To take advantage of this, go to Tj. Ascod Crafters. There's also a link in the show. Notes. The podcast is also sponsored by or partnered with that conference. That conference is a multi-disciplinary Tech conference that means front end, backend, ETC. That happens twice a year, once in Wisconsin, once in Texas.

If you want a free ticket, share this on social media and say, I want a free ticket to that conference and you will enter a raffle to get it again. We thank you to the founder of that conference, Clark cell. We have an episode coming out with him soon. And we are ever so grateful for your partnership. And we can't wait to send people there who listen to the podcast loyally. Now, thanks for sticking around. Here's my discussion with David Kid, David Kid man. We've spent so much time at various conferences, talking about, so many things. You explained, I, I'll remember this. We went out, to get coffee, once very early in the morning, and you explained the actor model to me. And I was like, Yo, we have to record this and tell more people about it. So I, I don't remember exactly which city that was in, but I do remember the conversation.

Yeah, we, we' met in a lot of cities and had a lot of conversations. So, yeah, and and now finally I get to have you, on this podcast that I that I just started. So I'm I'm hugely honored. Thank you for being here. I'd love it if, you could give a maybe a short introduction for the listeners, who you are, what you're up to. U, you're probably best known for XState. We're going to talk about that. But in your own words, stage is yours, sure, yeah, and I'm extremely happy to be here talking to you too. So, yeah, I. I created XState about eight years ago. I founded this company called state Le. A, or startup, about three years ago. A little under three years ago. I, I was at Microsoft. Before that, I've been a developer, for, I want to say, 15 years. I always lose track because what is time?

And yeah, so I also play piano, that's why my username is David K. Piano, even though that's not my last name. It's just what I like to do. You, you have a bachelor's degree right in that, in piano, yeah, that's right. So I went to University for piano, and then I later in my University years, I just transitioned to computer developments. I've always been interested in it, but, you know, being a developer pays a little bit more than a musician. Yeah, it's in both cases, you're, you're sort of playing a keyboard.

Play from 2:00

But one, for whatever reason, is more lucrative than the other. Thank you for that. So Stately, three years in XState ETC. I wonder, let's maybe start by talking about XState, the state management library, XState obviously a solution to the state management problem. Alongside things like, Mobex and Redux, now Redux Toolkit and Joai, I think, and there's a whole, slew of these. Let's zero in on XState. Actually. Maybe we can start by outlining the problem space, like, what are? Why do all these libraries exist? and why is XState one of them? And do they all solve the same problem? Probably so, but do they do? they solve it in different ways? And how does XState differ? Yeah, that's actually a really good question. Because state management, it's, if you look at it as is, it's not really a problem. It's like the language, the natural JavaScript language, or whatever language you're working on.

It already gives you the tools to update. State like this is something that you're taught in, you know, the 101 course of how to work with this programming language. It's like, I know how to update states, but when you get into Frameworks and libraries, that sort of expect you to update. State in different ways. Then you have to consider things like immutability, you know, just, and maintaining the same reference of things if you don't want things to change. So things like memorization, caching and stuff like that, but then things get further, so I see it as like different levels. So, you know, I'm sure a lot of people listening might use React. React already has buils and ways of handling. States. You have used state and used reducer, you have used context, which is arguably first dates, although, you know, maybe not. Yeah, like you could do. I would say 75% of your state management using those hooks alone, Acing state can be handled using well now with reactive the use hook ETC.

Basically, what I'm trying to say is that it? It's an interesting question, like, why are there so many state machine libraries? If it's already pretty much a solved problem? The problem comes with organization and managing more complex dates. So, for instance, if you need to manage dates, that, you know, that need to be Shar between components. You have Redux, that's how Redux became popular. It's like, Okay, now we have this Global store, and XState sort of just solves things. At the further end of the spectrum, where the more complex your application logic gets, you need to think about your state a different way. And so XState Embraces two main things state machines and the actor model, and so with state machines. You define that your app is in specific states at a time, or parts of your app are in specific states at a time. And they can't be in more than one state.

And so a state can be like, uh? Viewing the checkouts page and then viewing the carts or viewing the payment screen E.t.c. It's like, you, you don't want to be in two states at the same time, um. And also defining transitions between those states, and those transitions are triggered by events. And so this actually gives a mental model that makes dealing with complex state, I don't want to say easier, but simpler. It gives you a simpler model, it gives you the building blocks to, when requirements change, or you get more requirements and features and things like that, then. Your state is still predictable, it's still something that you could reason about. It's not something where you're going to tear your hair out. Because you have mess of if statements and just logic all over your UI and stuff, it gives you a nice, centralized place of dealing with your state.

Because logic application logic does get more complex the more features you add to it. And we're not all just building simple apps, we're building really, really complex apps, you know, unless we're making toy projects. So, in short, something like XState and state management libraries in general. They solve the problem of this logic growing in complexity, and that's definitely what XState purports to solve, too. Okay, I, I love that you, you, you know. Something I try to do on this podcast and something I value really high highly is, drawing a line from the basics all the way through to the complex. And and that's something you just did pretty masterfully here, because you mentioned, okay. State management is, look, you, you can do like, let VAR equals value and then update that value. And you're sort of managing state, you're working with state, and you said, that's, that's state 10 one.

And the reason these libraries exist is because state can grow more complex, and you alluded to the idea that state grows more complex. Because, well, there's. There's Frameworks and libraries that introduce those complexities, for example, React will introduce like immutable patterns and so on, and so forth. You mentioned, okay, so. Redux was invented to solve a specific state management problem, which is sharing state across components with the global store. You said XState goes to higher or maybe even extreme levels of complex. And you sort of touched on that briefly when you said when you said async state. But I'm curious, like, what is what is the worst, possible case of complexity look like? And how can state? How can state? XState? Excuse me, solve that. Oh man, you know those YouTube videos where it's like six levels of X or whatever it feels like that. So, basically, I would say at the furthest end, you have, you know, distributed, state distributed applications, where, you know, logic is living in many different places.

You need things. To communicate with each other, you have this asynchronous communication. State doesn't live in one place. And it's like, how do you her, these cats? Basically? Like, how do you make sure that, that your application is still working as expected? When things are just in a distributed, fashion, and distributed computing is hard, um? And so that's why, at least with XState, it Embraces, like I said, state machines, the actor model, which are which were specifically created to solve these kinds of complex problems. Now, because of that, XState might seem at times a little bit, you know, complex for simpler use cases, but, you know, the purpose of it is to deal with more complex logic. Yeah, and it's proven its value. I mean, it's used by a number of large. Last I heard it was used by, like, NASA. Is that accurate? I, I heard some big names using XState, not NASA, but there are big companies is using it, big companies and small companies alike.

It's basically when they see something that fits the problem of, oh, we need a state machine for this, or, oh, we need an actor model type solution for this, and we're working in the TypeScript project. They will do a Google search for all right? Which libraries use state machines? Andor, the actor model? And they eventually run into XState, which, you know, we tirelessly maintain, so it's, it's one of the most maintained state machine actor model libraries. Yeah, you, you, you posted on X. I think it was today, or maybe yesterday, about how open source maintenance can be such a thankless job. For various reasons, and I feel that okay. So state XState solves the problem of distributed state and, and, you know, state that is maybe async and that can have race conditions and so on. It's interesting because listen to listening to you speak about this. I, sort of learn and realize that state management is such a ubiquitous problem.

It's certainly more ubiquitous than I thought, and by ubiquitous, I just mean it's everywhere. Because I think of companies like Neon, right, that do database migrations, among other things, and that is also just a state management problem, because databases, if anything. Else are just massive state stores, and when you have distributed replicated databases, then the state management of the database gets super hard. And then you have companies like Neon E.t.c. That help you those migrations in a in a more seamless way. Whoa, my camera is having a seizure. But all that to say, awesome, thank you for that. Okay, so you mentioned state sort of goes haywire and highly distributed and asynchronous environments. I'm curious then, if how the interplay between XState for state management in these complex cases and things like CRDTs. So conflict, what is it? Conflict resistant data types? exactly? Come into Conflict free Replicated data types, I believe, right? Because that's also sort of a primitive, designed to solve distributed state problems.

Is there some interplay there, or am I just sort of seeing dots that don't connect? Sort of, and so, by distributed? I. I just mean that there's many things happening in your app. So the basically XD is not like kubernetes. Where it's like, you know, you have, you have a cluster of you know things, you know, just needing to, you know, work towards the same problem. It's, and I guess distributed is the wrong word for this. It's more complex states. So basically, you have many things happening in your app, for example our own editor at St. Editor, there's so many things happening. You have to detect, is a user offline or not? Are they panning? are they dragging? Are they editing as states like, and then you have to batch those edits E.t.c. So there's just a lot of complexity in an application like that, and in, you know, just applications that you might use every day.

We're using right now Google Docks, we're using Riverside, and those applications can get really complex. There's so many things a user could do, so, XState really wrangles the problem of there's, you know, many things a user could do. There's many events that could potentially happen, and those events can be from a user. Or they could be some external events, such as data coming in or some signal from something else. Just coming in. And you have to manage the state somehow, so you don't end up in what's? Called an impossible state, and so an impossible state would be something like, you have an error screen, but also it says that you successfully completed the operation. It's like, what that should never, never happen. And so Exed is a way for organizing and managing that complexity so that it's simpler to reason about. Yeah, I, I lost the original question, but that no, that's, that's perfect.

Yeah, thanks. You've debunked a lot of, potential misinterpretations around the use of the word distributed, so I appreciate that. Let's talk about state machines. You mentioned state the. The real edge of XState is it does what it does it. It organizes, as you put it, complex state, using two things state machines and the actor model. So I'd love to dive into both of those. Is it fair to say that XState basically represents a state machine as code? AS? JSON and I want to, maybe before you, you answer that, de like. Talk about what a state machine is for listeners, and there's indeed there's other episodes where we talk about state machines on the podcast. That probably are out before this, but for those, who haven't yet worked with state machines, I think it's an important thing to clarify. Because it's not a it's not a machine in the way that you think of a machine.

It's not, it's not a physical machine. It's not an industrial thing that gets input and does output, right? Like we think of a machine as the camera I'm using, or the microphone, like these are DEV devices, a state machine is not a physical device. Nor is it a human being that grinds really hard, like Sha Wang or Swix. The dude's a machine, but it's, it's, it's. It's a big drawing, it's a big drawing, a diagram with states and transitions between the states. So it's it's like a bunch of circles with lines between them, it's it looks like a graph, data structure. Just to clarify, and if I'm wrong, please correct me. But I think it's so important to capture that for those listening who maybe haven't yet been. Expos to state machines, cuz you hear the word machine and you go, whoa, so okay, the question. There is, is XState? Can we think of XState as expressing that type of drawing, but like as JSON, and then working with that drawing somehow, programmatically?

Yeah, so one of X. State's main purposes is to allow you to represent state machines and statecharts, which the statecharts are state machines. You take state machines to the next level. But I'm going to step back a little bit and ort of explain state machines. For those who might not know in the simplest way, Tes is right. Machines aren't physical devices, although it's funny and sort of ironic that state machines have. They were invented, like, you know, I think, around the 1930s, or just really early on, because they needed to be used in electronic devices. So like these physical devices that, you know, they, they might have a board on it that, you know, needs to control some electronic stuff. I, I don't do Hardware, so I can't see even BS terms with that. But the simplest way I could explain it, especially because it's 6:18 in the morning over here, I'll explain it in sort of an analogy.

Play from 5:00

I. I was sleeping and then my alarm woke off, said, Hey, you have a podcast with Tais? And so I transitioned to the awake state, and so, I became like, I. I went from asleep to awake. Now I can't be in both asleep and awake at the same time. Those are two completely different states, and also there's many different ways that I could transition between the states. I could my alarm could go off, I could just naturally wake up, have to go to the bathroom, things like that, and then the other transition is possible too. I could go from awake to asleep, so if I put my head to bed, close my eyes, then I'm asleep, and so that asleep and awake. Those are called finite states. And so if, like Tes was mentioning, if you envision a diagram, those are like two different boxes, and then you have an arrow connecting those boxes. Saying, I will transition from the asleep to the awake state when this event happens, and that's pretty much it.

Those are the fundamental concepts of a state machine you have finite states, you have events, and then you have transitions, which? Based on an event, transition you from one state to another, that's all it is. And so it's sort of easy to Envision how essentially every single application you make is a state machine at some level or another. Awesome, thank you for that. So then does XState take this collection of finite states, events and transitions and express them in code? And then give you APIs, where you can just be like, go to the next state with a function, call or similar. Exactly. So the main way that XState works is that you define your state machines in sort of this JSON way. That was the API that was most visualizable. I know some people might allergic to writing, JSON, but that's the API we chose. And it's the one that, like, we're sort of like, forward thinking.

So we're like, okay, we want this to be compatible with other languages as well. So, you know, JSON is just sort of this lingua franka for, logic. We don't want to use AML, so we'll just stick with JSON. But yeah, so you define your state machines in this JSON object, and then you put it in create machine, and then you have a state machine, and then you put that state machine in create actor, and now you have an actor, which is an instance of that state machine. So think of the state machine as DNA, and an actor is just someone who, you know like a live entity. You know, it has that DNA, it knows how to behave. Based on that state machine, you could send it events, it has its own internal state. But yes, that's a long answer to your question that XState does. Basically make it easy for you to create state machines and to visualize them as well.

Oh, visualize them as well. Yeah, how? I mean, so do you put, do you? Then take this JSON and plug it into some type of visualization library, and you get a get a graph. I, I. I knew about the create state machines and then interact with them part I didn't. How do you do you visualize it by then uploading it to the Stately editor, or is there a way to do it, like in code? So we have this, actually. I'll sort of talk about the history. So we. We've had visualizers before, where basically you're copying and pasting code, so you copy and paste the exact same JavaScript or TypeScript code that you, wrote to a visualizer. And then the visualizer says, hey, this is XState. I could understand it, and I could visualize all of those, those boxes and arrows, those states and transitions, that I was talking about.

But now we have tools where it's called Stately inspect, and this is also free and open source too, where basically you create an inspector, pass it into the actor you created. And there's a simple API for this. And then it will just pop up a new browser window and say, here, here's your state machine. We also have a VS code extension that essentially does the same thing, but without you having to add any extra APIs. It's just a little, text on top of your machine that says, Hey, do you want to open this in the visualizer or the visual editor? And it will just pop it open right next to you? And so that's honestly the dream where you could write code and then you have a visual representation of the code right next to you. So, in short, yes, yes. XState provides a way for you to visualize your application logic.

In visual state diagrams. This is so cool. That I'm, I'm. I'm a little bit lost for words, because I haven't ever used that. But it sounds like XState, so if somebody wanted to, like, show up and they maybe haven't heard of XState, they haven't heard of you. And they get inspired. They're like, whoa? I want to build, a way to take a statechart, statechart, state machine diagram, and then turn it into JSON. And and give developers a programmatic way to interact with it and visualize it. They. It's only a matter of time, then, until they create XState, because that's that's what it does, right. So, like this is almost I'm thinking about, like a challenge for listeners to learn XState and how it's built. Is. They just like, start by looking at a diagram, a state machine diagram, and then try and implement this code. If they did that.

As a challenge, how close would they come to implementing? Would they just implement XState? Like a basic version of it. I honestly, probably because there's there's two approaches and I. I've looked at so many different state, you know, state, machine, state libraries like that. There's the approach where you're basically imperatively building it up. You're like, add states, add states, add, transition, ETc. And that. It's I guess easy for developers, especially if you're used to those fluent Builder like interfaces, but it's very hard to visualize that. So if you give your users, the or, sorry listeners, the constraints of you, this needs to be visualized able, you need to be able to copy paste this and visualize it somewhere. Then they'd be like, Okay, I need some sort of declarative structure. And ultimately, you will end up building something like XState. And even if you don't know about XState, it's because the way we designed how you declaratively specify a machine is it's a.

It's a mapping, you're mapping states, events and transitions to other states. And so you would naturally think, okay, it's an object like something on this here, on that here. It's like taking a switch casee statement and sort of representing that. In JSON. You're going to get very close to, to, to act state. This is so cool, that's. That's a challenge to anyone listening who wants to sort of understand this library. And also, in so doing, level up their JavaScript and probably TypeScript game. Why don't you try implementing XState from scratch? Encourage it? Yeah, awesome, I say XState, I say TypeScript game specifically, because, I assume there's some really cool type inference type ch Alles there. Where you have state transitions or events with discrete names, and then across the state machine, you've got to have those names be types safed, right? Because it's better to work with transitions whose names you can predict, as opposed to just a string type.

Maybe we're getting too low in the details here, but I think that's a cool challenge for TypeScript. You mentioned statecharts are distinct from state machines, and you said statecharts take state machines to the next level. How? Yeah, so first of all, statecharts are state machines. They're just a different way of. Representing state machines, and this is going to sound weird coming from me, but state machines have some fundamental problems, like big, big problems, state machines, for example. Like, you know, you might say, okay, if you're modeling something where you're either asleep or awake, that's that's easy enough to do, however, if you're modeling more complex things like, I don't know. I'm trying to think of an example, but I can't. However, there's times where might add a state, and then you're like, Okay, we have another state, but you could transition to that state from any other state. So now you have to draw a bunch of arrows from one state to the other.

Or there's a set of states where you know, you could transition to that state. Basically, as the number of states and events grow. If just picture it as a diagram, the more boxes you add and the more events that are possible, the more arrows you have to add. And then, all of a sudden, your state machine start to look like spaghetti. You've heard of spaghetti code? This brings spaghetti to the visual level, like this is visually spaghetti. Like you could think of the States's meatballs and the transitions as little, you know, spaghetti noodles. Yeah, so statecharts were actually invented in 1987 by a, a professor, Dr. David Harel. And, wait, wait a second, sorry to interrupt you, but you said statecharts 1987, and then state machine. So the original thing on which statecharts are built was in the 30s. So there were like 50 years between state machines and statecharts. Yeah, yeah, around the 30s, and that was, Mele and more, computer scientists, I believe.

And then, you know, in 1987, now you have statecharts, and so statecharts, they bring hierarchy to state machines. So you could actually have a state which has child states inside of it, and those child states can have child states. So you get this infinite amount of nesting. And you could transition from any part of like, from a child to a parents ETC, or from child to child, from parents to child ETC. And you have a few other mechanisms too, like, orthogon, orthogonality or parallel states, so you could say which sounds. Contradictory to what I said before, in which you could only be in one state at a time, but in reality, these are still finite states. And so what I mean by that is you could have something that represents, a combination of states, for example. You are, or at least I am, awake and hungry.

You might be, you know, awake and not hungry. But it's like, aren't those two states? Like, how do I represent? I'm awake, but I'm also hungry? So in reality, you're in that combination, awake, hungry. States, and so statecharts just make that really easy to represent, without you having to make a million states that, you know, represent the combination of all of those states. And they have other mechanisms too, like the ability to say, hey, when you enter the states, then execute this action. Which I think is really cool. Because now you bring effects into state management too, which historically hasn't really been done, like state management has just been. Hey, when something happens, here's the next state, or like, when you do this, then just update the states. It really doesn't care about effects. Even in something like Redux, it's like, yeah, we'll just shove that to middleware, the middleware can figure that out. But with something like statecharts, it brings it into the actual application logic, because it does cons consider it to still be part of that application logic.

You have other mechanisms as well, such as, history and things like that, but yeah. Statecharts are just really like a really, really interesting way of representing state machines, so that they scale. And and that's indeed as we talked about. The original problems that XState solve are these highly complex problems, so it tracks that XState would model not just state machines, but statecharts. Okay, you mentioned a number of things that I want to go deeper on. It's so interesting. Cuz I've never been exposed to this, cuz I don't spend as much time in the in this world as you do, so I'm really thankful you're here. You mentioned orthog orthogonality, that is the ability to be in two separate, distinct states at the same time. Yes, and you use the example of awake and hungry. I wonder how? This plays with, states that we may think are impossible, but aren't, for example, the state of.

I'm thinking about lucid dreaming, right? So you're like, sort of unconscious, when you're asleep, but you're also conscious in your dream. Whoo? And so I guess that's where state statecharts really shine. Is they maybe call into question the impossibility of states, and can they sort of highlight, like, poorly modeled state machine jobs? I'm curious if you could speak to that at all, or if I'm just sort of, going off the rails here. Yeah, no, I, I'll double click on. I'm sorry I use the term double click, but I, I will dive deeper onto that. Like, you know, just modeling smells in general, and this is where something like state machines and statecharts really help with. Because if you have a problem in your application, logic, TypeScript, or whatever language you're using, it might say, yeah, it's fine. Like there, there's no red squiggly. Everything looks good.

And in fact, you or your co-workers looking at the code, you might be like, yeah, I mean, it looks fine, it's syntactically correct, the white spacing is correct. Because people cared about that for some reason. You're using tabs, not SPEs. Yeah, yeah, exactly, and then your users might not care either. They'd be like, yeah. The app works as expected until they run into certain edge cases. Or like, they're like, they, they click something and they're like, wait, an error occurred. And there's no way for me to get out of this. Or that was an unexpected state that I happened to be in. Now. Rewind a bit and say that you went back in time. And you use state machines and statecharts. Instead. Just a refactoring of your application logic to make, to make use of these states and transitions. Now you have a visual representation of it, and you could visually see, like, hey, we have a state here that's sort of orphaned.

We forgot to add a line to it, or it's like, Hey, wait a minute this date. It has lines to it, but it's an error state, and there's no lines coming out of it. It's sort of like looking at a map, or like a maze or something, and. Being like, wait a minute, if we go here, there's no Escape, there is no way out of here, there's no Escape. Route. Um. Or just like, Hey, this room exists, which is enti walls, like there's no doors or Windows or anything.

Play from 18:00

And so that's something that humans can really easily see and be like, that doesn't look right. And so state machines really help with that. Because it's like, like I said, it's those three fundamental concepts you have states, events and transitions. And so with all those Lego building blocks, you could see, yeah, that doesn't look right. This is something that we should refactor. And the other way around, like, if you see like, hey, we need to add a new feature or something, it's like, Okay. We add another state, another transition, and it sort of becomes clear how everything fits in. So that's why I really like the visual nature of state machines. It it makes those problems really clear, it gives you a different lens to them. Yeah, yeah, thank you for that. I wanted to ask you exactly about that. For context, we had, or will have, depending on when this is published. Aram Zacharko on the podcast. And and ARTM is sort of the leader of the testing movement, the automatic testing movement, in my opinion.

Like he, he's partnered with, Kent Dods over at Epic web, and he's like leading the charge on workshops about automated testing. And in our discussion, you know, he mentioned how invaluable it is to start with tests always, and he, he didn't, he didn't mention just starting with unit tests. But like, maybe you build a prototype so you don't, you're not religious about it, you build a rough prototype. And then immediately you cover it with test. As soon as some behavior is working, so you maybe not start with test, but you like, testing comes very, very early. Including like, UI like, end to end. He's like, look it, it's only expensive if you make it expensive, and he anyway that episode was very insightful to me because we talked about priorities. Okay, I'm hearing here that there's a huge amount of value in modeling your applications. Flow through time as a statechart, or state machine.

And, you know, from there, your application just becomes more predictable, for your developers and your users, and you. You make sure you're not ending up in some weird state where, like, Oh, we forgot to add a line here and now the user is lost. We're, we're in a room with only walls and nothing else. So I hear the value. My question is, when should we add this value? And I'm asking you this as sort of the preeminent leader in the space, right? Like, do we? You can laugh at that, but it's true. I mean, do we do? We start with the statechart before building a product and go like, Okay, what, what, what are we doing here? Or do we build a prototype? Like, at what stage in the software development life cycle do statecharts or state machines really add the most value? And I will preface this by saying, I once built a extremely complex piece of software.

This was before the whole AI, I think this was in 2019, where it was automated vetting for code challenges submitted by job applicants. So we'd give them a code challenge with predefined rules. They we didn't obviously share the rules, and they, you know, upload the code repo and our system, the system that I designed, would unzip the file, read the thing and make decisions based on the quality of the code. Of course, this, the final say, was humans, but it helped humans a lot. And this thing I, I realized how it was going to be so complex, um. And so I modeled it using a state machine first, and it was extremely insightful to me. Like I, I could literally see. Oh, I haven't thought about that transition, I haden't thought about that edge case, I hadn't, and so it made my software more robust. To start with a state machine, since then, I've not done that because I haven't considered the various products I've worked on to be like that complex that I would need a state machine.

And so for me, it's like, if I feel like it's going to get super complex, I would. But if it's just like a to-do list, I'm not going to do that. So I'm curious if, given all of that context. If you could speak to, like, when's the best time? And for what use cases? Should we maybe start with state machines or not? Yeah, so that extremely good question, I would say that's, it's. It's always a good time. And I know that's sort of a wishy-washy answer, but it, it's really true. State machines. And at least this idea of software modeling, and especially visual software modeling, it's so useful at every stage of the software development life cycle. So, let's say that you are creating your app, or your Todo app, or something like that. Even if it might seem simple, you still want to list out, like, Okay, what can people do?

In this to-do app? They could create a to-do, they could edit a to-do, they could remove a to do, they can. Market as completed ETC. So all those things I just listed are things that you would probably naturally think about where you're like. I want to build it to do app. Here's all of the features, all the use cases that I want from it. And just by listing it out, you're already doing software modeling, at some extent, you're already modeling, here's how it's supposed to behave. Like you, you're an experienced, extremely experienced developer. I mean, even your live coding is like, miles ahead of, like, well, what I've seen other developers do, and basically, I don't think an experienced developer would just be like, Oh, that's a problem, I'm just going to immediately start coding. No, it's like things are either going on in here, or you have a whiteboard or you have something like that. So you are doing modeling at some extent, and state machines really help with that now.

State machines are, you know, formal structures, so it might seem like Overkill to use a full state machine. But at least modeling things out where it's like, okay, if I'm building a shopping carts or like some sort of store or something. I could at least model some of the flows and be like, all right. Well, you know, the user could be taken here, here, here and here and just draw a nice line with five or so states. And then you would. As you're starting to code, you could use that as a. Reference. So you don't need to use that in the actual code. You could just design it out and be like, Okay, what I'm coding matches the idea or the model of the software that I've planned ahead of time. And also, like, let's say that you've decided not to, or you've already created a model. And, you know, you're really deep in the code.

You've written thousands and thousands of lines, and you're like, Okay, you? You were talking about testing, so it's like, well, now we need to test it either manually or writing end to-end tests for it. Where do we even start? And so that's where things like state machines really help, too. Because instead of saying, the user logs in, they click this, they click this, and then they. They end up in this screen. And then you write another one, lather and repeat. It's like, wait a minute, just draw out like a map where it's like the user, they could log in. That login could either succeed or it could fail. If it succeeds, the user could go here, here or here. If it fails, they could click forgot password, or they could go back, they could try again. You're mapping all of that out, so now your tests become like, just draw a path from the start to every other state, and you could visually see.

Did we cover all of the use CAS cases? Did we cover all of the paths? And so that's where state machines become really, really helpful there, too. So really, at all stages of the software development life cycle, you know, just modeling using state diagrams, it's extremely useful. If, there is, though, like, an upfront time investment, that, what? What I'm hearing from you and you're biased, is that time investment is worth it? Because it pays dividends over time. And this is also my experience with my big like AI software rating system. Yeah, I. I just like, I'm wondering how to reconcile that with, you know, fastpaced VC startup move fast, break things. Is it shipped yet? where's the UI? is it shipped yet? Where's it? And so if you tell someone, like two weeks later, like, yeah, no, we're just like still modeling this thing as a state machine, and um.

Oh, wait, so you haven't written any code? What? I was weaned in this culture. I, I. I don't know about you, but like, for me, it's it's all about shipping. Like, why is my product not there yet? And if you tell someone, Oh, I've just been drawing, drawing a statechart, I don't know how long it is until you get laid off, unfortunately. So, I don't know, like, could you speak to that? Maybe we can talk about your company, stat., and how you built that? Did you do that when you were building? Stately? Like, did you start with? Like, I'm going to model all of this first and then build my I don't know my editor? Or was it more like I'm going to start building, then come to the state machine? Then, like a ping pong between the diagram and the application, it was a mixx of both.

And I think that's a really good example. Because Stately Le, at, you know, Stately Le.. It's an example of something that's very, very complex. Like, I. I would be hardpressed to find anyone who built something that's just like Stat Le.. A, which is basically a diagramming tool that outputs to code and also inputs from code. It's just super, super complex, at least on the on the coding side. And so as a as a startup, there were times where, first of all, XState. We have around 50 or so state machines just powering various parts of the application. But at the same time, we have a lot of legacy code. Where I decided to just do some Cowboy programming and I'm like, Okay, I just need this to work. We're going to refactor this later, that later part has not come yet. So, you know, there's stuff where it's like, H. I. And something that we've often said was like, I really wish this was a state machine, you know, it's either something's a state machine, or it's like it's should really, really be a state machine.

But yeah, we definitely have a mix of both approaches, and especially in a in a startup world. Something that we liked to do a lot as a team is, even if we weren't going to use XState directly on something, we would. At least pull up the Stately editor or even some other diagramming tool, and model it out as a state machine. Because as far as a time investment for drawing boxes and arrows, you're looking at minutes like five minutes. Like, Hey, Tes, can you draw me? A quick flow of how you envision this feature to look like? It's going to take you like a few minutes on TLD draw or Excal draw, whatever you're using, I really, really like T draw. But yeah, that like that's almost no investment, and that's actually that is a small investment that pays off really, really well. It's just coming up with a plan ahead of time.

You know, so, uh? But doing something like learning the full power of statecharts and all of its features, and trying to adopt 100% of XState? Of course, that's a huge investment and it's not something that, unless you have a really, really good reason to do it, I would say, you know, stick to the basics first. At least just use state machines in a modeling capacity, because that's going to be very, very little time investment. And it's going to really help a lot. Because that serves as documentation. When you need to add features, you could reference previous models that you've created and say, like, Okay, I know how this feature will fit into it. Or wait a minute. There's these things that we need to consider. So, yeah, yeah, I think, maybe, and I'm. I wonder if listeners can relate. But for me, I, I see forethought and this is bad.

Play from 32:00

This is me, like confessing my own inadequacy here. I. I see for forethought as like, this is going to slow me down. And I love that you. You directly debunk that by saying, look, it's just a f minute thing and just write, write, a draw, a diagram, it's it doesn't have to be a complex diagram. But my fear is, and I think this podcast is evidence of this fear. I'll tell you what I mean. I tend to have this tendency where, I go down rabbit holes, David, I go down like long rabbit holes. And so for me, I, I, I'm scared of falling into the trap of Okay, I'll take five minutes. To draw this diagram but then I'm like wait wait what if and I keep going and then my five minutes turns into an hour and I guess this is where my sort of apprehension comes from however in saying this I realize it's actually good to go down that rabbit hole because if you don't go down that rabbit hole at that stage you're going to build some product that's going to have holes in it literally that you'll have to go down much later so yeah s I'm just sort of preaching to myself here based on what I the wisdom I got from you and you know what I think it's something that is definitely going to augment my software workflow so thank you for that let's talk about transitions you mentioned state machines have discrete finite states and then there's transitions between them triggered by events when I think of transitions I clear right like it's it's the edges between the nodes I also think of my mind goes to marov chains because these pieces of chain these diagrams are basically at least to me state machines because they represent a discrete amount of states and you and the probabilities of transition that's basically a markup chain so you have like four different states circle as you can think of them and then there's lines between them and above the line is like just a number like the probability of this transition is this much the probability of that transition is that much and I'm I'm no stranger to the idea that Markov chains are used in and statistical analysis and predictions and form the basis of like natural language processing and you know over time are very closely connected to if not directly influenced the development of neural networks deep learning large language models all the AI stuff today so my question is there a path from state machines and their transitions to then predicting those transitions using something like Markov chains and ultimately putting the AI in stat. a or is that the connect or is I guess another way of asking the question is since you model everything ahead of time with state machines and transitions and a state machine is a long lived diagram that represents the logic flow or the flow of an application it's is there value is does XState help with predicting the next state U as well can I guess you can in theory you can as middle and I'm thinking out loud here but you could every time you fire off an event persist that event to some type of log and then use all of that transition data to predict the next state okay big question but basically what's the application of AI and XState and why does Stately have state. AI oh man this has to be one of my favorite questions first of all stepping back to Markov chains yes you can represent Markov chains using finite state machines your intuition is absolutely correct like those boxes or well Markov chain are typically circles so those like circles and arrows like those are essentially you know state machines and like you said you have you know you have markof chains and for those who don't know markof chains are just like you know predicting or it's like a chain of man well what's the best way to describe it I would say like all right tees so if I if I have a letter T it's like okay what could the next letter be it could be a it could be E I O like it could be a vowel or I guess like consonant or something so now let's say it's like e right so te it's like okay is the next letter an X is a text it's like the is the next letter A T A T or a p or whatever it's like there's so many different possibilities but then the third letter is J and then all of a sudden your Markov chain starts to narrow because there's only so many words that start with t e j in fact I can't think of anything else except Tes right and so you could basically combine the entire dictionary into this one large Markov chain of like all right all of the words are represented in essentially this treel like structure so yeah that's what a Markov chain is and then you were talking about probabilistic Markov chains where it's like when you go from E to J, the probability of that is much lower than something from E to X, or E to some other common letter.

You, you have a unique and a great name, so, yeah. And so bringing this back to finite state machines, this is actually like, there's two angles to this, there's both. The practical angle of like, how are state machines useful to me now, even if I don't care about the AI stuff? And then there's the futur looking angle of how are state machines useful in? The AI world in the world of predictive analytics and things like that? And so the answer to both of those questions is that state machines provide this formal, declarative structure for all of your application logic in a way that normal code does not. So, you were talking about like we could encode things like states, transitions and events, and so just like analytics tools like, mix, panel segments, E.t.c. They, they sort of capture everything. State machines can do that in exactly the same way. Because the only way that something can happen is by an event, so an event causes a transition and you could capture that.

So imagine you have in a Pendon database where you just have a huge list of. Here's all of the events that this DAT machine received. You could just replay those events and because of what a state machine is, you will always like. You are guaranteed to get to that same state if you just replay all the events in exactly the same order.

Play from 43:00

So now take that to the next level. You have this nice declarative representation of everything that could happen in your app and add weights to it. So what are those weights? Those weights are what users are actually doing in the app. So let's say that, I, I actually did this back when I was working at Microsoft. In VSS live share, we had the general flow model as a state machine. Of course, by me, and so I like, we could actually just take all of the events. And then I used D3 at the time. But I was able to create this visual diagram of, it sort of like a heat map. And we could see that. Like, Hey, a lot of users who? Are trying to do this end up in some failure states? And so it was extremely clear, like you could see this big, thick red line going from one states to another. And it's like, Okay, let's dive into that, let's investigate what's happening there.

So now you have like these weighted transitions, so to speak, where you could visually see these transitions are being taken more often than these other transitions. And so, yes, you could feed that into AI and sort of essentially predict user behavior. For example, if you modeled all the features in your application, you could actually see which features are clicking with people. Like which ones people are using the most and which ones are not so much being used. And then you could see based on inputs such as like, what kind of user is using the application? Like, what are they most likely to do next? Like, given that they're in this state when this event happens, what's going to happen next? And so you could extrapolate from that just, user behavior. So I think there's a lot of really interesting applications. You could sort of tell that I've been thinking about this way too much, but, yeah, it's exciting.

I, I don't. I don't think it's too much. I, I've been thinking about the same thing. And just to be clear, Markov, so I actually built this is the this is what I'm about to share is a great example of Marov chains, what they're useful for and why when they fall apart. Because I, I built a Markov generator, which a Markov generator is just like is. Is. IS is an application of the chain, where a chain will help you predict the transition from state A to state B. And I loved your example of my name, thank you for the compliment that it's unique. I, I. When I teach Markov chains, I typically use the weather as an example, because the weather has, depending on how you interpret the weather. Finite states. It's sunny today, it can be cloudy tomorrow, it can be snowy tomorrow, it can be rainy tomorrow. So we have four states and you, you have a list of transitions, so from Sunny to cloudy, from Sunny to Sunny, from Sunny to snowy, E.t.c.

So you, you put these in into a matrix, into a table where the rows are one state, the Columns are another state. And it's just a mapping from this state to that state. And then you in. In the Matrix, you have the probabilities of transition from state A to state B, and that's your, that's the that's your transition Matrix. And if you then look at the most probable next step, or the if you're in state A, the probability according to this transition Matrix of transition to state B. That's the basis of a Markov chain anyway, so with that, I. I built a Markov generator, which is you just take the highest probability next thing based on the current thing. Of, I built a generator of Kenty Dod's posts on X and Twitter. And I, I. I decided to build. Like, okay, if, if, if, I could predict the next word from Kent based on the current word from Kent. So, of course, you give, give it a seed word like the, and you say, give me the next 10 words that come after this.

This thing was kind of ridiculous and silly, and it was silly because of the it was silly because of the mark of property. And that is, you can only predict the next state based on the current state. So it's memoryless, it has no memory, right? And you were talking about assigning weights to transitions for UI, that is so cool because I think that's the key. Because you can based on the weights make decisions, and this is the basis of neural network. It's like transitions with weights. That's all it is. And it becomes machine learning when you do back propagation.

Play from 49:00

So when you arrive at a target state and you go, like, Okay, what? What are all the transitions that led me here? And adjust for efficiency along the way. So I see a very clear line between XState state machines, Markov chains, neural Nets, deep learning, AI. Like like that. That's very clear to me. And I'm really happy that you see that as well and you're thinking about the same things. Does Stately the the visualizer have affordances for this? Yet? Is that something youall are working on? What does that look like? In terms of like a productized version of this yeah so we are working on that you know it's it's something that I thought about early on and when looking for a domain name like stat.com of course was taken it's a fashion subscription brand they keep emailing me saying like hey would you like a subscription or but you know I I have I have conference hoodies and t-shirts that's my entire wardrobe I don't really care but no we found St le. AI and I'm like you know what there's a lot of applications of state machines in AI and even when you look at very basic AI like let's say that you're playing Pac-Man how do the ghosts operate like how do they know to chase you and to hunt you down and to eat you or whatever they do to Pac-Man I think Pac-Man eats ghosts and ghosts just spook Pac-Man or whatever but those are essentially powered by finite state machines where it's like depending on the state of the game and what's happening the ghosts are going to behave a certain way such as when Pac-Man eats one of those pills or whatever it turns the ghost or cherries I think it turns the ghosts into well it makes them transition to a fearful state where they run away so state machines are actually the basis of a very classical artificial intelligence in games and then things evolved from state machines such as behavior trees and of course statecharts and things like that but yeah if you get further into it yeah state machine oh sorry just getting into the original question with state. you know we've always thought about this and it's always just been sort of a back in my you know mind idea and then once the whole AI craze SL bubble like the LLM Craze that we're in right now came about we're like you know what we could actually really use this to help people create and modify these state machines so one of the features I use most on state le. a is you would enter a prom or a set of user stories or a feature you would like to create and it would actually create that starting state machine for you?

And there's a lot of things that go into that. Because obviously with LLMs, it's like you give it an input and you expect some sort of natural language text output. So it's like, how do you actually create something that's structured, and, you know, outputs an actual functioning state machine? And so we've managed to, you know, use LLMs and, of course, XState itself to help do that. But things thinking about what you were saying, yeah, there. I have so many future ideas on just how we could take this technology to the next level, how we could represent or derive state machines from large state spaces. Such as all the different ways a user can interact with an application. And how we could actually just take that, feed that into an agent and have agents act like users, which really helped. Because it's like, imagine that you have an end to-end test where it's like, uh?

Make sure that the user can buy a product and that the user will actually want to buy a product. Like, how, how the heck do you test that? You can't really test, like human psychology or human behavior like that? But now, let's say, like you said, let's say you have a huge Markoff chain where you're. You actually have a ton of user data on, like, here's how users actually behave. You know, put that into a state machine and say, like, is this transition more likely than the transition? Of them saying, you know what, I actually don't want to purchase this, um? And then now the connection between state machines and AI becomes really, really useful for things like predictive analytics and agents behavior and things like that.

Play from 53:00

Yeah, can, can we talk about that thing you built at Microsoft with the weighted transitions? Is that open source? No, unfortunately, it's, or actually it might be, and it might be gone by now. It was part of VS live share, and given this was like, over five years ago, you know, things changed. So, but that was actually. It wasn't using XState, it was using that simple object mapping idea where it's like, state event dat, state event dat. Like the exercise that your listeners will hopefully do in creating their own state machine. It, it was essentially that, and then we just sped that into D3 and then it, it just output a weighted graph, but how did you calculate the weights was? Were you on every event, were you, incrementing some type of counter and some type of state store? Or, oh yeah, so basically we have, transitions, and so a transition is state plus event.

So like, given you're in the logged out state, you have a login events, so now you're in the logging in state. So that combination of log out state and login event, that's a transition. So we actually, read, I think it was called Custo. We, we had analytics, so we were capturing all of those transitions. And then based on the count, so we just do a simple count. And so it's like, oh, you know, we. We could just, map that to the weights on the graph, right? So these transitions happen super often. And so we probably normalized that to a percentage, and that's the percentage exactly. And it's probably a okay cool, that makes sense. I think a killer feature for Stately would be back propagation and weight support. Because at that point, you're just creating like a neural net, just in the product itself, and you could really demystify.

I feel like, look, AI engine ing is such a fascinating topic right now, because how do people define it? At this point in time? It's defined as just make a fetch request to some foundational model, or even a fine tuned model. It doesn't just make a request to, like, replicate, and pull a response and then use that response in your application. So it's it's the application of AI to solve problems, it's the application of AI in engineering, AI engineering. There you go, and that's cool, and it. It unlocks a lot of jobs and a lot of specialization. But I feel like it exacerbates the Mystique around machine learning, especially in in the front end space. Right? Because you have people now like querying GP4, but feeling more imposter syndrome around conversations around like, how is it trained? And the ethics of it? Like all of this is just so lost on people and I feel like Stately could play a role in.

Like, no, no, no. This is how neural Nets work, and we'll help you train your own basic rudimentary neural net, which is just weights plus back propagation. So, I don't know, I, I, I. I don't want to tell you how. What features to add, but I think that's such like I would be so, enamored by such a feature. Because I haven't seen that anywhere on the web. Yeah, no, yeah, I think that's really exciting. Yeah, so, I guess there's the education angle of that, and there's also the UM. Basically just visualizing your app logic in terms of, like this sort of rudimentary neural net. Like, yeah, just to, you know, summarize this topic. You were talking about Markof train chains. And then not having history. But then all of a sudden, if you add history, now you have RNNS or recurrence neural networks, and then now give those RNN's attention.

I'm drastically simplifying this, but, you know, give those attention and say, hey, here's the specific history I care about. And now you have LLMs, so it's sort of all comes together, connected. I found something interesting, that you said, because you, you're talking about state machines, and that they were, not necessarily invented, but first communicated in the 1930s. I didn't know that was surprising to me, because, um. Andre Marov published his first paper on Marov chains in 1906.

Play from 57:00

And so it almost is like Markov chains, which are really like, close to finite. State machines, were 30 years ahead of state machines. Absolutely wild. I wonder if we can talk a little bit about the actor model. This is, this is the topic, this is something you talking about, a number of conferences. Maybe we can just start by defining what that is. You sort of alluded to this early earlier, where, you create a machine with, XState, and then you can create. I believe. You said, create an actor from that machine, and you defined an actor as an instance of the machine. So you get a machine from create machine, XState and then you get create actor and you pass in the machine. What does that, what does that all mean, like, what is an actor? Maybe fundamentally, as a high level? Concept and then an XState what does it mean as an instance of a machine? Yeah, so the actor model is another one of those really old computer science topics. It was, invented in the, I think, around 1970s.

You, there was Carl Hwit, and then also Gou. AA, you know, both, professors or something. I don't know their exact professions, but yeah, point being is, it's a really old topic. And you were talking about Markov Teain. Like state machines, I would argue, have been around since. This is going to sound crazy, but ancient times, just going back in that, I, I know it sounds crazy. But they're Technic, technically called finite state automata, and if you think of an automaton, that's essentially what is. So, instead of a machine, it was called automaton. And that's a much more intimidating name than the machine, so I could imagine that's why they use the word machine instead. But in at Tomaton. Like, you know, those toys where it's like, you, you spin something and then, like something, pretends to like, act or do something like a figurine or something. It's like, Oh wow, you're making something actually come to life just by spinning this thing.

So you could imagine how that was created in, ancient times. Like, with these cool mechanical properties, that's that's essentially a state machine or an automaton. So yeah, there you go, so so a crank, a crank and a lever is what it sounds like that. But like those, it could get really complex. Like they were basically child's toys, where it's like you have two things, like communicating with each other or pretending to eat food. You know, those kinds of toys, I bet used, I bet they used these to build the pyramids. You know, I'm, I'm sure, I'm sure in some anyway. But yeah, going to the actor model, another pretty old, or, you know, relatively pretty old, model of computing. I'm. I'm also going to explain this in simple terms, just like my asleep awake analogy I am an actor, I am a paid actor. No, I'm just kidding, but like, if you consider me an actor and you an actor, it's just of actor in terms of.

Entity not someone who does something on TV or whatever, but just in entity. And as an actor, I can, send you messages, so right now, that's what I'm doing. I'm talking to you. You cannot read my mind, I cannot read yours, uh. So we all have our own internal state, and our internal state is what's going on inside here, our thoughts and everything like that. And the only way that you could really know some sort of representation of my internal state. Sorry is if you ask me, that's okay, so you, you ask me and I will respond with a message. So it's all about message passing, so we're actors passing messages to each other. And then, depending on the messages we receive, we could change our internal state and that's our behavior. So, for example, hopefully not. But I might say something that triggers you, you might say something that triggers me. And then all of a sudden we're angry or something.

Or we might say something that makes each other really happy. So that changes our, our internal states, and that's our natural behavior, our behavior dictates. When the actor receives this message, this is how they're going to respond to it. And so that's essentially the actor model. They are these entities that have their own internal states, and they could receive messages, and they could also create other actors as well, so they could spawn actors. And then you have the fundamentals of distributed computing. Because now you could envision these actors basically living either right next to the other actor or in some remote location. So some other server, it doesn't matter, it's location independent. And so, yeah, the actor model is just a way of modeling computation in terms of these actors that send messages to each other and have their own internal states. So, just to bring it in a practical example, just like you could see state machines everywhere, you could see the actor model everywhere.

A client is an actor, a server is an actor. How do clients and servers communicate? By using this protocol called HTTP. So same thing, message passing. They all have their internal state. You can't read a database directly, believe it or not, you have to ask it, you have to make. A get request. Then the database will choose, do I actually want to send this person back some data? It's just message passing. Wow, I can't unsee that. So the actor model has been around us this entire time. Yeah, and then with XState I, I have a machine that models state transitions and I pass it to create actor. And what do I get? Do I get something that can receive events and augment internal state? Is that the programming primitive I work with? When I call create actor? Essentially? Yeah, so when you create a state machine, you're creating actor logic, so that's the behavior of how something works.

To make another analogy, it's sort of like, re. So when you create a UM. Or when you define a component like a button or a date picker or something like that, you're you're actually defining the logic for the component, you're saying this. Like, an instance of a component will have this internal states. It will have these used effects, hopefully not too many useEffects, and it will render these things. But you're you're not actually defining an instance of a component. It's not like, oh, I want five date picker, so you're going to copy and paste five different date picker functions? No, you're just defining the logic and then in reacts, you're like, Hey, I'm actually going to loop through this and create five different date Pickers. Those are instances of that component, so you could think of the state machine as the components definition, so the definition of the logic. And then an actor is an instance of that logic, right?

And it doesn't have to be a state machine. Actually, it allows you to represent logic and things like reducers, promises, observables, E.t.c. But it's all the same fundamental concept where you have an internal state, you receive an event and you will transition to another state. And whether that transition is done by a state machine or a reducer function, that's totally up to you. By by a state machine or reducer function, do you mean an actor or reducer function? No, so, basically, you do need that actor logic. That says, if I'm in this state and I receive this events, then now I'm in this state. And that could be a simple function, and. A state is just a more advanced way of representing that, or a more formalized way, rather, and a promise. A promise is sort of a simpler way. Because it's like, I don't care what event you give me, I'm just waiting for an event.

That says, Hey, you resolved or you rejected. That's the only events I care about. And then it, it will change its internal state to say I have resolved or I've fulfilled, and here is my output. Awesome, yeah, thank you for that. I. I want to talk about Stately, in a more like, narrative style. I also want to talk about your experience as a CEO. But I do have one final sort of question about XState, because I think that's, it's, it's. It's just at the top of mine and I find it super interesting. Can we, like, build in memory? And of course, there's a read, me. Of course. We'll include all of this in the show notes. But as a little exercise, a reasoning exercise, can we build a to-do app, in memory? Using the actor? Bottel, just to understand? So this is my best guess, and you can maybe tell me where I'm wrong.

I first model all my states and transitions as a JSON object. And I pass it to create machine, and this is my machine. I get const machine equals create machine, whatever. Then I get this machine and I pass it into create actor, and I get back an actor. Let's say it's, it's identified by const actor. And it's a to-do list app, so I have states like, done, let's assume it's one to-do. Even for simplicity, have a state like done, not yet, done, invalid. Maybe, what would that like? How I, I don't know this is where I'm lost, is it, is it? Act, actor., act, and then I pass in the next state. I, this is where I'm. And of course, there's a read, me and so on. But like, for the people listening and who are now like entrenched in this discussion. How would using an actor look like?

What's its application? Okay, so, an actor, at least in XState, the actor interface is pretty simple. So we've already, you've already defined the logic. You're like, hey. Here's a to-do app you could add to-dos delete to-dos modify to-dos which are all events they're just events that you can send to the actor and I just said the API it's just actor. send and so you would send create to do you would send so just like Redux or you know things like that you would send update to do you would send deletes to do and then how do you get the states well you could subscribe to the actor because essentially an actor is a stream of different state changes so you could do actor. subscribe and then that states you could just observe every single state change or you could get the snapshot synchronously by calling actor doc at snapshot and it's called snapshot in X8 instead of states because state is meant to be internal so a snapshot is a externally facing representation of that state which might or might not be the actual internal state so for example you're if you're reading from a you're not getting the actual state of the database you're giving whatever the database chooses to share with you based on you know what you gave it so you're getting a snap shot of the database so if you update that data you're not really updating the database hopefully yeah so yeah that's so cool okay and now that you mention it like that I see so the I see a whole Multiverse of things open for example if I subscribe if I subscribe to an actor and I get back a snapshot of the state every time something happens including maybe an event then I can propagate those transitions and or the state into some type of analytics database where then I can you know calculate weights I can do that I can do this whole neural net piece we talked about by subscribing to an actor I can also trigger new events etc okay this is cool thank you for that I fully understand now the application because it also simplifies like application code if you define a bunch of actors and export them or even make them into npm packages because you can do that right then you would in an onclick handler for a button just do like, actor. send and that's it, and then you.

Play from 1:01:00

The logic follows, Okay, that's so cool. So it's a centralized way of also storing state transition and then dealing with that, that is so cool. Yeah, thank, that's essentially that's what XState is, really. You could you, that's so. And you could also then, create agents, right? Because you could subscribe to events and environment, and have these agents that do tasks as well. Based on, like, what's happening in the environment. How far off am I from? Like, something? PR, Oh, you're right on. In fact, I'm creating a package. I, I haven't really advertised it yet. It's called Stately agent, so at St. AI agent, we have some basic documentation. It basically makes it easy to work with LLMs, but essentially an agent in terms of, you know, AI. It. An agent is something that it sort of observes in environments, just like you described, and it's, it. It takes action based on that, based on the goal, so an agent might have the goal of win.

This chase chest, sorry chess game and so based on the environments, which is the chess board and the move that the player just made, it's going to decide. Okay, I'm going to move this piece here because I think that there is a path to reaching that eventual goal. And so we might have this internal state machine of like, here's how the game operates, and it could use that state machine to evaluate. Here's all the different possible, you know, possible plays that I could make, and here's the one that's probably going to get me closest to winning. So, yeah, you're absolutely right. An actor is just something that has internal state receives events, and it determines what to do based on the events it received. And so that's what an agent does, too. So honestly, they're, they're exactly the same. This is cool. I could then build using XState.

Man, you've, you've unlocked so many ideas based on this discussion. I could, I could, build a state machine that is modeled after some type of conference, let's say, I don't know J.S. Budapes, you're going to be there. I can build a state machine that models a bunch of states such that, conference happening conference scheduled, CFP announced, you know, conference happened, something like that. And transitions between them. And I. Could, you like, going from there? From the basis of that state machine, build an agent that, when the transition happens to CFP announced. Then, go submit a CFP, and if you're, if, if this agent package Stately agents integrates with LLMs, I could have it even generate a title and abstract. For me, that is completely novel, based on things I've just been talking about on social media. Whoa, that's, that's wild. I. I need to play with this package.

Even if there's rudimentary documentation that is so cool, you could literally build yourself a Jarvis. And it's, and it's Pro. So I. I've been thinking about this and this is a tangent. I don't know if we should go down. I'm happy to, but like, I love it, I've been thinking about this, about AI and LLMs. An inherent limitation today is that a lot of it is, reactive instead of proactive. Like, you know, you have to give it a prompt and then it helps you. But I know some folks in the space that are working towards AGI through proactive AI, AGI, by the way, just artificial general intelligence, and one limitation is AI is reactive, not proactive. But there's folks over at Vel. This is Kyle Simpson, the author. If you don't know JavaScript yet, he's now co-founded a company called Vel V. and their whole business is we're going to make AI proactive. I can hear you typing and looking up, but they're so what?

What they do is it's local first, so your data is protected and you log in with various providers and in a in a secure way. They sort of read your notifications and and proactively, like, prompt you like, just so you know you're having dinner in two weeks and you haven't had Mexican in a while, so maybe make a reservation at that place. In fact, I make it for you wild, right? So I see Stately agents as solving this case. And that's. That's a future I'm super excited about. Yeah, yeah, and to bring it full circle. I think that state machines. Are extremely useful in AI programming, so not just the original example, I talked about where they're using game programming, but actually for agent behavior. Because you do want some something that AI is sorely missing today, and some of the disadvantages of using AI are. It's not deterministic, which means given a an input, you might get different outputs.

Play from 1:12:00

It's not predictable, you have no idea what the AI is doing, so, and it's, it's not explainable. You have no idea why an AI, like an LLM or something, reaches a certain conclusion or decides to do something. So, steam machines are like the polar opposite, but they could be used with AI. Because, they provide constraints, they provide guard rails. For. One of the best examples I've seen was, I think someone posted this on X or Twitter or something where, they were basically just, uh. There was a car, chatbot or something, or I'm not sure if it was a car, just some other website, they had a chatbot, of course, like websites left to do. They're like, Hey, now we could replace our humans with this AI LLM powered chatbot. And its main purpose is to help you out. However, this person was doing homework and it's like, Hey, I don't really care about that, but please solve this math problem for me, and it's like, free ChatGPT. And because the agent was like, Oh yeah, sure, I could help you with that, and you know, there were no constraints.

It's just like, Hey, give me an input, I'll give you an output, uh. However, with things like what you were talking about filling out a CFP, etc. It's like there are times where you do want, even these free LLM agents to actually follow a specified path and follow a certain series of steps to reach a goal. Which is, you know, fill out a CFP for me or do these things in this specific order. And so that's where state machines can really, really help out there. Yeah, and they can also probably play a role in making sure the machines don't kill us all and take over the world. As you talked about. G. Yes, yes, not. Not that I'm a Doomer, but if you ever meet a Doomer, you can. Just be like, no state machines, it's okay, it's going to be soled cool. Let's talk about Stately.

You. You built this library, extremely popular, you, you. I'm assuming you built it when you were working at Microsoft. I don't know if you built it on the job at Microsoft and then open sourced it. Whatever it was before Microsoft, yeah, oh, is that why Microsoft hired you? No, they, they actually hired me because I built a form library in Redux and then I gave up on that form library. So, yeah, gosh, wow, I didn't know that. Okay, so you built XState, it, it has proven value time and time again. And you, you join Microsoft, and after a while, you decided I'm going to leave Microsoft. And and productize state XState, by adding the this layer of a visualizer. And so can you, in, in, in, in as many words as you like, talk about, introduce Stately, maybe the journey there, the product offering, and where it's going tomorrow. Sure. So, in short, I just wanted to work on XState full-time.

It was the middle of the pandemic and I was really just dying to do it, you know, there were more and more companies depending on XState. And, you know, I. I just realized that I needed a lot more resources. And basically it was just me and Matou on the project, working on it. Nights and weekends I even had to wake up early. And, you know, just basically, like, like we talked about briefly before, open source is sort of a almost a think lless job. You know, you're, you're doing a lot of things for free and it's not really sustainable unless you have some corporate backing. Or, you know, a huge amount of just contributions and like, you know, support from other people. So yeah, this was my opportunity to sort of just go the VC funded route and actually turn this into a product. And so the main idea of it was we were basically going to take the idea of XState, which is this visual modeling of application logic.

And make it, just make it accessible to a lot more people, and we did this by the use of visual. Diagramming tools such as the we had state Le Vis and then that turned into the Stately editor and a way for teams and individual developers to create modify version and share their machines but also just have an easy way to basically use that as living documentation that transforms directly into code or the other way around if you wanted to so we once bring basically diagramming and documentation to the next level and so that's what we you know we did and we're still working on at stat. a fantastic I'm curious if there was ever I see a big Trend by the way of companies starting because open source not sustainable companies like cal.com companies like Crab Nebula comp which is like Tower which is an open source project and they're like this doesn't pay the bills and you start a company and of course build a product I have Chad from Sentry on the podcast he's their head of open source and they they're doing some fun stuff around making open source sustainable but I'm curious if youall considered for a moment the Consulting route as well like have a product but also cons because I see this trend a lot I think of Crab Nebula great example they have like Crab Nebula Cloud which is like distributed application distribution globally because a lot of folks are just Distributing binaries with GitHub releases which isn't really edge CDN powered and so they're just adding a CDN to that among other powerful features as a product but on the way to shipping the product was like we're just going to do Consulting contracts because we are like we built this open source thing and it's in use at Enterprises so it made sense did you is that something yall pursued in the early days in the early days yes for sure but you will typically hear you know common advice that Consulting it's sort of I mean obviously people make livings off of Consulting and you know being Consultants but in terms of a startup it doesn't scale so it's something that you should actually tend to avoid because it's like you're spending an hour of your time to help or a couple hours to help one person one company when in said you could spend that one hour doing things that scale out and help multiple companies, or like marketing efforts and things like that.

So, yeah, we started down that route and I don't have too much time to do it. But with that said, we do have, you know, we, we do. Consulting at St.. Awesome, so it's it's this product, and Consulting. And the product is a visual complement to XState. Where you can really intensively model statecharts, not state machine. So I, as I understand, you have child states, you have all these other, powerful primitives, and then you export to JSON that you can then pick up in your application and just fill in, like application logic. The state machine's built for you, and I appreciate that. You also said about state Le. a the product that it can take code AS input as well to a diagram, so it's a really cool product. I've used it myself, I'm a huge fan. You, you, you founded this. It's your first time founding a company, as far as I know. It's also your first time being the CEO. I. I posted something controversial on LinkedIn where I said, you know what?

Maybe we should just call firsttime CEOs junior CEOs, and I didn't say that disparagingly, I just said it. It would set the expectation that this person's their this their first time doing it, and they need support from the team. As opposed to what I've seen is with the first time CEOs, team members show up with, like, unrealistic expectations. Like, what do you mean? You don't have all the answers? You're the CEO and you're like, no, but I did. I'm. This is my first time, so my thesis was, if you add junior to the title, it'll help people be a bit more compassionate, understanding. Regardless of that post, I'm curious if you could speak a bit to your experience as a first-time CEO? Maybe the challenges, but I'm more interested in, like the. The Salient important features, like what is really important for a firsttime CEO to know and care about? And maybe what is really most important in a recurring Salient way.

For even experience experienced, excuse me, because. You've mentioned three years experienced CEOs to care about and have sort of at the Forefront of their mind. I mean, I'm, I'm still learning, and I really like your framing of, the junior CEO, because I definitely do consider like, I'm. I'm a first-time founder, like, I'm not going to pretend to be something I'm not. I'm still learning along the way. And that's why I'm also going to say, sort of a. I don't know if it's controversial or not, but like a like. An important thing for, you know, Founders and you know, firsttime CEOs to do is to make mistakes. I've made plenty, and the trick, though, is to realize the mistakes you're making. Because I think that when you become second time, third time founder, or you become a CEO at another company. It's not like you write up all these books. Or you went to school for this and you're like, Hey, I know how to be a CEO.

Now, your knowledge is the collection of all the mistakes that you've made. And so, you know, like, Hey, we're going to do this. Because when I did it the other way, that failed horribly, so we're not going to do it that way. So I. I think it's important to just realize the mistakes you're making and sort of learn from them. And I mean, I've definitely made plenty. Like there's been times where we've been stuck in this whole like, Hey, I think these features will be really cool.

Play from 1:17:00

People are asking for this, this and that, so we're going to build all these. And also people are like, Oh, this would be really great if it were free, so it's like, yeah, sure, let's make a bunch of things free. And then you realize that your free users are not really the like they're never going to, or almost never going to pay. Like, that's not your target audience, so you want to build free features if you know, if you want to, just to get people in the door. And then you really want to focus on the people who say, I have a real use case and we want to pay you money. Those are the people you should be focusing on. That's so interesting. Yeah, I've seen this trap, that a. Lot of Founders fall into. I feel like this is especially hard for you as an open- source author and maintainer, because all you're used to is free people. Free users.

Going like, I want more of this and more of that, right? And so it's a different beast when you're when you're, running a business, but then how do you find those people? The people who say, Hey, I want this and I want to pay money for it. Well, you, I mean, you start charging you, you put things behind pay walls and you. I. I don't want to be that person who says, hey, you know, that thing that used to be free while we're making it paid. I, I really do firmly believe that if you offer something for free, just keep it for free. But any new things or things that will actually have value to people who might want to pay? Definitely put it behind the pay wall because your time is valuable. The development effort. There's a huge cost to that, and so you do want to, you know, just have people pay for it like your product is worth something.

So, yeah, yeah, and so that's what we do, you know, we. We have things where it's like, Hey, if you want to use this advanced feature, something pops up. It talks about the advantages and it talks about going pro, like we call it Stately Pro. And so it encourages people to say, hey, there is the option to pay if you want to support and you want to, use these more advanced features. I heard I, I, I. I had a discussion on this podcast with another founder. And and I'm, I'm totally blanking here, which is which is really bad of me, because I should ideally remember every conversation I have. But like, there was this one founder who mentioned, oh yes, it wasn't even a founder. It was Jeff Escalante, director of engineering at Clerk, absolute genius, in terms of engineering leadership. And he said this really powerful thing.

And I brought up Stately also, by the way, because, we were talking about Road mapping, yeah, engineering, Road mapping, and, you know, y all use canny. That came to mind in my. Discussion with Jeff by the way, that episode's probably out, go have a look. I'm not telling you, I'm telling the listeners to be clear. But. But Jeff used, he found this product called product Lane. And it's basically canny, but deeply integrated with linear, so you don't have to do anything like you're linear. Issues that you want exposed are exposed, people can up about them, comment on them. ETC. And it's this beautiful two-way data binding with. It's like a public interface to linear, really cool, um. And then the priority is determined by your community or your customer base. And so Jeff saw this product, and he was like, Yo, I, I love this product. And what he did was he reached out to them and and said, listen, I.

This is valuable for us. We. We are tempted to use your free tier. We realize you don't have pricing figured out. Cu, it's too early, but, we want to pay you, so, give us a price. In fact, put us. You don't have an Enterprise tier. But like, invent one, cuz we want to be on it, and we'll walk you through the process of inventing one. Because he's done this at Versel, as far as I know. And he talked about the value of really, as a company, doing that to other companies. Because then you invest in, like the long-term relationship. As opposed to, I'm just going to mooch off of this free tier. So, I love what you said, I love that you said, you know, put a pay wall behind it and the right users will come. I think there's maybe a mandate here for companies in a position to be paying customers to do so.

I've only unfortunately, been a part of startups that went like, is there a free tier?

Play from 1:26:00

No, we're not using it. But I think there's something inspiring there. Cool, David, I want to wrap up with. I want to talk to you about what's next for Stately. You mentioned stat... Agent or agents? Agents, correct me, agents. Okay, is that what's next? What else is coming? Yeah, so, of course we have the AI s with St diet AI. That's something I'm extremely excited about, because. Like we talked about for half, the podcast opens up a whole new world on, you know, thinking about the future of AI applications. The next big thing that we're planning on releasing is, uh. We are updating the VSS code extension, which has been used, heavily by, you know, of course, Exed V4 users. But it does need to be brought up to date. And honestly, this is like the core of our product, which is the magic of your coding. And you see the diagram updated in real time, it's like live living documentation. But you could also, it's sort of like a magic trick, you go the other way around, you could edit the diagram and the code updates.

So, you know, we're just sort of working on that magic between those two. It's an extremely difficult problem to solve and we've been working for years on it, but hopefully we could have something out, eventually for that, um. But other than that, we're just going to keep improving the tooling, and we're also hoping to make Stately. Basically, the way that anyone, no matter which libraries, Frameworks, or even programming languages you're using, you can make use of these tools. Either at a simple level of diagramming state machines for your application, or just visualizing the logic, regardless of if you're using XState or not. We want to provide tools for more and more companies to, you know, to visually model their software log or their application logic. So we're just going to keep working on that, that's, that's, that's so cool, I can't wait to play with all of it. Listen, David, it's been, as always, an absolute pleasure, to talk to you all.

Whether it's over coffee at 6:00 a...m.. in some City that I can't remember. Or on the podcast when you, ship that two-way data binding and magic. I think it we should maybe do this again. I would love to talk about the internal details of how that works, because I imagine there's there's walking the syntax tree and making connections between, object literals and SVG elements or something like that. I don't know, but this sounds really interesting. Regardless. Thank you for getting up at 6 o'clock in the morning and despite your hunger. And, thirst for coming on the podcast and sharing all of these insights. All the way from why Exate exists to its application in neural Nets and Marov chains, through to Stately, and today, and what's next? I, on behalf of me and all the listeners, it's, it's an absolute blessing. Thank you, thank you, thank you so much for having me on.

It's always great to talk to you. Thank you for joining my discussion with David Kused. I hope you learned a lot about state machines, state management, when to manage, state XState, Stately agent, and more. I certainly learned a number of things, for example, the distinction between statecharts and state machines. I genuinely didn't know that because I didn't have much overlap in my day job. And that's kind of the point of this podcast. You get exposed to things you maybe don't get, exposed to at work here on the podcast. And that deepens your understanding and removes your imposter syndrome, all while celebrating the beauty of engineering. If you're learning from and or enjoying this content on YouTube, then if you subscribe to the channel and maybe like it, that'd be super helpful if you're listening on Apple or Spotify. If you could leave up to a star review, that would be helpful.

It's just all of this doesn't cost you much, and it does benefit the channel more than you know. So any of that would be appreciated. If you learn something, if you want to share a clip or so on social media, I will not stop you. Thank you for being a part of this podcast, thank you for being a part of the discussion, and, most importantly, thank you for your interest in engineering.

Play from 1:30:00