Is Visual Coding Ready for Prime Time?

The introductory pause, Okay, that was quick. All right, I think we're live. Hello anybody, everybody watching? I've got David here. CEO and co-founder, founder of Stately, founder, founder, solo founder. That's hard, we can talk about that in a minute. David's here to talk a little bit about Stately visualizing, sort of software, state machine stuff like that. I think it's a fascinating topic because I think Builder tackles the visualization for another piece of the stock, and I have my own theory about, you know, the benefits of visualizing software. Why it hasn't worked in the past, like two all-encompassing of approaches versus these more fine grains like purpose builds, like, visualize this piece. I don't want to steal any Thunder from David before we jump in. Anybody joining in live, please just throw your name and where you're from in the chat. I think it's fun. I, I'm in the chat. Behind the Builder logos. If you see something from Builder, that's actually me, but without further.

Ado, David, I would love for you to give us a little bit of your background, who are you? What are you doing? Why are you doing it? Just yourself? XState Stately. I think it's fascinating. Oh, shut up, please tell us a bit about yourself, sure? So, my name is David Khourshid, not David K. Piano I, I was just telling Steve I studied piano at University, which is why piano is part of my display name. Pretty much everywhere. And I still really enjoy playing piano. As you could see right here, my fingers are in the wrong place. This isn't the piano I play, it's just a Lego. But, yeah, so I'm a self-taught developer, started with visual basic, and, eventually during college, I decided to just pursue, I guess. Web design at first, and then web developments like your typical WordPress, PHP development, and then quickly moving on to jQuery, CSS, and, eventually just JavaScript.

So, yeah, I, I've been a developer for, I think over 12 years now. I lose track. And most recently I was in Microsoft. And then a little over a year and a half ago, I decided to start a startup called Stately, where I am right now.

Play from 0:00

And then what was? Yeah, that's a perfect. Good overview. And then what was the inspiration? Like, why, why does the world need state? Where did you run into? Sort of a challenge that it solves? This might dip into X8 tube. I'd love to know when you were like, Ah, there needs to be a better way, you know? Yeah, so, speaking of me as a pianist, we like as musicians, we really like to think about things in a different way, but also a symbolic way. Like all musicians, or most musicians know how to read sheet music, which is these, you know, notes on the paper. And you could express Rhythms and Melodies and things like that. Like, there isn't a paper telling you, okay, put your finger on this note and press down. Like, there's nothing like that, it's all it. Declarative representation of just in infinite combination of, like, you know, Melodies and harmonies that you could create.

So, when I started at my first junior development job, it was for a medical company where we were just doing these really complex, multi-step forms. And this was before Frameworks were really popular, except, backbone, I think, was popular. Angular was becoming popular, but we didn't get to use any of that. It was just JQuery, and it was one of those companies where the policy was everything you build must be built in-house. You can't really grab a framework. That eventually changed, of course, because spaghetti code everywhere. But I just remember there being so many different, bits of logic and rules on. Like, show this field. Only when this is checked and that's checked, and when you press next, depending on what was checked before, go to this screen or go to another screen. And if they go back, then you have to undo some logic. And as a junior developer, it was absolutely confusing to me and it was very hard for me to keep track of what goes where.

And so, you know, as a visual learner, I just started trying to look up, like, is there an easier way of representing this logic? And so I stumbled upon state machines, and then eventually statecharts, started reading about them and became utterly fascinated with them. I'm like, Wow, you could describe really complex things with this visual notation, and this visual notation isn't. Just like a rough sketch, like a flow chart or something. It's actually an exact formalism, so it's like it's like a programming language, but visual. So I just started, you know, experimenting with different approaches on how I could represent that in JavaScript and maybe automatically generate some visualizations for that. And so, eventually I created XState, and it wasn't really popular at all until I started talking about it at conferences. And then people realized, like, hey, this is a much better, better way of thinking about logic.

Because, you know, even if it's a lot different than our imperative. Like, Oh, change this data here, or set this Boolean flag to true and that other Boolean flags are false. It just put things in an organized way and provided a concise visual language for, you know, expressing all types of logic. And of course, the visualization part was really cool. So, I just kept working on X8 for the next few years, and then eventually it got to the point where lots of companies were using it. And I, you know, I just couldn't be doing it on nights and weekends anymore, so now, as a founder, I get to do it. Mornings, day times, nights and weekends. So yes, no, I'm familiar with that. And then, no, that's awesome. And where is the? I have a million questions on this, like, I'm sure one of the initial challenges. This is what I've always run into, I mean, for backgrounds, I bought the Builder..io DOM made in 2013, and it's been.

I think I spent about nine years while working other jobs, trying to figure out how, where, and in some ways, why. You should introduce visualization into programming. So I'm sure maybe in the earliest days, or maybe you knew, to kind of already go past this.

Play from 2:00

You know, you can start on one end and say, like, Okay, you can create a state machine visually, and, you know, say, you do the entire creation with the visuals kind of programming language behind it. And then it's like, Okay, what do I do with this, how does this plug in my code, how do I manage source control this and that? And so you can take the flip side and say, well, what if I just? Visualize the exact code that I have, so you're not changing people's workflows per se. It's just their JavaScript code that goes to the same version control. And there's no weird, esoteric, oh, this needs to, you know, access some additional other system. That's what I thought was fascinating about, you know, the pieces that I've kind of seen and played with for, XState, Stately ETC is and I. There's some questions I've always had is, for instance, in order to sort of visualize the state machines.

Are you doing that with static analysis of the JavaScript code? Are you doing that dynamically? Like you will, you know, say important module and then look at the object structure. How does that work exactly like, how is the exact interfacing point, and how did you come up with that? So, right now, it's sort of both, when we so. So, when you create the machine definition, of course, it could be statically analyzed. And this is something that a few people have gripes with, the fact that it's basically a big configuration object. But really, that's that's the best way you're going to get static analysis in JavaScript without creating a very strict DSL like only use these functions in these positions? No, just do an object. Objects are like JavaScript's natural DSL. That really converts a JSON so you could use it in other languages. But there's that's.

And then, you know, even if you dynamically create that machine, when you call create machine, it's basically creating that object. So it's a big data structure and you could convert that data structure to JSON, which then can be visualized. But we are also doing, static analysis for different parts, like, we have a VS code extension that allows you to visualize the machine, but also bi-directionally edit it. So you could change the diagram and the code will update, you can change the code and the diagram will update, and that requires static analysis in order to do it. And there's actually a whole bunch of magic happening there, so it's a little bit, yes, that's what I want to dig into, that I'd love personally. So this is where, when I've seen. So I did this kind of in-depth blog post on this from a lot of research I had. Done. But when you look at like, who's who's actually using visualization tooling in sort of real production coding workflows, like at scale?

And, having like a very powerful need for it. There was really two main things that I found, besides graveyard of failed experiments of the way past, so one that's very prominent, I think makes perfect sense is, game engines. So if you look at like, Unreal engine, a lot of visualization tooling that integrates and connects really seamlessly with code. And you can imagine why that is, if you look at these AAA title games, just imagine, you know, taking a brief video of the gameplay and imagining. If they tried to build those things, like we build websites and you actually were coding up like you do CSS. The color is this and the position is this. Those are so in-depth, there's just no chance that they can have that level of quality and be hand coding all of this. What they need to do, of course, is have a UI that can access all the game objects, visualize it. Let a game like a, I don't know the exact terminology, but it's called like a scene designer come in and actually set up scenes, animations, rigging all of that.

And that is just an obvious need and is done very seamlessly. And then something that I don't think has as much adoption, but does exist. It's very cool. Is also like the visual tooling for Swift UI, which is a much like, and I think much closer to what you're talking about. Which is you declaratively show code up your Swift UI tree, and you can click on elements in the code and visualize it with static analysis, make edits in the UI, and it'll granularly update your code. Now we've done a lot of stuff like that with Builder, we actually ultimately made Mitosis to give a even more declarative format. It's useful in a couple ways, but it's very straightforward to visualize so you can parse it and it's it's got a strict structure. Kind of like you talked about one of the directions you may have gone, but yeah, when I saw you were doing this with, XState, I thought that was fascinating.

Because anytime I've tried and done the very granular like finds. Where the code is, statically, analyze it and update it. I found it to be, you know, you can obviously assume it'll be challenging, and then you start doing it, then you find that there's a thousand other challenges then anticipated. How exactly does that, does that work? I'm very fascinated that you took this approach and I love it because I think it's the best approach when it can be pulled off. So, the question is, how exact? Or, yeah, how? How do you? How are you doing the static analysis? Where you can find the state machine, visualize it and sort of update your code without sort of mangling or changing it entirely? Like, very, I've seen it kind of be very granular, which is very cool. To be honest, that's, someone else in our team, Matthias Brzezinski, and he's absolutely brilliant and he's actually currently reworking the whole engine.

But basically, it's just, we're doing ASC Transformations and so we're sort of mapping, like, there is a, you know, a Digraph, or tree-like structure for the visual part. And then, of course, there's the AST that represents all the different parts of the XState state, state machine, and so thankfully with the X8 state machine. You can't really define it in an arbitrary way. Like it's an object where you have your states, you have your transitions, and the transitions are always nested within the states ETC. And they have a predictable, shape to it. Now, of course, it gets tricky when you have comments and arbitrary code in there. Or if you, are like referencing a key somewhere else in the file, then that gets a little bit tricky. But it's still not in insurmountable. But yeah, so that's pretty much all I could say is it's ASD Transformations. We're comparing one tree with another tree, and also it's a, it's a command-based approach.

So, we're able to semantically say that we're changing a key here, or we're deleting this node and then we translate that. So what would be the equivalent to operation on the diagram side? And so we could do that both ways. So we also have to maintain the protocol where both things understand the same operations that can be done. Yes, that's awesome, and that makes perfect sense. Especially the command base. You're kind of just passing patches back and forth, not like the full representation and diffing, which will get crazy when you've got kind of code embedded throughout. Comments like you said, yeah, yeah, this is so interesting. I love that you're doing it because this is something that you know. It used to be a much more rare technique, and seeing it explored kind of more recently is really fascinating. And I still know there's some challenges. And I wonder if there's abstractions that could be made, like there's some things that you're doing with that we would probably benefit from, and maybe vice versa.

So I these things are probably so specialized right now, abstraction layers don't make sense. But maybe one day, like, where do you? I'm curious a little bit more now about like, where?

Play from 6:00

And I kind of want to mix two things because I just want to get your sense of this topic in general. You know, my first thought is kind of your. My first kind of curiosity is, where do you think this is going? And I think a particular sort of like, more specifically, like, where is Stately today? So maybe we can get back to that one and focus on Staley for now. Like, Stately, sort of, who is it for? What are the best use cases, what kind of problems is it solving in the state machine workflow? And also, you know, where is it going? Like, what's coming with state leads? I think this whole realm of visualizing code is just so there's so much that can be done. It's really exciting, so I just want to know your thoughts on all this, yeah. So if you're brand new to XState and Stately and you start playing around with it immediately, you're going to think like, okay.

This is just like any other diagramming or whiteboard tool, albeit probably a bit more limited than them. But the big difference in the I guess the ceiling that we're trying to break is that. These are diagrams that are actually executable, which means, you know, you could use that code and it's actually functioning. Code like it accurately represents the logic inside of your application. And, of course, there's been numerous, you know, startups and services that allow you. You to build things visually, like websites with webflow applications like Builder..io. But as far as the logic part, honestly, and no offense. But like, a lot of these tools are just like, Okay, here's a code editor. Have fun. There's like, no, no assistance. For that you mentioned switch, I know that there's like a navigation builder for iOS. I'm not sure if that's what, but basically, you draw the lines and you see, okay, I could go from here to here when this is clicked, and then here to there.

And I'm, I mean, I. I don't do any Swift programming, but I imagine that there's something similar like that for Swift and Android and stuff like that. But long story short is that we really want to build a tool that allows you to diagram executable models of your application logic at any level of complexity. Like there, there's already a lot of tools for doing. I guess these linear flows like go from A to B, B to C. And then maybe they have advanced features, like you could branch, or maybe you could loop back. But to us, like those are like the extreme basics. Like you should be able to nest states, you should be able to have custom types of actions, different types of events. One machine, we call it, or flow more colloquially, should be able to call another machine. Should be able to spawn like multiple numbers of machines and have them all working together.

To, to express any logic you want. So our, I guess our goal with this is to create a diagramming tool that is secretly a coding tool that's super cool. And like, what is the common sort of adoption path? It's fascinating what you said. Executive executable diagrams. And like, imagining that, you know, I'm making a Fig Jam or a mirror board with all the notes connected. And then that becomes a program, which I think is a lot of the fascination of visualizing, code in general. Like, you know, it's just the idea of, like, okay, you use a design tool, and that's intuitive. We all know why we're using a design tool we would much prefer to use. You know, even take like Google slides, I know people do make slide presentations. With React sometimes, like when you want to make a very rich and interactive and maybe a source control component. But if you just want to whip something up, you're probably not going to reach for CSS.

You're just going to reach for like, put the text here, put the image here. We're good. And then it leaves people like, why can't that? Or let's say now it's a figma, why can't that now be my, my code? Why do I have to reproduce everything? Why are there these firm barriers? And we know, you know, a UI is better for so many things. Why is there no connectivity? And yeah, it's a fascinating idea of just like you make a flow chart and then that becomes a program and can still be managed and visualizes. That is the adoption path. More that people start with the state of the UI and create something and then bring that to code. Or do they start with code and bring it in? Or does it go both ways commonly? So, I guess the adoption path, at least for right now, is that. People discover Exty through, a variety of, you know, different means, either on Twitter or conference talks or whatever. And then they realize, like, Oh wow, I could actually visualize my logic, that's pretty cool.

Let me try out XState and then, you know, they try it out. And whether they, you know, like code or like doing things visually, they might eventually go to the editor or the visualizer, which eventually is going to be part of the editor. And then, you know, they realize, Oh, hey. I could do everything that I'm doing in code visually. And it honestly takes like a fraction of the time to create it visually rather than creating it in code. So XState is probably right now one of the biggest driving fact actors. But we've seen more and more people. Just say like, Oh, hey, it's like it's like a flowchart tool, so let me try to create a flowchart here. Okay, I could go to here, go to here, and I could simulate it, and, oh cool, I could export it to code tool. Too. So in the future, we're hoping that this becomes, you know, just something that is discovered, not only by.

Developers, but also by other people on the team designers, project managers, other stakeholders. Just as a visual tool for expressing what the business or application logic should be. That's cool, and yeah, it's one of the that's a fascinating one too, like, I know, so. Builder under the hood is actually just a structured, data headless CMS. And just slap a Figma style editor on top. And now you've got, you know, kind of something else, in a certain sense. But, a lot of times when you have complex, domain modeling, like, you create all these data models, so they have all these relationships. Yeah, people do jump to programs to visualize that, yeah, and you can share it with a more technical stakeholder who's not a developer. But at least, you know, if they want to get in the weeds, they can trace the relationships, have a better understanding, and, funny enough, with most CMS's people, kind of, do it the old way.

They just reproduce everything in the visual tool and they hope it stays in sync with the actual code, the actual relationships. And they're like, you know, and obviously probably the product manager looks at the chart and they're like, this looks wrong. Is this up to date? It's like, Oh, we have enough to do that in months, you know, and have all these issues which all evaporate when it's actually completely synchronized with code, which is super interesting. And so, I have a million sort of thoughts on this. I'm trying to think of this, like, where do you think this goes over time? Like I could see worlds where? To your point, you know, Builder? When it comes to any non-trivial logic, we are kind of like, throwing some code, bring a developer in. Code can unlock all the world, right? Yeah, but suddenly you're back into, you know, the hard line of the sand.

There could be. Absolutely, you know, world where a state lead state machine is what's expressing. Anything non-trivial, which is a key component to building something of that actually has value. That's interesting at all, but also like, do you see? Like, how do you see this evolving over time? Where do you think Stately is going? What do you have? And both maybe already planned, and. Just fathoming for the future things you'd love to do, but who knows if you ever get there, right? So, first, I'll say something that probably both you and I will agree on with, Builder and Stately. And I want to talk about where I don't see things going, so I don't see things going, where we're doing absolutely everything. Visually, I think that's sort of a myopic pipe dream, you know, that's never going to happen. Like, developers aren't going to disappear just because load code tools get very good, just because there's a it's a balance.

Like there's a point where, when you try to express too many things in a low code or a no code tool. Eventually, that NOCO tool essentially becomes a programming language, and it actually becomes easier to just learn the programming language. Like, I've actually talked to people who were like, yeah, I tried to learn all of these LoCo tools. But, you know, I want to make a website that did this and that. I took a weekend and I learned HTML and CSS and I was able to do it myself. And I'm like, yeah, well, see, like that, that. That's why, you know, there's an upper limit to what you could visually express. And so the same probably goes with Builder I O the same definitely goes with Stately. And so the future I see is that, these low code, no code tools, or I'm not even going to use that term, I'm going to use visual tools.

Their main purpose is to visually augment the programming that you're already doing. So right now, as developers, I would say about 90 of our time is spent just reading linear code, which means that trying to understand it. It's in our heads and, thankfully, trying to visualize at least the UI parts. That's something where, you know, we could use hot reloading, like Frameworks are actually pretty good at that, where we could just quickly refresh. I remember having, you know, in the early days before, whatever, that program was called, where it automatically refreshed, which it was a little buggy. But browsers or something. Yeah, yeah, yeah, yeah, before those days, just manually refreshing, pressing F5. Maybe there's latency, so you have to wait and then you have to. Redo all your steps to get to the screen that you were on. You know, thankfully that's a better experience now.

And that lets you, like, not keep that in your head. Because it's very hard to just look at HTML and CSS and be like, yeah, I know exactly what that looks like, which is where you know things like Builder, I o come in and then. So the biggest question for me is like, why are we still doing things today? Where the logic, like, just when you click this button, what happens, what talks to what, what conditions are triggered? All of that is still in the developer's head. And if you're lucky, you'll get some documentation. Or maybe one developer will like, just create a flow chart. Being like, Okay, let me explain the flow of this. When I've worked at startups, I remember, we had just endless whiteboards where we would go to it be like, Okay, let me explain this. Drop boxes and arrows, take a picture with our cell phone that we know that we're never going to look at again.

And eventually that just goes out of dates. So, even that isn't the best solution, but that is really the best you could get even today. So, the, I guess the future world that I see is that. These kinds of things like documentation and diagrams are automatically generated based on the code that you are already writing, and at the same time, they assist you in writing that code. And so the purpose for this is not just for developers to have a pretty picture of the code, but instead for them to enable collaboration and communication with the rest of their team. Which I think is really, really underrated. Right now, we're living in a world where we still do handoff. You're probably experiencing that pain, and that's something that Builder..io is trying to solve, like just this handoff part where it's like, here's a bunch of user stories. Go implement them. And then the developer will have to go back to the designer or the project manager and say, Hey, this doesn't make sense, or you forgot this edge case, or this isn't going to work with this other feature.

You know, so that's, that's one big thing that I. Want to eliminate? And I think that once we break those barriers down, development productivity is just going to get 10 times as fast as it is today. Because there's really no reason for us to have, you know, 100 developers and six month development cycles just to release a couple of features. So, oh, you're absolutely preaching to the choir, so I agree completely with everything you're saying. And you know, I think there's it's so funny. Handoff is awful, or water flow Pro waterfall processes that have to go through all these steps. And so not only do these sort of like, linear, relationships between, okay, somebody specs it, somebody starts to build it. Oh, they got an issue back to the spec. They're having all kinds of miscommunications, they're saying same words, I mean, different things. Like, you know, the throughput between, you know, using your mouth to communicate with another human is pretty significant.

When you can use tools like, I can imagine a world in the future where, you know, your product manager wants to make a change to the business logic.

Play from 13:00

And if it's intuitive enough, they can just effectively propose the change. And if it looks good, great, bring it into the code. We didn't have to do all these specs, these crazy, poor ways of sort of conceptualizing things that have a better paradigm. And I think that, like, agree completely with what you're saying as well, which is, yeah, coding won't go away. We're basically just bringing more people to process and making people more productive, too. The funny realization, too, is, I wonder if you run into this, but maybe not. There was, there was like, this was like, four years ago. When I first announced the existence of Builder, I did like a Reddit post. The website was super ugly and crappy and all this stuff. But there was like, this, I can't remember what it was. But it was like, there's a tagline. And it was like something like, help your marketers and free your developers, the point being, you're freeing developers from tedious tasks.

You can focus on the more interesting work. And somebody on Reddit wrote a comment and said, Oh, you had a typo, you meant fire your developers, which is funny because most people don't jump. To that conclusion, and, it's pretty rare that doesn't come up anymore. It was kind of a one-off thing way in the past, but yeah, it's hilarious, that idea that people can kind of misattribute that, really. All we're talking about is removing boring stuff. Like, at my last job, what we all hated was just like, marketing team wants this button color now, they want this button color now, they want a second button. And that's one of the challenges of, in our case. You know, it's a lot of working with marketing. The whole thing about marketing is it's experimentation driven. So you're just trying this and this and this. If you're a developer, you're implementing that and undoing your work and redoing and undoing it's.

It's actually infuriating. You want to work on something more interesting, more lasting, and so being able to just delegate this work to others. Or make yourself more productive by removing basic details, you know, in our case, like layouts, this and that, and just focusing on making a great system of components. And then other people can rearrange them into any combination and any A B test or whatever.

Play from 25:00

It really goes a long way. I'm curious to what is your thoughts on? There is, you know, there's an overall question I have, which is like, why now? Like, why is this happening now? There were experiments all the way back in, like the 80s of visualizing software. I think it was maybe intuitive for people forever. Like, yeah, as soon as to you at one of your example. As soon as one developer adds an ASCII chart by hand or generated to a piece of code, that's awesome. But that's going to go out of date right away, right? It's going to be amazing. Until people start thinking that's true and the code isn't matching it anymore, and confusion happens, and you know, there's that whole, whole dilemma around it. But there seems to be a renaissance now. And I love how you also are stumbling on, like, low code, no code. I hate those terms too, because I don't believe in. Like replacing code with visuals, then you're competing with the rest of technology, which is wrong.

We want to be integrated within it. But I'm curious why you think it really seems? Like there was a Heyday a long time ago in types exploration of visualization of code. They didn't seem to disappear for a long time. And maybe they're little attempts, but not really. I really think there's more coming back now. I'm curious if you have any thoughts on, like, why is this happening now? Why in 2022? Of all times, this is becoming more of a reality, and with Stately Builder, there's other things out there too. Yeah, it's funny that you mentioned that because there was recently an article just about UML. And just by someone who is part of the I guess UML working group. About, like, just why it died and the various reasons for that, and honestly, I think it's, the same thing that I was talking about with low code, no code tools. Where eventually it gets to the point where they're trying to do too much, and then it becomes easier to just not use them at all.

So, with UML and tools like that's Rational Rhapsody from IBM, and all of that's like. First of all, they were focused on code generation, which sounds like a good idea, but code generation is very much a here's a code, don't touch it like this is read only code, essentially. And for a developer that's not very useful, you want to get your hands dirty with the code. And then, you know, eventually we just decided, Hey, abstractions are better. We have Frameworks and, you know, things that you can build on top of that. And man, I. I remember using visual basic I, I thought it was really awesome to, just drag and drop components and just visualize things that way. But then once he gets to needing multiple screens or dynamically positioned components, then you realize, okay, it's better to do it in code. You know, just because the limitations of those, Loco tools.

And so that's why, like, you know, at least with Stately. We don't want to be the thing that expresses a hundred percent of your logic, we want to be the thing that orchestrates 100 of your logic. So that you, if you need to write code for certain parts, you can, and that code can just plug and play and work. Together, and so in a way, this becomes very similar to tools like Zapier, where you have these, you know, workflow tools. And each of these connectors are essentially black boxes of code. That's, you know, just do stuff. And so a developer should be able to create that themselves, and, you know, just connect it. Usually a or sorry, using a visual Builder. So, yeah, I think that there's many reasons why it didn't work out in the past. But like, we're in a completely new time, where we have, like, thousands of times more developers now in the world.

That's a non-accurate measurement, but there's a lot more of them. And also, everyone is doing things their own way. We have so many competing Frameworks, so many computing libraries and even languages right now. But at the same time, we still have this huge problem of. Most of the code that you're writing, like, most of the logic, has probably been written thousands of times before by other developers in other languages. But none of that code, even if they were able to share it with you, none of that code can be used in your app because you have unique constraints and things like that. And so that's something that I want to, I guess, democratize, and I think that there's a huge opportunity for, you know, visual tools. Again, like, what, what Builder IO is doing with what Stately is doing, uh? To really make it easier to put those Lego blocks together instead of having to do all of those repetitive tests. Because companies are realizing that developer time costs money, and developers are more expensive than ever right now, you know, it's crazy.

We find this at Builder a lot. I. There seems to be a weird psychological principle at play and I can't figure out what it is. But people don't equate, people don't fully understand how expensive developer time is. Like, really, really don't seem to get it. Yeah, and it's so funny. And I think there's just a larger market education to do over time on just people's lack of fathoming that.

Play from 27:00

And and when software can supplement and accelerate the engineering team, businesses just don't compute, and it's it's funny, and it really takes a lot of education for people. To realize the value of developer time. Especially, you know, depending on your team size. And and this and that, and it's. It's funny because, you know, I'm trying to draw a mental framework on sort of like that question of like, you know, why, why now and how? And this and that. And I think one big thing that's that's happening a lot lately. In this approach you take and we take two is being as minimally prescriptive as possible. So, like, I remember something, and I know flow-based programming and state machines are different. In fact, I'd love to unpack that, like similarities and differences there too. Yeah, but I remember there was this, it was so funny, uh. Developers have a hard time marketing, I've noticed, and marketing to developers is very hard.

Like just generally generating awareness for something that, you know, will benefit people. But you know, people are doing things with their lives. You have to find a way to be in front of them at the right place, the right time. But I remember there was this, this startup, that I hated, their marketing, but I know marketing is really hard and so I can't judge that. It's called node flow, or something like that. Oh, no flow. Yeah, no flow, that's it, yes, and so flow-based programming. And that was another example of just. I think, in my opinion, they're just far too prescriptive. You had to write your application as these sort of like compartmentalized nodes, and you had to. They all had to have a certain structure. And, you know, gives you a certain level of vendor lock-in. To, you know, a bunch of concerns of like, is this the right structure for my entire application or these whole portions of it?

And you know, I think that became a serious challenge, for the adoption rate of no flow personally. And it's really cool that XState, you know, and Stately, you take an opposite approach. You work within your applications, you don't have to refactor the whole application. In fact, you can be very granular as to where are you at it and get value immediately. So incremental adoption is really critical here, too. And it's funny, and was this actually? Here's, maybe something more specific I'd love. Your take on? Was the plan with creating XState ever to get to the point of, a Stately service? Was X8 purely just trying to solve the minimal problem? And you realize more was needed, and a service on top of it would be the best way to power that. Like, what was that path? Because I could see, just for a sake of example, if you created Stately first and you're like, oh well, you can only adopt this.

If I made a wildly popular open source project, that's quite a criteria, but you kind of had the first. I'm curious if the latter was kind of in mind at that time, or how that came to be too right. So, first of all, Stately was created seven years ago. And I, I wish I could claim like, yeah, I have a, you know, four sites to be like, yeah. This is going to be hopefully a very successful business one day. But honestly, no, it was just to scratch and itch. The first version was written with, you know, JavaScript and low Dash. And actually, before that, I was experimenting with PeGJs, which allowed you to write these, custom string based DSLs. Which that was actually really fun.

Play from 32:00

And looking back on that, because I'm like this, this seems like a really great way to write these state machines in a more concise way. But yeah, it was mainly to scratch a niche. And then I presented it at a Reacts conference. And so then people were like, Hey, I'd love to use this in reacts. I'm like, Okay, I'll make adapters for React, and um. But from the get-go, I didn't make it framework specific, I didn't make it for a specific technology. It was just state machines, which happens to have been around for, I guess, over a century now, or century-ish 1950. I don't know. I mean that it's how basically all electronics work today, you know, via state machines, but yeah. So eventually, like a lot of the use cases, were centered around React. So these multi-step forms, these complex component logic, just all sorts of things, and oh yeah, also just, fetching logic, where it's like, all right, I have to fetch this and then do this, and then do that and then.

Depending on what happens, go here, do this. Like that, that's something that X8 can express really well, uh? But eventually, people started using it for other things, like for chat Bots, for even server-side workflows, and also home automation. Like just I. I started discovering more and more use case yeah uses. People have been using it in, like, Frameworks like Phaser for games. And so I was like, Okay, wow, there's actually a lot of potential here. People are using it for a wide variety of use cases. They want even more power out of the visualizer because people are actually relying on it. I, I sort of did that as a toy, too. I'm like, can I actually visualize this in boxes and arrows? And, you know, the answer is yes, uh. So eventually, like, you know, like I was saying before, it got to the point where enough people were relying on this.

And you know, it only had a couple of maintainers. Still does, you know, we have a small handful? But you know, I, I just needed to find a way to, uh. And that's always a hard problem, too, is just finding a way to make. This is an actual startup, like make it an actual product, and you can't really do this with every, every kind of popular open source project. But thankfully with state machines, you can, because there's a lot of, you know, DAG tools and workflow tools out there today. And actually, in terms of software modeling, like with state machines, there's not too many tools. Maybe in the embedded electronics industry, there's like Simulink, state flow and stuff like that. But yeah, I just decided to, yeah, figure out a business for it. No, it makes sense, and I love that it sounds like, and you tell me if I'm interpreting wrong, took a very incremental approach. In fact, I think I remember seeing a very old conference talk of yours, where it was just generating a one-way visualization, just a static image.

Look, we can see what we're doing. Like, I'm curious, what was the point where you're like, what if I, you know, made that into HTML nodes? And I just let you kind of move it? And I just tried to write that back, like? Was this an experimental process of like little hacks to see what could be done? Was this like a very? Did you approach a different way? I'm just curious how you talk about that, because I find these things. Oh so, for the actual visual Builder or the visual editor part, exactly the time you're like, I want to write back to the code. Yeah, so I was still at Microsoft and, you know, at ON on the weekends. I would just be like, visualizing is cool, but it's sort of a one-way thing. Like, I really wish I could go the other way. What would that look like? And so that led to many experimentations with canvas, HTML, SVG, all of these different things.

I probably have like five or six different prototype versions of that. And yeah. So eventually, like it, it just became, you know, this process of creating a Digraph, I call it so a Digraph structure that represented these nodes. And I actually intentionally did it so that it wasn't, it wasn't married to XState or state machines and statecharts, but rather just. It's a directed graph. Where you have nodes and edges, and these nodes can connect to nodes which might be nested in other nodes, so you could have infinite nesting. And these edges. Could, you know, just connect one node to another node? And this pretty much describes all state machines, all statecharts. But and this is part of our future plans. It also describes things like what you would use for CI CD processes, what you would use for any sort of workflow engine. Even things like just graphs that don't have to do with flow, but might be like, like relational diagrams or things like that.

Yeah, actually, that's fascinating, and yeah, that one's interesting one. Today, I will admit, we were thinking through sort of a more first-class way to visualize, just complex schemas, the structured data part of Builder and how you could visualize and potentially manipulate that back. So it could be an integration path between our products in the future, too, where you could use something to visualize the model relationships, make edits, show it to the team members. That'd be interesting. Follow up on that separately. Yeah, but another thing, so. What is what is the difference between a state machine and flow-based programming? Is there similarities? Is there differences? I'm curious, so they look the same where you have boxes and arrows connected, but they're actually very different, so flow-based programming is. You know, you have a node, your that node might be doing something with data, and then once it's done, it passes it off to another node.

And so each one of these nodes can be considered entities which have a responsibility to do something with that data, convert that data. They're, I, I mean, they're always doing something, and so with the steam machine, that's different. So, I would say. Flow-based programming is closer to the actor model, where each of these nodes are actors, so just entities that do something. And the state machine describes the behavior of a single actor. So, for example, my brain is my state machine, which might sound really geeky or whatever, but and your brain is your steam machine. But the way we communicate to each other, that's more like your flow-based programming approach. Because I'm sending you a message, I'm sending you data, you're interpreting that data, you might be sending me data. Except, I think in flow based programming, you can't, you can't have cycles. But source stressing that definition a little bit.

But yeah, so both flow-based programming and state machines are fundamentally different. However, a state machine can represent the behavior of a single node in flow-based programming and actually has proof of this. Node-Red, which is a very popular flow-based programming tool. There does exist in XState Node, so you could represent a state machine. No, no, that's cool. Yes, that's fascinating. And then, is there? Yeah, I really want to. Is there a degree to which we can talk more about sort of that idea? Like, because I have, been fascinated by tools like Zapier and Zapper's fantastic. They're Builder customers, so you know, they're, yeah, their team is super awesome by the way, and, everything they do.

Play from 35:00

And it's clear that they solve one specific problem well, but that type of solution, that type of, just visualize a workflow. And yeah, there's a very linear kind of, like you said, you kind of do one, two, three if you use an advanced. Feature you might like, I think they have a filtering feature, so, you know, a bit of a conditional filter. This and that, right. And yeah, you gotta mentioned, there's some other tools that can do branching and loops and get more advanced. To forget a couple names Alloys when I remember for e-commerce, and there's one that's a little more popular, more, more Enterprise. But you know, I'm curious, yeah, I. CICD is a great example because I don't know how RCI CD works at all. It's our engineering team set it up. Every time I go to look at configuration files and output, I'm just like, you know what, I'm lost. It's fine. It does the thing I need.

I say, deploy, it does deploy, you know? But I wish there was an intermediate layer in between, like the button does the thing, okay, you know, black box, or whatever. The best term for that is in the extreme example of like, line by line. Looking through code, configuration, the tools used, and really trying to make sense of it. Which, like you said, I mean, programming is a lot of drawing a mental diagram, and exactly funny enough, you'll get 80 to your mental diagram. And then you get a slack message like, my partner will come in the room and it's gone. I'm like, Oh, get out of here, like, quit slack. And then it's like, Oh, back to the drawing board to make my mental image. But yeah, this idea of expressing more things than just say, like, a front-end, state, honestly, is extremely appealing to me and I want to. I hate this term, but I don't know a better one.

I want to double click into that. It might be something you have, not a lot more you want to share on. It's kind of exploratory future direction, but I don't know if there's anything else you're exploring in that area, or what that could look like. And this, and that I'm fascinated if there's more kind of you have in mind there. In terms of just like visualizing, application, logic, flow, or like, yeah, other. I love the use cases you gave. I'm trying to imagine, particularly like how that, how that would work, you know? So what the timelines do you think are? Yeah, tell. Me, Oh yeah, so I. I just want to go back to your previous statement about how, like, basically, it's a spectrum, right? You either have a black box where it's like, Okay, eventually maybe you'll get the result that you want, and then you have the really, really granular approach.

At the other end, where it's like, I'm debugging, I'm going line by line and I'm trying to understand everything that's happening. And there really needs to be an abstraction in the middle, where it's like, Okay, you're at this date, this thing is happening, and here's the possible things that could happen from here. Sort of like a Domino's Pizza Tracker, you don't need a camera watching, like, you know what ingredient the person is putting on the pizza or what? What position it is in the oven? No, you just need to know, Okay, it's in the oven now, all right, it's being delivered. Like those are the concrete steps you need to know. And so when we do typical programming, we don't have that level of abstraction, we're just guessing, building a mental model on it.

Play from 42:00

So, that's, that's one of the things that I really want to like. I really hope to see in the future with Staley is being able to. To express application flow, even as you're using the application in a way that the entire team can understand. But I guess in terms of like, the future and just other applications of this, there's, there's just so, so many. One of the big ones that I'm really excited about is testing. Actually. Because even if you're not using X data or state machines in your application, state machines are extremely useful for testing. Actually. So think about it when you write an end-to-end test, it's like, for like, for a login flow, enter the username, enter the password, click this button, and depending on if it's correct, the user should end up in the dashboard. And then let's say, you know, you wanted test the failure flow, Okay, enter a username, enter path.

So you're basically writing the same stuff, or 90 of the same steps for this end-to-end test. And then, guess what, let's say that you wrote like a dozen of these tests, and then someone says, Hey, we actually changed. The login flow now there's an interstitial, or there's a screen, or the username and password are split up on different screens, which some apps do. Guess what, you have 12 or 20 tests that fail just because of that behavioral change. And so there's this thing called model based testing, not sure if you've heard of it, it's really, really interesting. So instead of writing all these tests manually, you write a state machine that describes, how your application is supposed to behave. So you're like, okay, the user can be in the login screen and then logging in might be a spinner or something. And then they could either be logged in, or they could have an error and be taken to a forgot password screen or something like that.

And then, you could generate each one of those scenarios. So basically traversing the graph like there's nothing too complicated about it, except, of course, the algorithms. Shortest path, simple path, just all these different things. And you could generate like just potentially hundreds or thousands of tests based on your model. And then later you could say, Hey, this feature actually changed, we changed how our login flow works. You only change it in one place, the model, and then the paths are regenerated. And you basically have a comprehensive Suite of end-to-end tests that are going to cover as many use cases as you desire. So testing is definitely an area that I'm very, very interested in, and a lot of people are too, because it really makes writing tests a lot simpler and more robust. That's fascinating. Yeah, and how much does that? I love this. You're gonna be really excited about eggs. Something I have not implemented in any major project, but this is making me way more like, Oh, I get it.

I knew there was. I mean, there are certain things that always made sense. But as you go into more detail, it like it starts to click even further. And so, to what extent do that? I love the idea of generating tests and adaptively updating tests. And I mean, I love any type of intermediate representation too, especially when bi-directional. It's like, that's how our mitosis, system works as well on, just all these sort of like bi-directional flows where you. Can have UIs updating code, code updating UI and something in between. That's maybe the better abstraction for, various other purposes, um. But with those tests, like, I'm just imagining, Okay, you have a complex flow. Written React, so say all the state is an XState, and say all the UI is in React. If I generate a bunch of tests, how much do I need to even worry about testing anything else? Like if, if, because this is, the state machines.

I know the concept of and everything you've described, and some work that you've put out before, too, some content that I think is great. And I'm trying to think of, like, I'm really like, stretching my brain to say, like, you know, and I think of, like, the React team, that whole thing of just like. UI is function of state in a pure form. States index state UI is just an output. Obviously, users can do basic inputs. You know, if you generate tests at the state layer, how much do you even have to test a UI layer? If you did that generation? You said, is your test Suite kind of made? Is there even any much left to do at the UI level to care about at all? How do you see that? Well, sort of so. You know, you could test that the state is going to be correct, but UI could actually pretty frequently be out of sync with state.

So, for example, you know, you could say that, hey, according to my state, this screen is supposed to show. But now maybe you have some error or some CSS is hiding something, so you have all these different things. Which is why I think that there's there's still importance in testing, like just the entire end-to-end parts, um. But it also brings up the interesting point where if you do author your logic as a state machine, you could use in theory, you could use that same state machine. To, you know, to test your application as well, because it's essentially the blueprints for how your application is supposed to flow. Yeah, no, this is super interesting. And yeah, it's so funny, too. The I think, you did a talk specifically on the problems with useEffect. If I'm butchering. It, but, I mean, that was the first thing that my mind went to. It was like, Oh, yeah, I sing. It's like, Oh, you forgot to add something to the dependencies array?

And of course, like with X8, so we use internally a builder we mostly use, MobX I'm a huge fan of. Just like actual reactivity, like Solid.js, too, solid is incredible, like when it's just built into the framework. Oh my goodness. With XState, you don't need to worry about a lot of those UseFX problems, right? Like your state sinks nicely. Can you tell me a little bit about that? Just from a dummy? Haven't gone in an up depth with this point of view. Yeah, sure, so. And, this is something that I feel like a lot of state management libraries are also sort of missing. Is that effects can be declarative, too, so and also effects can only happen in one place, a state transition. And so what that really means is that, in effect, like fetching a promise or doing some sort of action, does not happen out of nowhere.

There has to be something that triggers that a user click the button. Some data was loaded as some other signal happened from some other part of the app. But like, there has to be a reason for every effect. And so that can be declared, or that could be represented declaratively inside the state machine as well. It's not an extension of estate machine, it's literally how state machines work. With output. They call it like, I guess, the theoretical term, but also in statecharts, it is directly represented as actions. So, yeah, that's why with XState, you could say, hey. When I'm in this state, this action should happen, when I make this transition, these actions should happen. Or you could even abstract it a little and say, whenever I enter the state or exit this date, these actions should happen. And you could also do what's called invocations, where you could say this action might be long lived until I exit this date. So, for example, if I'm representing dragging and dropping while I'm in the dragging state, I should be listening for the mouse move events, but when I'm not in the dragging state, I shouldn't be so.

I could, you know, just start and stop that, and so that's part of the reason why I gave the it's called the goodbye useEffect. Talk was to emphasize the points. That effects belong in these state transitions, and they don't necessarily belong in. Like, oh, let's listen for some sort of state to be changed. And then, depending on some conditional, execute this effects. And then forgets to dispose it or whatever. It's more, you should move your effects closer to where the event actually happens, which, is an event. Handlers, and the next state, the entire thing is basically a Giants event handler. So you could just move it right in there. Yeah, that's fascinating and is there. I'm also thinking, too, you know, if somebody looks at Eggstate for a split second, they might go, Oh, you state is less code, so that must be good, you know?

Play from 45:00

So I'm curious, yes, yeah, I sorry. I'll probably Rance on this for another two hours, but tell me that's the thing. Have you seen Rich Hickey's talk, you know, simple, made, easy, or something like that? I haven't, but that sounds like it's a classic. So basically, there's a difference between easy and simple. Like, easy is you getting from point A to point B in the quickest possible way? Simple is you being able to Traverse the alphabet in the most efficient way? That's sort of the analogy I can make. So, basically, what I'm trying to say is that when we could directly manipulate state. And of course, at the most basic level, that's just object mutation. Like you just mutate values, account plus instead of sending an event somewhere. That's the easiest approach, but easy is not simple, so when you do that easy approach. And it's funny that you mentioned Mob X, I know that MoBX has actions which sort of prevent you from directly mutating the states, but I guess older MobX used to be a problem.

When you're allowed to just directly change state from anywhere, and this is still a problem with other state management libraries, then things actually become more complex and harder to do later. Because, for example, let's say you're making a counter, right? You would do like on this button count. Plus plus. But now, let's say you have to enforce a minimum and a maximum. So now it's like, where does that logic go? And especially when you, when you could manipulate C from anywhere, now you have to share that logic somewhere. And eventually, you're just making a crappy version of a reducer. So even though you're like, oh yeah, just manipulating the state, like, couldn't be easier, so that's why XState sort of takes the approach where you can't directly manipulate the state. Everything is based on events, so sort of the, the Redux approach. And to me, this Maps more directly to, you know, to what is given to you by project managers. Like these user stories in that everything can be expressed as events, like when the user is in this state and this event happens now, here's the new state.

And so that's why, you know, X8 sort of unapologetically takes that approach, rather than the oh yeah, you could update data from absolutely anywhere approach. Because that allows you to, I guess, to make adding features and changing features a lot simpler in the future, rather than easier. Yeah, and that's what I was kind of getting at. Is it really the case in just for background, too? It's, you know, we're finding. For instance, with quick. One of the challenges we'll run into is, it's a problem that you run into later, right? So you can feel the simple application and then you get the problem by the time you hit the problem. I've seen state become an absolute Rat's nest of insanity. Once you're in that state or in that, yeah, once that's happened to you, it's very hard to undo. And so, yeah, you know, one challenge, I'm I'm guessing, that will just inevitably face.

XState is the most minimal example, is going to look a little more complex with XState. And every documentation and every like Dev.2 post starts with the trivial examples. Look how trivial this is. And there's a reason for that, right? So it's all JS does. You know this and that there's, there's cool stuff there. But yeah, I'm guessing there's like a curve of like, you know, you state, or just like direct manipulation. State management start simple and gets really complex quickly, and. Eventually can be a ton of code because you're just conditions and guards, and sometimes you're doing set timeout to check this and then. Or really, really crazy, yeah. And then X8 will start like a little bit, and then it'll just kind of be more flat. Over time, as things get more complex, much more manageable, and it's actually a robust application, is probably smaller and simpler, and much more debuggable.

Play from 53:00

I take it, and that's exactly it. So, basically, you're moving your logic into these, I guess logical containers or reducers, if you're coming from the Redux world, and they're all contained in there. And so the end results of that is no matter or how complex your, your reacts components are, or whatever other framework you're using. Every single interaction is either going to be, sending an event or reading state, and that's it, like you, that's pretty much all you have to do. So you click a button, that button is only going to do one thing, maybe two things. But the one thing it's going to do is send in events, the other thing it might do is prevent defaults. If you know if you have some sort of silly, UI thing that you have to fix. And reading states, it's just you have this. What we call an actor, and so you could just read a snapshot, we call it.

And so this is basically like you selector and Redux, it's basically it's even the same as like atoms and Recoil, or in MobX, your store, same concept. So I, I have the theory that pretty much all like. It doesn't matter how complex or how simple your, your applications are. They could all be reduced to that. Where your components are only doing one thing sending events, and your components can read the states, whether it's local state or some Global state somewhere. And so that's where I think it's simple, because otherwise you're saying, listen, I don't need that, I just need React. Hooks. And then you end up with seven use dates and three useEffects, and maybe one useLayoutEffect, which it needs to be layout, because if it's useEffect, things are going to break. That is very difficult for me to understand, you know, especially like, Okay, when? This dependency changes. When is this effect in the rumble?

It's completely unclear. Yeah, absolutely, and I. The other thing that happens, too. Besides your code becoming a mess is, performance can really take a dive.

Play from 57:00

Because once you're kind of losing a concept of how things are working, your code becomes redundant, becomes bloated. Which is a performance nightmare. It scales poorly this and that. Yeah, this stuff is so funny and that's something that, you know, I'm seeing, being a challenge. I mean, all these projects are growing, so it's not like it's like a hair on fire issue, but it's just funny. Because sometimes, when there's just a clear, better way, it's surprising how many people are like, you know, I'm cool with what I have and like, that's not a problem for me. And right, it's hard to explain like it's not a problem yet, but it's kind of right. So actually, let me give you a similar analogy. That's closer to Builder.io before Frameworks, before Backbone and whatever. JQuery was King. And so if we wanted to append the list item or show a you know, components, or show something. We would use JQuery methods, you know, we would create an LI and just append it to our UL.

I. I forget the commands. It just involved a lot of dollar signs and, things like that. Basically, there were a dozen, you know, dozens of ways to just have these interactive parts on the screen. Now, if that were the standard way of creating and updating dynamic UIs, would Builder..io exist? Probably not. That's one of my biggest answers to why now for Builder, it's only possible with a declarative component model. It would never be possible. Yeah, so right now we're in the JQuery era of application logic, it's absolutely everywhere. As 10 developers had to implement something, you're going to get 12 different answers. So, like, there's there's no declarative way of doing it, and, things like Redux and even those stands to an extent, get closer to that. But we think that ultimately it is going to be in more of a declarative. State machine type of model, and I say state machine type.

Because with XC version 5, we're actually going to be, allowing you to express behaviors that are. Are still going to be the same sort of actor interface? But a behavior can be a state machine, it could be a promise, a reducer, an observable. Just a bunch of different things, but they're still going to be contained in those. You know, we were talking about flow-based programming, each of those nodes that could talk to each other. And. So, eventually, you could say, Hey, my logic's in the promise right now. Eventually, I want to make it a state machine, but I don't want to do that just yet. That's fine, you could progressively enhance later, and then, make that a state machine. Yeah, that's fascinating, I love that, and it's it's funny too, because, and I, I understand how things have to be done sort of iteratively over time. Like you can't solve everything at once.

It's a bad idea, but it is funny, too. When you start you, you learn about the concepts about of React originally, which is all about that declarative benefits and get rid of a narrative. And then you start writing a lot of React code and you're like, wait, this is getting really. We got rid of part of the spaghetti and we opened up a whole new realm of spaghetti. And it's funny that it's taken us this amount of time to figure out more declarative paradigms at work. And yeah, I mean, to your point, the components, sort of layouts now are finely declarative, no longer like JQuery. So you can have the UI tools on top of that, yeah. And now it states, become more declarative, you can add UI tools on top of that and all sorts of other benefits. Like you said, testing, go ahead. Yeah, and I, I was gonna say, it's it's not just the visual, you know, Builder aspect of it.

Like, when React was created. Like, the goal wasn't, like, okay, now we could have those visual builders for these components. No, the goal was. Now we could have a predictable way to build these components and have them in sort of a compartmentalized way. And then, of course, I led the way for visual tools. But the result is that we are, like, just compare. Pre, I don't want to say pre-React, but like pre-framework, like Angular to post framework and. Now we're able to create just these really, really advanced user interfaces that could do a lot of things show and hide things. Work offline or online, like, just like, do so much more than what we were capable of doing, before these abstraction layers. And so I think that moment is going to come for, you know, for complex application logic as well, that, you know. Hopefully, now that we have this abstraction layer that's declarative for logic, we're going to be able to express much more complex logic.

And that translates to our applications having more features, more intuitive features, more customization, and being able to add features without fear that something else is going to break. Because when you add a single feature, you exponentially multiply the number of potential bugs and edge cases that you could have. And so I, I guess that's why, you know, we were slow to build features because we do want to be cautious about it. But it is sort of that Roche limit that I wants to sort of Escape, so that we could build more complex apps without fear.

Play from 59:00

That's a great point, and frankly, I obsess over that. Our startup is not about 50 people. And it's like, you got to be very conscientious about, am I going to build a thing and be supporting it forever, or can I build a thing? And things kind of just run smoothly? It, you know, microservices and that Tech on different ways. State machines. Just managing complexity to make it not a burden forever, but something that actually just works. It's it's made and it functions as expected and stuff like that. But anyway, I could probably have this conversation forever. We're at our sort of pre-allocated time that we usually grab our streams, so it's a good time to say, david, this is a ton of fun, as expected, tons of overlap and sort of like ideology. With XState, instantly and Builder and quick and all that stuff, we need to get a, an XState quick integration going at some point, too.

I think that should be a very strong, oh yeah thing. I'd love to jump into quick. I've been hearing a lot about that. You know, I've been drinking water this whole time, hydration's on my mind. Especially the lack of it. So, yeah, yes, yeah, no, and it's it's going to be fascinating, if it's of interest to you, and I know your time's probably thin doing the whole startup thing. But the fascinating exploration right now with quick is, we have signals in quick now that can go over the wire. Meaning, you can send your application as pure HTML to the browser, and state mutations can actually happen without the framework downloading, without code downloading a signal can. Actually. It's very hard to describe. So if you think of, if you think of solid..js signals and so like, something changes. And the tiniest DOM node will change. No, like, component, component, executing and diffing and all of that. Imagine that same thing, but over the wire.

Meaning the reactive state graph is actually made on the server or during server-side render or static generation. If I click a button, a tiny bit of code. That's not the framework, it's not your component, it's not the assembling of all of the VDom. Or anything. Is just going to granularly update, you know what in the UI needs to update? The big question, of course, though, is building abstractions, like using something like XState. But seeing if we can support this to not all run the clients and use that presumability aspect, it's something that the market teams exploring with. Marco, 62.. I have no idea how that's going to be, but it's going to be really fascinating to figure out. I mean, I'm sure it's possible. I don't know if you've seen Eric Ross Musin's talks on, UM. He was using Remix, but the concepts are sort of similar where, you know, Remix can work completely offline, so he was demoing.

Just a your typical shopping cart application, you could increment the number, and it's basically using a complex date machine to orchestrate that logic, because shopping carts are not that simple. You have many steps depending on what the user clicks, you have to go somewhere else, etc. Etc. And then, in his demo, not so spoil it for anyone who hasn't seen it, but he turns JavaScript off and then everything still works. So, I think that the same sort of thing can work really well, uh? In quick, that's a great point. Yeah, that might be the approach to think of it kind of server first, I'm also spending a lot of time. We're adding, first class React server component support to Builder, so I'm building the integration out now and works great. Visually. Build everything and zero JavaScript, in the resulting page or whatever you built with Builder, which is really cool. And yeah, spending a lot of time with Shopify's hydrogen framework.

And same deal. A lot of like exploration of that idea of like, everything's really on the server, almost nothing's in the clients. Anyway. I could talk about this forever. David, thank you so much for coming on. This was a blast. Let's keep in touch and integrate all the cool things. And, next stream for anybody who's still watch tuning in. We're thinking about a couple topics in mind. All announces sometime next week, but in the meantime, thanks for tuning in. See you all next time.

Play from 1:04:00