Ben: Hey everyone, and welcome to PodRocket. Today I'm here with David Khourshid the creator of XState and Stately. How are you, David? David: I'm doing good. How are you? Ben: I'm also good. So real excited to learn about these projects. We can kind of start with either I'm guessing maybe it makes sense to start with XState first, since as I understand it, that's kind of foundational in a sense to stately. So does, does that make sense? We could start there. And so maybe for, for the audience who aren't familiar with XState, what does it do, how does it work? David: Sure. So XState is a library for creating and using state machines and statecharts. It's completely framework agnostic, and it was initially written and in JavaScript rewritten in TypeScript. And so there, there's sort of a distinction because I know when people think states they think state management and so XState, isn't just a state management library. It's more for state orchestration. And so the difference is that state management is like having a nice little container to hold and maybe react to state changes and state orchestration is more about changing the behavior and just orchestrating when which behavior gets applied based on which events, you know, come in and of course events can change the behavior as well. So it's a little bit more than, than just state management. Ben: Got it. So maybe just to make things a bit more tangible, like what's an example or maybe a question is like often state management frameworks are demonstrated with like the to-do list app. So could you put XState in context of how it might frame up the, the classic to-do list state demo? David: Well sure, let's you know, if we take a to-do list app, as an example with state management you would just be concerned with alright, I need a place to store my to-dos, adds, deletes, edits, all of that. And the other logic, like, okay, we'll just let the developer figure it out, with applying state machines and state orchestration to that. Now you also have to think about like, okay, there's a certain number of states that my to-do could be in. So for example, I could be editing it, I could be reading it. I could, it could be deleted, it could be completed. And so if we have a to-do that it's deleted, it probably shouldn't be editable. And so like also, you know, if it's completed things like that. And, and so right now, like the way that developers would typically do this is they'd have some sort of bullion guard or condition that says, all right if I am, you know, if this is completed, like it is completed, then you know, just don't do anything when the user tries to edit and just like a ton of defensive logic. David: And so a state orchestration library, like XState puts that state first and says, when you're in the editing states, these are the things you're allowed to do. And when you're in the completed, here's what you can do. So yeah, that's pretty much the distinction and hopefully that made sense as an example. Ben: Got it. So in a sense it's, it's like more opinionated about how you handle each possible state than something like Redux or MobX, which is more of just like a generic place to store state and it's kind of up to the developer, how you architect state in, in the context of like a JSON object, but with XState there's, sounds like it's more opinionated and gives you a more, more of a framework for how you describe what you can and can't do in each state and how you get into various states. Is that accurate? David: Yeah and jokingly, I like to call like Redux with rules feels like not, not boiler plate, but just like rules. Like you're more constrained in the behaviors of your application depending on, you know, what state you're in Ben: And how does it work as like, as a developer, how do I use it? What's the API like? David: So if I were to describe it with words, you have a peer function. So if you're used to using reducers like in Redux and GRX or UX, you give it the current state and the event and it returns the next states. With XState It's the same way. So you have a machine, when you create a machine dot transition function where you give it the current states, an event that happens and it will give you the next state. And then there's something called an interpreter, which basically makes it like an event emitter that you could subscribe to. So you could take that machine and now it becomes a living entity and that entity you could send events to. David: And it's going to hold that state in there. In Redux you have a single store that is that living entity. So you could send it to fence and it holds that state internally and you could also subscribe to it. With XState It's pretty much the same way. The biggest difference is that, you know, now, since it's, you know, state first, we could visualize our application logic and we could write more robust application logic than just a, a free for all reducer function. Ben: And when you say visualize, is that visualizing code or actually visualize in some sort of graphical visualization. David: The second, basically we were making directed graphs out of the logic represented in a state machine, or you could think of it like boxes and arrows, more colloquially. So you could visualize alright, we have this state and when this event happens, now we're going to go in this state and it might also run some actions or effects, you know, depending on what events came through. So yeah, it's definitely visual in like a higher level of abstraction than the actual code. Ben: Got it. What are actors? David: So actors, I remember when I was talking about like how we could interpret a machine and it becomes like this entity that you could send events to and subscribe to just like a Redux store when it's used in an application. So that's considered an actor and this comes from the actor model of computation, which, you know, was made many, many decades ago, I think, 1973 or something like that. And so XState treats actors as first class citizens. So when you interpret the machine that creates an actor. And so it creates something that you could send and listen to. And so that actor can also create other actors through like spawning or interpreting. And each of these actors represents like a local isolated state that could listen to events and change its behavior based on which events came in. David: And so, you know, there's many ways that you could think of this in a real life application too. So if you're like, if you think about a component, a component can be itself, an actor or a, you know, a handler for an event like that could be an actor as well. So it's just basically this thing that you could communicate with. Yeah and so with XState there's, you could have many actors that talk to each other. Ben: And maybe going back to the context of like our to do app, how would the actor paradigm fit into that app? Like, or maybe not the core app, but some additional functionality we might add on top of our to do app. David: So let's convert the two apps to like sort of a real life example of like, let's say your workplace where you have a boss or a manager, and then you have workers. So a to do list could be like that manager and each to do can be like one of those, you know, employees or workers. And so in the actor model, instead of all that being like one big data structure, instead it's like many little pieces of isolated states. So you could have one to do report to the manager, Hey, I'm completed. Or I just changed or I was deleted or something like that. And then the parents can handle that from there and say, okay, well let me just remove you from the list or something like that. Or the parents, like let's say it was given the command, like mark all as completed. So the parent receives that events and then it tells all of the other to dos, Hey, you all are completed. David: I think I said, completed or deleted, but yeah, you, you all are deleted in. So it, it would send in events to each, each one of those. And so from there we have like a really good separation of responsibilities because now it becomes trivial to do something like, let's say you take your to do NBC app that everyone loves to implement and re-implement in different frameworks and libraries. And let's say that we want these to dos to actually sync to a database. And you want a sync to dos where saving might fail or, you know, persistence is an issue too. Like, let's say you want to persist it to local storage, but also some remotes API or fetch them from an API too. So now the structure of like to do and to dos says, as actors does not change at all a to do is still a to do. It just has now this extra functionality of like being able to communicate a sync, but to the parents, the parent doesn't know that all the parent cares about is this to do is going to send me events and I'm going to send events to the to do so that interface is still exactly the same, no matter how many features are added to each of those actors. Ben: Overall, how does XState compare to some of the other kind of state tools, state machine based tools like Robot is one that I've seen before. Yeah, curious how that differs or is similar. David: Yeah so it's interesting cause there's, you know, there's obviously a lot more state management libraries than there are state machine libraries, but there are still quite a few state machine libraries. Matthew, I think he's Matthew Phillips. He is the creator of Robots, which is a really cool library. And I think one of the focuses of the library was to just give it a nicer API and make it a little bit more composable. It doesn't have all the features of the state chart, which is why XState is the way it is, is because it has to adhere to this SCXML interface which has a whole lot of features and, you know, makes it compatible with a lot of other tooling. But Matthew who created robot, he also created this DSL called Lucy. And I think it's at lucylang.org something like that. But what it is, it's a, a meta language for describing state machines that is written in C actually. And it compiles down to just JavaScript code and it actually compiles to XState. So yeah, he's, he's definitely a, a fan or at least I hope so of, of XState and yeah, there, there are some older state machine libraries too, but I, I don't think that they're updated, you know, or up to date. Ben: And originally what, what led you to, to build this and you know, what, what got you so excited about state machines in the first place? David: Yeah. So state or state machines, XState is about six years old. It was almost exactly six years ago when I released it. And originally when I was a junior developer, so about 10 years ago, I had to suffer through just like a, a massive PHP application, which was representing just complex workflows, like user facing workflows of this, you know, prescription drugs. And these, these are really expensive specialty medications. So you would have to pick your insurance and then pick the right dosage. And then another field would show based on the dosage that you picked. And then you had to like fill out this prior authorization form and then your address. And so it was just form after form after form. So that sort of nightmare wizard form scenario without any frameworks or I, I think we used jQuery mostly, but yeah. So coding it and coding all of that logic was just as a junior developer. David: It's like through throwing, you know, just being thrown into the deep end. So I was like, there's got to be a better way to do this. And so that's when I started like just researching like, okay, what's a way to make like these workflows. And so obviously you search workflows, you're going to eventually stumble onto state machines. So I started researching state machines. I'm like, okay, this is a visual paradigm. This is actually pretty cool because I'm a junior, I don't know too much, but I can definitely follow boxes and arrows. And like that makes a lot of sense to me. And then I started reading that there's this thing called state charts, which really takes state machines to the next level, allows you to represent hierarchy and parallel states and a whole bunch of other features. And so I just started researching that and decided to make a library out of it. And honestly it was meant to be a toy library used for a conference demo, but it sort of grew to much bigger than that. Ben: And as I understand it now you're building Stately AI on top of, on top of XState. So maybe tell me a bit more about that. David: Yeah. So Stately AI, it's a company startup that I founded and our goal really, it's not exactly XState focused at first. It is going to be, we're going to be building tooling for XState and Stately. Like most of the tools are built on top of XState, but the main purpose of it is to have, and provide software modeling tools for developers, designers, project managers, other stakeholders, and essentially be like the set of tools that you would use to represent your application logic in a visual way, just like you would use and any other diagramming tool. But the biggest difference is that this diagramming tool lives with your code. And so it's always going to be in sync with your code. And so these are called executable diagrams and state charts are one of the ways that, you know, you can make these executable diagrams. And so basically we just want also to be a place where developers can share their application logic and collaborate on it, just like you could collaborate on designs in Figma. So I guess you could say, we want to be the Figma of application logic. Ben: So would you kind of describe the logic of your application in, in the visual interface and then does it generate code or it, you hook into that logic of APIs to build your application on top of how what's like the interface between the visual and your actual application? David: So the, the two paths we're exploring are like, if you're creating it in the diagram, it could of course generate code. And of course you could edit that code too. And, or like in, in intermediary JSON representation. So it could be consumed by other tools as well, but we also want to make it so that if you are coding in something like XState, you should be able to visualize that and visually edit it in the editor. So that's something that, you know, we definitely wants to have as, as a feature. Ben: Does that kind of functionality exist at all in like the no code, low code app builders, or I'm curious, like kind of what else is out that has maybe explored this concept of visually describing kind of the control flow within your application? David: Yeah. So a lot of the no code and low code tools are focused. Well, like there's a category where it's focused primarily on the visuals. There's a lot of visual reacts builders and website builders, and that is pretty much static. Of course you could add like dynamic elements and just pull those in, but it's still very much a, you know, a, a limited subset of what you can do. And so usually what tends to happen is that once you get to a point where you need to express complex application logic, or just something custom that the low code don't provide out of the box, then you pretty much have to jump into code. And also these tools, they typically generate code where it's like, here's a code, do not touch it. Otherwise it's not going to work and we're just going to blow it all away when you, when you use the tool again. David: So I, I think, yeah, there there's been on tools that sort of explore this place, this space, but I don't think that there's been any that really show like what you can do with like expressing full on application logic. And so that's why like XState was sort of the, the second half of the approach where it's like, can developers express complex application logic using just XState. And so the answer is yes, and right now the answer is increasingly like we would move to XState if we need to describe anything complex. And maybe for trivial things, we won't use XState yet, but you know, once that hypothesis is proved, now the question is like, all right, can a low code editor actually create those XState machines? And then you have the full picture of this low code editor being able to, you know, just fully represent as complex of application logic as you want. Ben: And what is Stately Viz? David: So the Viz, Stately Viz is an updated version of the XState visualizer. And it allows you to visualize machines by copying and pasting the XState code inside the, the code editor in there. And you could also visually inspect machines too. So if you're using XState in your application, you could hook it up to the Stately Viz and see the state machine changing as you navigate through your application. And what's cool too, is that it works both ways. So if you manipulate something on the state machine, it's going to reflect back in the application as well. Ben: Got it. So none of that, none of that code that's generated and you can't touch it, sounds like it can go both ways. David: Exactly. Ben: It can generate code or you can edit the code and see the updates in the visual interface. David: Exactly. Ben: And what does the future look like for Stately AI? Like where, where do you want take this in a year? What do, what do you, you know, what do you think about building? David: So right now we're working on the editor, and you know, we're going to be opening up to, you know, for beta, like in a couple months and hopefully general, general release next year, but that's, that's only the first step in the process because like, we want this editor to be useful for a wide variety of things. Like I said earlier, not just XState, but we want developers, designers, and others to be able to represent any type of user flow or workflow in this tool and have it interact with a, a wide variety of tools. Like for example, GitHub actions I think it'd be really cool to just jump into the editor, be like, all right, let me just drag and drop these things to create my GitHub action or visualize in the existing GitHub action and yeah, just export it and use it or even see it working live. That'd be really cool too. So yeah, lots of ideas. Ben: So if folks are interested in learning more or potentially even getting involved on an open source basis, what's the, the best way to approach either XState or Stately. David: So we have a, a pretty, pretty good size community on Discord right now. If you go discord.gg/xstate, we have a whole bunch of interesting discussions every day. And it's also the quickest way to find help. If you have any problems with state modeling or, or XStates, you know, there's always someone who's going to, you know, answer you quickly. We also have GitHub discussions. So if you go to stately, github.com/statelyai/xstate, lots of interesting discussions there too, and also our Twitter @statelyai, that's a, that's a good place as well. If you want to learn more about state charts in general, I recommend this, this is a resource by Erik Mogensen called statecharts.dev. And it includes a lot of not even using code, but just, you know, representing state charts in a visual way and why you would use state charts and just all of the fundamentals, like the different terms and things like that. Ben: Great. Well, David, this has been awesome to learn about both XState and Stately thanks so much for joining us. David: Today. Yeah. Thank you for having me. Brian: Thanks for listening to pod rocket. Find us at pod rocket pod on Twitter, or you could always email me even though that's not a popular option. It's Brian at log rocket.