David Khourshid: 0:00

Like you could describe a promise as a state machine where you can't be in both the loading and the resolved or the resolved and the rejected states at the same time. And there's a well-defined transition.

Fernando Doglio: 0:30

You're listening to episode number 11 of 20 minute JavaScript where we discuss everything JavaScript related.. As always. This episode is hosted by open replay and open source session replay suite for developers. Stop guessing all your production issues are and check out open replay. I'm Fernando Doglio, your host, and your favorite human for the next 20 or so minutes. And today we're going to be talking about state machines for the front end. We David Khourshid he's the creator of XState, a popular state machine library and the founder of stately.ai . So David welcome. you for being here and please introduce yourself.

David Khourshid: 1:02

Hey. Yeah. So, um, like Fernando said, my name is David. I live in Orlando, Florida. And I've been in software developer for over 12 years now. Most recently I was at Microsoft as a software engineer, and now I'm the founder of a startup called stately. And, uh, we're building a software platform for making application logic and workflows, visual and collaborative, uh, and enabling this, like with entire software teams. Um, it's based on the state machine library, like you said, that I made called XState and, uh, I made that about six years ago.

Fernando Doglio: 1:35

Oh, wow. All right. So it's been, it's been under, under development for a while. We, we actually are on our blog. We published a while ago, uh, an article about XState and how it could be used to, to replace some of the common state management libraries in react. And, uh, it really caught my eye. I mean, I never heard about it before or even about using a state machine to do that on the front end. So it was really an interesting concept. Really, really different from the standard, essentially. So let's start with the basics. If someone listening and doesn't know what XState is, can you elaborate?

David Khourshid: 2:13

Sure. So yeah, XState is a library for JavaScript and TypeScript. So basically for web development, uh, that enables developers to create state machines and state charts easily and use them anywhere and even visualize in inspect them. So it gets compared a lot to state management libraries, but XState is actually much more than the state management library because it also work history. Different parts of your application can communicate with each other, uh, by sending events. And it also does things like declaratively manage effects and things like that. So you could think of it as more of a super set of estate management, library

Fernando Doglio: 2:49

absolutely. I mean, from what I've seen, you can even probably declare your whole business logic around the states. If, if you can map it, that's really powerful. And so let's go one step back. How do you define a state machine then let's get a little bit the theory down and then we go into the practical realm.

David Khourshid: 3:08

Yeah. Yeah. So, um, statement machines are actually a lot simpler than people might think. Especially if you go to Wikipedia, you're going to get a mathematical definition and it gets really confusing. The basic way you could think about it is like this. A state machine is a way of describing the logic of something in terms of three things, you have finite states events and state transitions. And so it is a mathematical model of computation as Wikipedia would say. And of course computer science textbooks. Uh, but it's also a visual one. So it guarantees that something can only be in one finite state at any given time. So the classic example is a traffic light. You know, it could either be green or yellow or red, and you can't have the traffic light be both green and red at the same time. And the transitions are also deterministic. So as a driver, when you're looking at a traffic. You always know that it will go from green to yellow, to red, and then back to green. Otherwise you have lots of car accidents. Um, and as it turns out, state machines are also extremely useful in software and especially application developments. Like you could describe a promise as a steam machine where you can't be in both the loading and the resolved or the resolved and the rejected states at the same time. And there's a well-defined transit. Between those states. Uh, and they could also describe more complex things such as multi-step forms back in workflows, chatbots, and so much more.

Fernando Doglio: 4:34

All right. And then how is XState taking the concept of a state machine and putting it in, in the hands of the front end developers? How are we going to use that for front end?

David Khourshid: 4:44

Yeah. So, um, when I first started learning about state machines, it was in the, I guess you could call it an academic aspect where. Regular expressions are basically state machines or they describe, uh, recognizers, acceptors, et cetera. And I was like, how could this possibly be used in normal application development? It's so theoretical. Uh, I read the book a while ago though called, uh, constructing the user interface with state charts that really opened my eyes to, um, you know, how state machines can be used in applications. And it made me realize. The state machines are actually everywhere in software, you know, because developers are always creating implicit state machines in their apps. Uh, but that implicitness is actually a problem because they might manage their state with booleans such as is loading or is success. And there's no way to fully understand the logic. Like you, you can't really share it with your team. They really have to dive into the code and also get a mental image of like how that logic works. So a. Yeah, basically I created XState to do two things, which is provide the, like an explicit and a, a declarative way to, um, define these same machines and also to visualize. And by describing your app logic, like using state machines, uh, you do have that clear and visual representation of even the most complex app logic. And because it's deterministic you and you eliminate entire classes of bugs and impossible states and transitions, uh, but more importantly, it transforms your app logic into something that could be shared. Even with non-technical people on your team, such as designers and project managers. And so this means that the logic no longer just lives in the developer's head, but you also have a common language to talk about logic, but just those three main concepts states events in transitions. And again, this, this is everywhere in application logic from, you know, uh, the component level to the routing level, to backend workflows, to everywhere.

Fernando Doglio: 6:42

And when you say it, you can share it. You mean through state, state charts, right? Because not like you're gonna just expect someone else to understand the definition of the state machine in code.

David Khourshid: 6:52

Right? Exactly. And so, um, the way that you would create the machines in code. Are in a way that can be visualized using that visual formalism, which is just boxes and arrows. So, um, different people refer to it as different things. You know, we have state machines, state charts, state diagrams, uh, designers might refer to it as user flows. Uh, project managers might refer to it as flowcharts, but these are all essentially the same thing. So that's what I mean by. You know that that's shared a definition or that's shared language or right.

Fernando Doglio: 7:24

That's really powerful. Um, if you think about it being able to write a whole logic and is it, is it practical to think about it that way? Because I've never really done it myself, but, um, I've seen the examples in documentation on, in code, at least you get like, uh, certifies of JSON essentially, or. Similar to JSON definitions of states and transitions and different parts of our actions as well. So is it really practical for big applications or would you say the, once it reaches a certain level of the amount of things you can do, the amount of states you can handle, then it becomes a unpractical.

David Khourshid: 8:03

Uh, so I, I would actually say the opposite where a state machines and state charts become more practical. The more you have to manage the states and events, because as application logic grows over time and it inevitably will, like, you're always going to be adding features or dealing with edge cases. You need to keep track as a developer of what are the different states my app could be in and what are all the different events that can happen. Especially the events that can't happen. So for example, if your app is in some sort of a loading state, you might want to disable certain things from happening. Otherwise you will cause race conditions and impossible states and things like that. Um, and also from a business perspective, you do want to understand. All of the features of your app. It's like where, where exactly is that listed? Maybe in JIRA, which I don't know if it's still broken right now or something, but, or like maybe in some sort of issue tracker, uh, some random place. Uh, but there is no definitive place where you could say here's everything that a user could do in the application from starts to end. Um, and so. Applications and unfortunately end up like that because you don't have a defined way of saying here's all my states, here's all my events, here's all my transitions. And so that's why I would recommend the state machine, not only for, uh, organizing the code, but also for, um, you know, sharing that knowledge with everyone, even users, but most importantly, your entire software development team.

Fernando Doglio: 9:29

Um, and would you say there are a specific use cases that lend themselves better for these type of development? Or is it good for.

David Khourshid: 9:38

Uh, yeah. So in general, used to try to use the state machine at the very least to describe the logic of any part of your app. And this is like, it doesn't matter which kind of app you're working on. You get described it in terms of finite states, which are, you know, you could refer them as modes or statuses or even routes. And also in terms of events, which is anything that could happen in the app, whether it's internal or external. So it's just a great way of describing like a user could log in or log out. This data could load, or it could, you know, presents an error or something like that. Um, so even if you're just drawing boxes and arrows on a white board that still counts as like using a state machine in designing your application logic, but, uh, specifically they're especially useful for things like multi-step forms complex components like date pickers, uh, managing asynchronous logic, where you might have a sequence of things that need to be completed one after the other, uh, different modes of the app. Um, and so much more. And so there's pretty much always some way that state machines can be applied to a non-trivial app.

Fernando Doglio: 10:43

Interesting. And, and you've, you've built, uh, let's say, uh, integrations with the React and Vue on all major frameworks.

David Khourshid: 10:52

Yeah. So currently there's integrations with React , Vue, Svelte Stencil I believe. And we're, you know, we're currently talking about adding integrations for angular, but XState itself is a framework agnostic library. And the interface is really similar to in events, emitter, or observable, whatever you want to call it. So it's actually pretty easy to integrate it in a framework such as angular and people have done that.

Fernando Doglio: 11:17

All right. And, uh, interesting comparisons. Would you say that the whole process works under the sort of the observer pattern? Uh, or is it more copies than that?

David Khourshid: 11:28

Uh, I, yeah, I would actually say that. Um, so a state machine describes the behavior of what's called an actor and an actor is just like you and I it's something that. It's a specific entity where we could receive events or messages and we could send messages as well. So just like you and I are talking, we're sending and receiving messages to each other, same thing with an actor. So if you think of in observable as an interface where you could subscribe to things that it admits, um, and actor it's just one level of abstraction above that, where you could also send things directly to it, and then it has its own internal behavior. And. It might, there might not be a one-to-one like whenever you send something is, uh, emitted, but it takes that events does some internal logic and then it might communicate with outside things. But also this actor can spawn other actors too. So it's sort of like an extension of observables.

Fernando Doglio: 12:22

Interesting. And I want to touch a bit more on the, on the scalability of, of this model, because again, from a practical point of view, even if you're using some kind of visual editor to create the whole, a state machine that eventually translate into a set of configurations, the basic samples that you find online, or one big configuration file. Am I to understand that's the only way to describe your whole logic or are you able to like split it into sub files and then be able to like modularize that state machine so that it's easier to maintain.

David Khourshid: 13:00

So it's actually encouraged to split it into different responsibilities. So instead of having one single state machine just dictate all of the logic for your app, like you would do with Redux, maybe you would use. Um, it's split into just like we were talking about actors. So you would maybe have one parent's actor that's responsible for delegating things to other actors, which could communicate back with the parents. And it's also possible for actors to communicate with each other. So in that way, you have a separation of responsibility, which of course you can put it into separate files. Yeah. And actually like if your state machine, like, if you do have something that is single responsibility, but the state machine, doesn't nothing really big, just consider like, I mean, you could do like normal things where you separate the logic into different files and then pull it in. Cause it's just a JavaScript object at the end of the day. But consider too that like the equivalence of writing that same logic using switch statements or other techniques is actually going to be a lot more verbose. You know, it's not the biggest deal in the world.

Fernando Doglio: 14:06

All right. And, uh, tell us a little bit about Staley.ai then. Uh, because it looks like you turn state into a company. Is that, is that what it is?

David Khourshid: 14:16

Yeah. Yeah. That's exactly right. Yeah. I basically turned XState into a startup about a year ago. And there, there a, there is a lot of interest for, you know, the visual tooling and services and top of that state. And even though I was working nights and weekends on XState while I was at Microsoft and companies, before that, I, I quickly realized that there was no way that I could build these dream tools that people were asking for without doing this full-time or having a team of amazing people to work on it with me. And so that's why our goal. Basically to build out a software platform for visual application logic, which really encompasses everything from component logic to routing and forms, and even server-side workflows. Eventually the open source tooling of course will always be free and well-maintained, but we do envision premium tooling and services. That companies will want to use to manage their workflows and logic, uh, that hopefully will save them a ton of time and money. Um, and so, I mean, that's how we're going to survive as a business. Uh, and of course it won't be limited to just XState. You know, I feel like that's important to mention because we want this to be a platform for any sort of logic that you could describe, especially with state machines and state charts, but XState of course provides a good foundation for this since, you know, state machines are a pretty universal concept and you could translate a lot of things to state machines, even CI/CD workflows, you know, ETL workflows, things like that. We, we just feel like, you know, this is basically the visual editor for any sort of application logic.

Fernando Doglio: 15:47

Interesting. And, and on that, have you found, or have you ran into. Any use case that you said, well, this is not gonna work, uh, with a state machine.

David Khourshid: 15:57

Oh, that's a good question. So, um, I mean, I'll, I'll always recommend to use the state machine, but that doesn't necessarily mean that you have to use like XState, for example. So like I talked about before, uh, developers have been doing like implicit state machines. Um, you know, that that's typically how we code actually. So. Really it's at the point where if you want to make those implicit state machines explicit, then you would use something like XState or even just something where you could formalize that into some sort of state machine. So again, it doesn't necessarily have to be XState. Yeah, I would say that we're actually shines too, is when state machines themselves are too limiting because. You can define state charts in that state, which can be thought of as extended state machines with many more features. Uh, but for many apps you might not need all of those features. So I, I would recommend, you know, I would actually recommend writing state machines, yourself using switch statements, if you need to, um, or using a more limited library, like X FSM, which doesn't have all the state chart features, but in general, like, You know, for trivial apps like apps where you don't really have that many states, or you don't really have that many events, then no, you don't need state machines, but also those apps are pretty boring. There's not too much going on in those apps. And I always say that like, apps don't stay simple for long. If an app is worth developing and adding features to it is going to get more complex and you do want something to manage that complaint. All right. Perfect. That's all the Democrat to discuss state machines. But before we leave, I want to ask you three, three questions that we asked. Well, all of our guests. So what was the best advice you ever received? I would say probably, um, you know, that there's, there's more to life than work. Like, I don't know if you've started watching severance, but that show has been, you know, pretty addicting. Um, but yeah, so there's more to life than work in. Actually ironically, why I'm so passionate about what I'm doing now, because I see a real opportunity to just greatly reduce the amount of work that entire software teams need to do, because there's so much that we could automate. But yeah, I find lots of inspiration, just not working and playing piano and things like.

Fernando Doglio: 18:13

Yeah, it's interesting. Absolutely. And what is going back to work though, but sorry, but what is the most exciting project to work on?

David Khourshid: 18:21

Uh, I would say the one we're working on right now, which is the visual editor, because, um, it's like a diagramming tool, just like a whimsical or SkeleDraw, um, or, um, you know, sort of like Figma. Uh, but this visual editor, the, the magical thing is. It outputs code. So it's like these diagrams that you draw, you could actually put them inside your code. And I just think it's so cool. Even, even though like, I, I know all the internals of how it works and everything, I still find it pretty magical that you could do that.

Fernando Doglio: 18:52

Interesting and side question. Are you using your own libraries to, to create that application?

David Khourshid: 18:58

Oh yes. Yes. Everywhere. So XState is definitely used in the editor, the registry, the visualizer.

Fernando Doglio: 19:05

Nice. Alright. Uh, final question. What is one thing you wish you knew before you started coding?

David Khourshid: 19:12

So, yeah, I would say that, um, and this is also advice for junior developers, I guess, too, but it's that everyone Googles, you know, everyone is going to, you know, Google questions. Like I think junior developers get stuck in this trap. And me, especially when I was a junio your words, like. I shouldn't be Googling this because I'm, you know, I should just know it, you know, I don't feel like an accomplished developer. Uh, like all these other developers probably have all this memorized, which is not true at all. Like even now I've been developing for over a decade. And when I come to a problem that I don't know, I have like 40 tabs open to stack overflow and just MDN documentation, like just trying to figure out a problem. Uh, so yeah, just don't be afraid to ask for help. And. Google everything. Or Bing, if you use Bing.

Fernando Doglio: 20:02

Who does though? Yeah. Um, but yeah, uh, absolutely great, great advice. All right. Thank you again for, for agreeing to, to come in and talk about a little bit about state machines and next day, please finally let our audience know where they can find you, where they can contact you. And we'll add also those links in the show notes.

David Khourshid: 20:24

Sure. So I'm David K piano pretty much everywhere. On Twitter, Github LinkedIn, probably. And so you could find me there. And also our company website is stately.ai. So you could find everything we're working on there.

Fernando Doglio: 20:41

Perfect. All right. That's all the time. Thank you again, David, for coming in checkout at state and.

David Khourshid: 20:48

All right. Thank you for having me. Yeah, absolutely.

Fernando Doglio: 20:51

All right, everyone catch you on the next one.