Stately with David Khourshid

Episode Description

David Khourshid discusses XState, state machines for UI logic, the Stately visual editor, and how state machines simplify complex app workflows on both client and server.

Episode Summary

David Khourshid, creator of XState and founder of Stately, joins the show to discuss how state machines and state charts can tame complex application logic. He explains that XState is a framework-agnostic JavaScript/TypeScript library born from the challenge of managing intricate UI flows like multi-step forms and event-driven interfaces. The conversation highlights a real-world example where a donation form's submit button allowed duplicate payments—a bug that state machines naturally prevent by ensuring the app can only be in one state at a time. David describes the Stately visual editor, which allows developers to create state machines through drag-and-drop and export them as usable code, supporting a bidirectional workflow between visual diagrams and written code. The discussion extends to server-side use cases, where state machines model back-end workflows like payment processing and onboarding flows, drawing parallels to AWS Step Functions. David notes that state machines don't introduce complexity but rather reveal it, forcing developers to handle edge cases upfront. He touches on the Zag project's framework-agnostic component logic, the VS Code extension for inline editing and simulation, and the early-adopter stage of state machines in web development despite their 50-plus-year history in fields like automotive and aeronautics. The episode closes with a look at Stately's roadmap for collaboration features and growing back-end adoption.

Chapters

00:00:00 - Introduction and XState Origins

Anthony Campolo introduces David Khourshid as the creator of XState and founder of Stately, a company built around state machines for application development. David shares that he is the sole founder and that XState began over six years ago as an open-source project originally called Estado. He explains that the library is framework-agnostic, working with React, Vue, Angular, Solid, or no framework at all.

David outlines the core problem XState addresses: managing complex application logic such as multi-step forms with conditional flows and heavily event-driven interfaces. He emphasizes that state machines serve as a visual formalism that not only helps developers reason about logic but also makes that logic understandable to non-technical team members, which became the founding premise of Stately as a platform for visual modeling and collaboration.

00:03:13 - The Visual Editor and Bidirectional Code

Christopher Burns shares his experience learning XState through a Frontend Masters course and notes how the Stately visual editor has lowered the barrier to entry. David explains that the editor was built because code is fundamentally one-dimensional and poorly suited for describing graph-like structures where states point in many directions. The visual medium makes it far easier to see and create those connections.

Anthony asks whether the visual editor can generate code from a diagram, and David confirms the bidirectional workflow: developers can drag and drop states and transitions in the Stately editor, export the result as JSON for use in XState's machine creator function, or edit code and see the visualization update automatically. He notes that building a scaffolding visually is significantly faster and less error-prone than typing it out, and the team is focused on bringing full XState feature parity into the editor.

00:07:19 - Real-World Bugs and Revealing Complexity

Christopher describes how XState simplified a complex onboarding flow in his application and recounts a critical bug where users could trigger duplicate payments on a donation form because a simple disabled-button approach failed to prevent multiple submissions. David expands on this with his article arguing that disabling a button is UI logic masquerading as business logic, and that a state machine naturally enforces the rule that submission can only happen once.

The conversation turns to how state machines don't add complexity but instead surface it, forcing developers to handle edge cases upfront. David compares this to how TypeScript forces developers to deal with types early. Anthony draws a parallel to entity-relationship diagrams for databases, noting that the apparent complexity in a state machine visualization simply reflects the real complexity of the application, and David adds that maintenance becomes easier because adding features is just adding states and transitions to an explicit, visualizable structure.

00:13:25 - Collaboration, Testing, and the VS Code Extension

Anthony asks about collaboration features, and David explains that developers already share XState visualizations with designers and project managers via screenshots or links, providing a common language that code alone cannot offer. He outlines future plans for commenting, collaborative editing, and GitHub integration within the Stately platform.

Christopher raises the topic of mocking and testing state machines, and David describes how XState separates specification from implementation, making it straightforward to swap in mock actions, guards, and services. The discussion moves to the VS Code extension, which embeds the Stately editor in a side panel, allowing developers to visualize and edit machines alongside their code. David acknowledges the extension is experimental but highlights its power: editing the diagram on the right updates the code on the left in real time.

00:20:45 - State Machines on the Server

Christopher introduces server-side state machines, referencing Erik Rasmussen's Remix Conference talk on JavaScript-less multi-step form processing. David explains that server-side workflows—sequential or branching series of async steps like image processing or payment flows—map naturally to state machines. He illustrates how each await statement in a typical async chain becomes a state, with transitions handling success, failure, and alternate paths like fallback payment providers.

Anthony brings up AWS Step Functions, and David acknowledges the strong parallels, noting that AWS States Language resembles XState's JSON structure but lacks the power of state charts. David sees an opportunity to build a more powerful, framework-agnostic alternative. Christopher then walks through an onboarding example where the server enforces step ordering, and David emphasizes that developers building ad hoc solutions with arrays or linked lists are simply creating implicit, less reliable state machines.

00:27:18 - Components, Adoption, and the Future

Christopher asks whether XState can replace useState at the component level, and David points to the Zag project, which drives framework-agnostic component logic with its own state machine library that is already compatible with the XState visualizer. This approach allows a single logic definition to power React, Vue, Solid, and Svelte adapters with consistent accessibility behavior.

David reflects on the maturity of the ecosystem, estimating that web development is still in an early-adopter phase for state machines despite their 50-year history in fields like embedded electronics, automotive, aeronautics, and game development. He notes that the mathematical definition of a state machine is stable and that different libraries are simply API layers on top of the same fundamentals. The chapter closes with David sharing that adoption is growing on both the front end and back end, encouraging listeners to explore Stately and join the community Discord.

Transcript

00:00:00 - David Khourshid

Yeah. Sounds good.

00:00:13 - Christopher Burns

David Khourshid, welcome to the show. You're the state machine wizard, as many would probably refer to you. You're someone who has gone out and explained it and created libraries around it, including XState. I know you've already done the state machine 101 many, many times, but the way I always hear it described is like a traffic light. It can be in different states: green means go, red means stop, yellow means slow down. You always go from one to the other in a predictable pattern. But you really said we could take this idea and use it for our UIs to simplify them.

Now you've actually built a company called Stately, which has to do with state machines and how you integrate them into your software. So there'll be a lot to get into here, and we're very excited and honored to have you here.

00:00:59 - David Khourshid

Thank you. Really excited to be here.

00:01:01 - Anthony Campolo

Do you want to give a little bit of background on the company and how it was formed, and who were some of the other co-founders?

00:01:07 - David Khourshid

Sure. So first of all, I'm the sole founder. No co-founders. But this really stems from an open source project that I started a little over six years ago called XState. It was actually called Estado back then, but then I changed the name because having an X in your state management library name is cool, for whatever reason, so I decided to roll with it.

XState is a library, like you mentioned, for state machines and state charts in JavaScript and TypeScript. It's not meant for any specific framework, which is why you could use it in React, Vue, Angular, or even without any framework at all. In fact, there's an open PR for Solid, which is pretty exciting.

One of the original problems I set out to solve was the problem of managing complex application logic. This can be manifested in many different forms. If you have multi-step forms where things have to conditionally show based on other things, or the order of the steps may change depending on what the user has put in, then that would be an example of complex app logic.

[00:02:05] That's pretty difficult to reason about without having some sort of declarative structure, like a state machine, to make sense of what should happen next when the user does something. There are many examples of complex UIs where they are very heavily event-driven. Depending on what events occur, you could perform different actions or do things like that.

I found early on that state machines as a visual formalism were a really, really great way of representing complex application logic in a way that could also be understood by the rest of the team as well, not just developers. I started Stately on that premise of building a platform of visual tools for helping developers both model their application logic visually and collaborate with the rest of their team, share that application logic, and manage it. They can even see what happens when the logic changes and communicate that without things like documentation, tests, or diagrams going out of sync from the actual code. So we have a lot of big plans, and we're a small team of ten, so we're excited to make those plans happen.

00:03:13 - Christopher Burns

This is a very cool project, library, and company. I have been using state libraries now for about 12 months. I actually learned how to use state machines from your Frontend Masters course because, for me, I found it hard to get my head around it by just looking at documentation.

But then when I watched your videos, you had examples of how you needed to make them work. That made it click for me. This is a subject that I think, obviously, your company is working on to make easier, but when I started, you had to build the models yourself. Now Stately has a diagram builder, so I think the complexities of XState are just getting easier and easier to overcome, to where the benefits start becoming easier and easier to gain, if that makes sense.

00:04:08 - David Khourshid

Yeah, it absolutely makes sense. One of the biggest reasons we built that visual editor is, like you said, for it to be a lot easier to not only visualize these state machines, but also to create them as well. I know that many people have actually said that the API could be a bit object-like and a little bit confusing to author, and this is due to a lot of reasons.

First of all, we want the API to be visualizable, and so having some sort of declarative JSON structure really helps with that. Second, code is just not a good medium for describing graphs. Graphs, of course, can point in many different directions. They're essentially 2D or even 3D, and I like to think of code as pretty much one-dimensional. You're reading it from top down. Of course, you're reading it from left to right, but overall it's just a single direction. When you have something that needs to point to something else, you're trying to keep all of those connections in your head.

[00:05:00] Honestly, a visual medium is much better for that. So I completely understand the frustration with trying to create state machines in code, and that's why we're moving towards more of this visual programming aspect. Not low-code or no-code, but more like visually augmented code.

00:05:16 - Anthony Campolo

I actually learned state machines and XState from working on Everfund. Funny enough, it was about a year ago. As you say, you had integrated it. I was working on it for this project that we had done. We haven't really talked about it much on the podcast, but there's a login flow that had a whole bunch of different stuff in it.

I looked at it after. It was like reading it and brute-forcing my brain to understand the different pieces. I kind of reverse-engineered what was actually happening because the variables are named pretty well. So it was like, all right, this means this, this means that, so this goes this, this goes that. I agree that having just a visual tool to look at that in a diagram would have been awesome. I'm curious, though: are you able to reverse that, so create the diagram first and then have it generate the code?

00:06:00 - David Khourshid

Yes, absolutely. This is now possible with the Stately visual editor. So if you go to the Stately editor, it's basically a drag-and-drop tool. You could double-click to create a state and drag edges around. What this allows you to do is create a diagram where you could export it as that JSON structure that we were talking about and use that JSON structure directly in createMachine, which is a machine creator function that's provided by XState, and actually run that as code within your application.

Right now we're working on just bringing more XState features into the editor, so that whatever you could do with code, you should be able to do in the visual editor. So you could get like 70% or 90% there just in the visual editor. Again, I know it's a little bit of a paradigm shift for developers who are mostly living in code, but trust me when I say, if you played around with this, you'd know it is so much faster to create at least a scaffolding of a state machine visually than typing it out.

[00:06:59] It's less error-prone. If you want to create states, it's just double-click and type and drag to create lines. And that's pretty much all you need to do. But yes, we are very focused on that bidirectional approach. You could edit code and have the machine visualized, or edit the machine visually and have the code updated to reflect that. That's one of our biggest goals.

00:07:19 - Christopher Burns

Building on what Andy was saying and what you said earlier about complicated state, this is what Andy was talking about. Elephant is obviously what I build, and this state has only gotten more complicated as time has gone on, but has remained simplified by using XState. As you said before, it seems counterintuitive that the more state there is, meaning the bigger the state, the more complicated it looks, but actually it reverses it. It makes it easier because there are so many logic gates in this onboarding process, API calls that need to return error states for the API calls. What happens if they then want to go back four screens and then send another API request?

Trying to do all this with just hooks like useState and useEffect, you get yourself into a muddle really, really fast. One of my biggest reasons why I actually adopted XState was on our donation systems. This seems like such a trivial reason to implement XState, but actually it was a blessing in disguise because it made everything so much easier.

[00:08:24] We had one of these multi-step forms, and on the submit button it would submit a payment. The payment would move money from one account to the other, and you would say, okay, I would put a useState, say, as soon as this onClick is fired, disable this button. Easy peasy, right? We did that, and then we started noticing bugs where people would do two payments, three payments, and we would be saying, how is this happening? This basically wasn't the state providing proper functionality to the API. And when we implemented XState, because the state can only be in a certain place, it actually stopped all of those regressive bugs from happening.

I've probably described that terribly, but basically users mash every button, and XState is great for stopping them from mashing every button and repeating the requests, for example.

00:09:14 - David Khourshid

That's a really great example. Actually, I wrote an article a while ago titled, "No, disabling a button is not app logic," or I think something like that. It talks about that same problem where it's like, all right, if you have a business logic rule where something could only be submitted once, and obviously you don't want a user to submit it multiple times, developers by and large, their number one solution to this is, you know what, let's just disable the button. That way they can't submit more than one time.

But that's moving that business logic over to UI logic where it really doesn't belong. It's sort of like just putting up a simple barrier in order to not let people in, instead of locking the door or having other safeguards in place to make sure people don't get in. It's possible to submit a form by pressing enter or by doing something else. You could easily work around that submit button.

[00:10:10] Plus, there are many forms where the developer just plain forgets to disable that button. I'm guilty of being one of those users who smashes the button multiple times. I'll tell you why we do this. It's because we get so frustrated when we don't know that something is loading or we really want something to happen. So we're like, let's make sure, and just click this three or four times. But the actual logic that you want is, hey, when I've submitted this, then submitting should no longer have any effect. The most natural way to represent that is with a state machine, where you could only submit when you haven't submitted yet, which sounds obvious in retrospect.

00:10:49 - Christopher Burns

Very much so. When you look at it like this, the state overcomplicates everything. Like, now you've got this whole massive state machine to worry about. But in essence, it's simplifying everything because all logic gates are now in this massive graph. My use of useState has significantly reduced with more and more state machines I've used throughout my application. I think inherently it's made my application more stable. I say "stable" with air quotes because they're not just going to keep on mashing buttons and trying to get it to move states forward.

00:11:23 - David Khourshid

Right, exactly. There's many ways to verify that as well. With a state machine, you could also generate tests and ensure that that won't happen. You basically have this self-contained model of what your application logic is going to be like, so that you can know all of the possible states and transitions, and there are no surprises.

That's another point I want to bring up, too. Sometimes when people make state machines and state charts, especially if they use XState, they might think, hey, it looks a little bit more complicated than the code that I would normally write. But the fact of the matter is that state machines and state charts don't introduce complexity. They reveal it, and they force you to deal with that complexity up front, in much the same way that TypeScript forces you to deal with static types up front.

00:12:09 - Anthony Campolo

Yeah, I would compare it to those entity relationship diagrams for database models and how your relationships work. It's like you look at it, it looks complicated, but it's like, well, that's what it is. It has these different fields and it has these different relations. If you want to visualize it and understand it, you can just look at it and you're like, wow, that's complicated. It's like, yeah, it's because our apps are complicated. And so you are going to be implementing a state machine whether you use a state machine library or not.

00:12:36 - David Khourshid

Yeah, that's exactly it. When people are writing simpler code, the complexity lies in the code that you don't write. If you want to add a feature or change something, you're going to run into bugs because that stuff wasn't specified.

However, with a state machine, I like to think that it makes maintenance and adding requirement changes a lot easier because everything is up front. You know what transitions are there. You know what events and states are there. Adding something is as simple as, if you visualize a state machine, you're adding a box and you're maybe moving around a couple of arrows. That's a new feature. So all of that complexity is right in front of you, and it's all just states, events, and transitions. You don't have to deal with other abstractions or even ad hoc abstractions that you might create if you don't use an explicit state machine.

00:13:25 - Anthony Campolo

I recommend our listeners take a second to go to Stately.ai so they can see this. Once you see it, a lot of this stuff will make more sense. Otherwise, it sounds kind of abstract. I'd be curious to get more into the collaboration aspect. You mentioned that this is a tool to not only create these diagrams and state machines, but to collaborate on them. So what are some of the features and functionality that enable that kind of collaboration?

00:13:51 - David Khourshid

Sure. We have a lot of plans for collaboration, which I'll get into in a minute, but currently we've heard from a lot of developers that one of the main reasons they would choose to use state machines, whether it's with Stately or XState or not, is because the logic cannot just live inside their heads. They need some way of sharing it with the rest of their team.

We've heard stories from developers saying, like, I was able to take the exact same app logic that I wrote, copy and paste it into the XState visualizer, print it out or take a screenshot, or share it. You could actually share that visualization via link with project managers or designers, etc. Basically, give it to them in a way where they could easily consume that and understand what's going on, at least at a higher-level perspective. This enables collaboration because if you try sharing code with a designer or a project manager, unless they're technical, they're likely not going to understand what it is.

[00:14:49] Even if they are technical, how many times have you shared code or reviewed a pull request and you're like, hey, I'm a senior developer, but I have no idea what's going on over here. Can you please explain it to me? I've been developing for over 12 years and I still feel that way sometimes, where I have to ask for an explanation. But a state machine just presents that common language.

As far as future features in Stately, we want to be able to add commenting and collaborative editing to these state charts and more. Sharing features like you could share state machines via link, but we also want to provide first-class integrations to GitHub so that the state machines that you create in your applications are also available in the Stately platform. Again, anyone can go in there, comment on state nodes, transitions, whatever, through that link. So that's coming in the future.

00:15:38 - Christopher Burns

Some of the areas that I am really curious about: mocking your state machines. This is something that even I suck at. How do you actually mock all the services and events that you want to do? Is this something that is going to be supported better in the future in Stately, or is this something that we're still yet to figure out as a community on how to do it best?

00:16:02 - David Khourshid

So by mocking, do you mean like in terms of testing, like end-to-end tests?

00:16:06 - Christopher Burns

Yeah. I mean, for example, in the XState Stately thing, you can press through the states, right? But that doesn't necessarily run the functions that are linked to the event, does it?

00:16:18 - David Khourshid

Okay. I understand what you mean. Yes, right now you could simulate just states and transitions, but not necessarily the actions or invocations or things like that. So we are just coming up with ideas on making simulation mode better. But in general, the way that XState is structured allows you to, like if you're just authoring normal tests and you want to test your state machines, XState really separates the specification of your state machine from the implementation details.

So you could say, this action is notify user, whatever that means, like you might do alerts in the browser, or send an email or whatever. You could do machine, well, in V5 it's machine.provide, but in V4 it's machine.withConfig. So basically you could provide the implementation details for what those actions, guards, services, delays, etc. mean. It provides an easy way to mock them out if you want to.

[00:17:15] With that said, I think that we are going to be thinking of better support for being able to provide some sort of mocks for that when you're actually trying to simulate them, whether it's in the VS Code extension or in the Stately editor itself in the browser.

00:17:29 - Christopher Burns

Yeah. This is something that I think would be really cool, because a lot of the time when you're building out a state machine, and this is prior to using the visual UI, you want to run through the state machine without using the UI. If you could do that in the VS Code extension or something we're yet to talk about, to be like, oh, push an API request, do this, do that, almost as if it was in headless Chrome mode, if that makes sense.

I think that would be really, really cool. And to get on to the VS Code editor, what is this and how is it actually going to make my life more useful?

00:18:06 - David Khourshid

Oh yeah. So the VS Code extension is basically the editor or visualizer baked into the VS Code extension. What you could do, and this is really cool, it was really headed by one of our developer advocates. His name is Matt Pocock, who I'm sure that you all have met.

What you could do is, if you have an application and that application has XState machines defined in it, when you install the extension, you're going to see a couple of options on top of the machines. You could open it in the editor or you could visualize it. And so when you click open in editor, it's going to open a side panel. And that's going to be the Stately editor visualizing that machine that you have on the left.

Now, like you said, you could click simulate and it provides some very basic simulation just of your states and transitions. I agree it would be useful to show, hey, this thing is being invoked. Here's this action happening. Having all of those things in there, or even the ability to send payloads to events, there's a lot of things that we want to add to simulation mode.

But one of the other powerful features is that on the right, it's not just a visualization, it's your actual state machine that you could edit visually. So you could delete state nodes, add state nodes, maybe drag transitions around, just move things around, just like you're editing any sort of diagram in something like Excalidraw or Lucidchart or something like that. What will happen is that the code on the left will be updated when you edit your state machine on the right.

It's very experimental, but very promising. People have been using it for a few months now, so yeah, it's just a very useful extension.

00:19:48 - Christopher Burns

I think I have quickly played around with it, but I couldn't quite get it working right on one or two of my states, as the buttons to pop up to open would only appear on certain of my machines. But I'm sure that's an early bug of it, as I think it was a few months ago.

Two other areas I really want to tackle are state machines as components with Zag, and also state machines on the server. State machines on the server is a really interesting question because Erik Rasmussen demonstrated this at Remix Conference. I believe I was watching the talk, but I definitely believe it was state on the server. What he managed to achieve was JavaScript-less multi-form processing without JavaScript enabled.

What are the benefits of state machines on the server? And is this something we've hardly explored yet?

00:20:45 - David Khourshid

Oh, that's a great question. So state machines on the server are actually really useful. I'll say first, state machines on the front end. I have a lot of developers saying, like, I'm interested in XState, but I haven't really found a good use case for it yet. And maybe they're working on just simple CRUD apps or something like that, where having a full-blown state machine doesn't really make sense because their app logic isn't that complex.

However, once you move to the server, then the use cases sort of explode. That's because almost every server-side application has something that's called a workflow. A workflow, just for those who don't know or if you want to put a specific definition to it, is a series of steps where you have to do one after the other in order to accomplish a specific goal.

For example, if you want to upload an image, then you know it might go through a few steps. There might be one step where it's minifying the image, and then another step where it's uploading to a cloud location, and then another step where it's retrieving the URL. And then another step where it's giving that to the user.

Of course, these sequences of steps might be more complicated. Eric showed a checkout flow. It was pretty straightforward, like step one, step two, step three, step four. But not all workflows are that straightforward. You could have different things happen depending on other conditions. You could have branches, you could have loops, you could have different triggers which might cause an error, and then you have to figure out that error again.

So many applications have a lot of these server-side workflows. One of the best ways to represent these workflows is via state machines and even state charts. Again, Eric presented a checkout flow with that, and that's sort of using a state machine to drive the front end views. That's one use case of a state machine on the server. Others are just like what I described: back end workflows.

I would say that using XState on the back end is something that we're exploring more and more, and we want to provide a lot more first-class features for that.

00:22:47 - Anthony Campolo

I'm curious, do you know anything about AWS Step Functions?

00:22:50 - David Khourshid

Yeah, so.

00:22:51 - Anthony Campolo

That's what I was thinking about the whole time you were saying that.

00:22:53 - David Khourshid

Oh, exactly. And so people who have played around or looked at AWS Step Functions will immediately see the parallels behind what we're trying to do, and what AWS has done. In fact, if you look at what's called AWS States Language, it bears a lot of resemblance to XState. Obviously, there's some major differences, but you still have that big JSON object which can be visualized. However, it is for state machines, and we have state charts which are much more powerful than that.

So there's a huge opportunity to basically create a much more powerful framework-agnostic AWS Step Functions. Hopefully they don't hear this and want to steal our lunch, but that's something that we're looking into.

00:23:36 - Christopher Burns

And just to carry on the conversation of servers, I think something that we always see, well, something I definitely see in my flows, is chains of await functions. For example, payments are a great example. I need to confirm the payment, then I need to communicate with Stripe. Then I need to get back that data, store that data in the database, then build a response, and then send a response through the client.

You could say that, well, logically right now it seems like await statements, like await, then do this; await, then do that; await, then do this. This is the normal. How would XState make this better, and what would it help reduce? Bugs, side effects, errors?

00:24:19 - David Khourshid

I'm just imagining your workflow right now. You have some data from data equals await do this, and then maybe have some more data or do something with that data. Say data equals await do that and then await step three, await step four. So you have this very serial sequence of async operations happening.

So in XState, each one of those would be a state. So you would have a state of doing this, and then when it's done it transitions to a state of doing that, which transitions to a state of whatever. So basically box each of your await statements. That's a state. And draw an arrow between them. And there you go. That's basically what it is in XState.

It's just representing that sequence of await statements as a state machine. And you might think, you know, that seems like just an aesthetic improvement. Maybe. But what that really enables is answering questions like, what happens if one of these await statements fails?

[00:25:12] So in code, you would have to wrap each one of those in a try/catch and do something, but you might not want the entire thing to fail. Let's say that your call to Stripe fails. You start saying, okay, I wanted to apply some different logic, like maybe we have an alternate payment provider via Paddle or something like that, and we wanted to go through Paddle if the payment fails, and then we just do different logic based on that.

Then with XState, that's just another arrow going to a different box or a different state. And so you could see how you could definitely express any level of complexity using this idea of states and transitions, rather than your very linear async/await flow.

00:25:54 - Christopher Burns

Yes. Let's also just talk about the final use case that I see in my head, the onboarding step form. So you have like ten steps and you're going to do it on the server side. Every single API call may be different. You know, one may be update profile, one may be create a team, or maybe accept terms and conditions.

How do you make sure that each step is done in the right order? Well, you would build a state machine on the server that would then say, okay, these are the steps I need to do. Then you would indicate what step they are on based upon the API call and make sure all previous steps are done before they can do the next steps. Is that correct? That sounds correct to me.

00:26:35 - David Khourshid

Yeah, that is correct. And that would be one of the primary use cases of a state machine where you could verify that these states are happening in order. And of course, you could do it in code too. You might say, like, oh, you know what, I can make a linked list to do this. That's something I learned in university and I could apply it here, or I could just go through an array and keep track of a count or something instead of using a state machine.

But at the end of the day, the developer is creating their own ad hoc, bug-ridden version of a state machine by doing that. So either way, it's like you're either creating an implicit state machine or an explicit one. It's not whether you're using a state machine or not, you are still using a state machine, but it's better to have one where it's a more rigid, declarative structure. You could visualize it, etc.

00:27:18 - Christopher Burns

Yes, that's really exciting. I've only used state machines so far on my client, but this sounds like something that I'm like, maybe I need to go implement some state machines on my server as well to talk about the other side.

So we spoke about it controlling workflows on the server, but what about components? Is XState a replacement for useState on a component-level basis as well?

00:27:43 - David Khourshid

So it could be. I say, like, if your components do have complex state, then it is useful to use a state machine, whether it's via XState or not.

In fact, in the Stately editor we do have complex components which do need XState and a state machine in order to drive them. There is this project right now called Zag, where that's basically their entire thing. They're using state machines to drive the logic of components. Now, interestingly enough, they're not using XState. They're using their own homegrown state machine library, which is completely fine.

But what they've written is actually compatible with the XState visualizer already, which is super cool. They even have a page showing the state machine visualizations of each of their components. So what this allows them to do is to take that component logic and make it completely framework-agnostic, including all of the accessibility details and considerations. This allows them to just write adapters for React, Vue, Solid, Svelte, etc. and ensure that they have the same logic for all of these components.

[00:28:44] So it's a super exciting project.

00:28:46 - Christopher Burns

Do you think all of these things are still really early on, as in we've only hit 20% of peak efficiency of state machines?

00:28:55 - David Khourshid

Oh, of course. Yeah. There's so much more research to be done and ideas that we're having. We're moving to version 5, but we already have so many ideas for the future. But all of these ideas are rooted in fundamentals that go back more than 50 years, because state machines predate basically all software engineering.

I mean, software engineering and computers and things would not be possible without state machines, which basically drive all of the logic in our computers. State charts are from 1989, and of course, there has been a lot of research done on that as well. So I think right now we're in the early adopters phase of actually using state machines and state charts for user interfaces and even for things like workflows. And I think that as we get more mass adoption, people are going to discover new patterns, new modeling techniques, and better ways of visualizing these things. That's just going to have a lot of benefits in software development in general.

[00:29:53] And some of these benefits are already being realized in many other industries, which I'm not related to, but things like embedded electronics, automotive tech, aeronautics, these more hardware-related tech fields. They extensively use state machines and state charts in development. Oh, also game development as well. They use it to great effect, and there's a lot of benefits of using it in those kinds of industries. I just want to bring those benefits over to the web.

00:30:22 - Christopher Burns

Very cool. When we talk about the future, will we see multiple standards emerge, or is XState already the default standard from the previous years?

00:30:33 - David Khourshid

Yeah, that's a good question. So the basic mechanics of a state machine, it's a mathematical definition. So I don't see that ever changing. We're always going to have those same five things: a finite number of states, a finite number of events, a finite number of deterministic transitions, an initial state, and a final state. And as long as we stay with those five core ideas behind the mathematical definition, then everything is just API sugar on top of that.

Even state charts, which introduce things like compound parallel states, final states, entry and exit actions, a lot of different things, a state chart can be decomposed to a state machine. So you could write a really big state machine that does the equivalent of what a state chart would do. So at the end of the day, it just comes to a convenient wrapper around what a fundamental mathematical state machine is.

00:31:24 - Christopher Burns

Awesome. Just like as we said a minute ago, Zag is using their own version of machines, but they are compatible with XState's versions because both of them are on the same fundamental principles.

00:31:37 - David Khourshid

Exactly, yes.

00:31:39 - Christopher Burns

Great. Have you got any more questions, Christopher?

00:31:41 - Anthony Campolo

I'd be curious who you're seeing pick up Stately right now, and if you're seeing more solo devs or companies, or if there's a certain area that you're even aiming at.

00:31:52 - David Khourshid

Even before I created Stately, we've seen a lot of adoption in companies big and small using XState in production. What's interesting is that while the primary use cases were assumed to be for the front end, like you were talking about, whether it's component logic or routing or things like that, we've seen more and more adoption of XState on the back end.

We see companies focused on things that even have nothing to do with UI. They're using XState to drive back-end processes. That's something that we definitely want to target more of in the future, but we also want to target companies who are doing some just very complex things on both the front end and the back end, which is why we're building these tools to really address this general idea of application logic or business logic and collaboration with the entire team.

00:32:39 - Christopher Burns

Very, very cool. I wonder how long it will be until something like XState is in a game. It's probably already there, to be fair.

00:32:47 - David Khourshid

Oh yeah, there's Mastery Games by Dave Geddes that's been out for a few years now, actually, and he uses XState to drive these games. They're very fun games. There's one called Service Workies that, again, this was released like four years ago now, but it does use XState to drive all of the game transitions.

00:33:05 - Christopher Burns

That is really, really cool. Do you have any last thoughts before we close this episode out?

00:33:10 - David Khourshid

No, I just want to encourage everyone to check out Stately.ai and learn about state machines and see how they could help you. Also feel free to visit our Discord. We're a very welcoming community, so if you have any questions, there's always someone here to help. Yeah, happy Stately modeling.

00:33:30 - Anthony Campolo

You beat me to it. I was going to ask if you had a Discord. Yeah. Awesome. Well, thank you so much for being here. Thank you for building XState and being such a passionate advocate and explainer of it. I think it's really cool that you're getting to actually build a company now on top of state machines. I think pretty much anyone who knows you will see that as like the logical conclusion of this whole thing. So hopefully one day you will have a state machine corporation.

00:33:52 - David Khourshid

That sounds more evil than you probably implied.

00:33:59 - Anthony Campolo

Well, thank you, David.

00:33:59 - short split/interjection

Just kidding. Yeah.

00:34:01 - Christopher Burns

Thank you so much. I personally, as a user of XState, I can't wait to see the future of Stately and how it can make state machines even easier, as my motto with everything is, if it makes my life easier, the better it gets.

00:34:17 - David Khourshid

And that's our goal. Yeah.

00:34:19 - Christopher Burns

Where can the listeners follow you?

00:34:21 - David Khourshid

Yeah. So I am David K. Piano pretty much everywhere online, on Twitter, GitHub, LinkedIn, whoever uses that. Yeah.

00:34:30 - Christopher Burns

Yeah. Awesome. I think that's about it. I really don't have anything else more to ask unless you do.

00:34:35 - Anthony Campolo

Anthony, I think we're good. That was a good pitch. Good, concise episode.

00:34:39 - short split/interjection

Awesome, awesome.

00:35:10 - Christopher Burns

There you go.

00:35:11 - short split/interjection

Yeah.