# Coding Complex App Logic, Visually

Canonical: https://davidk.dev/talks/coding-complex-app-logic-visually-renderatl-2022/
Video: https://www.youtube.com/watch?v=fDheg8lQif8
Speaker: David Khourshid (@DavidKPiano), creator of XState
Type: Conference talk · Event: RenderATL 2022 · Year: 2022 · Duration: 15:29 · Views: 256 (as of 2026-10-19)
Topics: Visual modeling

## Summary
You’re not going to want to miss what David had to say at Render 2022. As features and requirements increase, code gets more complicated. Learn about how state machines can manage complexity at scale, in a visual way. Don’t miss what Render is doing next. Make sure you’re following @renderatl for updates!

## Key takeaways (quoted from the transcript)
- The reality is that we do use code loco tools more often than we think. (3:00)
- With the intention of allowing you to code as much as you can visually, but also letting you jump directly into the code. (9:00)
- When you log in, if you have the correct credentials, you know, obviously you should be in the logged in state. (11:00)
- When it comes to balancing abstraction versus complexity, we could see how low code, whether you want to call it low code or visually augmented code, or whatever. (14:00)

## Chapters
- 0:00 Introduction
- 3:00 Code could do everything that loco tools can do…
- 9:00 We have code, we have user stories…

## Transcript
[0:00] All right, awesome, hello everyone. My name is David and I'm going to be talking about coding complex app logic visually and talking about what visually means and how could really help us code all types of apps. So first of all, I want to get one thing out of the way. I have a full name, my name is David Khourshid. It's not David K. piano, it's also not David K. Like you probably saw in the thing, like, there's some missing information here, right?

[0:00] There's like, Where's, you know? It's totally fine, though you could call me David K. My last name's really hard to spell, so David K is totally fine. Now. Let me show you some more missing information this right here. So when we talk about complex app logic, this is actually sort of what I'm talking about. This, this is fine, right? What does is loading equal true? mean? It means, you know, it's loading right now?

[1:00] Let me give you a harder problem. What does is loading equals false mean? Now, some of you, you know, might be a smartest and say, it's not loading, but that's that's partial information, right? Does not loading mean we didn't start loading yet, or we've already loaded? And so if we've loaded the data? Does that mean that we have a success? Or did something fail and we need to load again? Like, what's going on here?

[1:00] What does is loading false mean? And so it really depends on context, right? So, you know, we might have extra variables like is success is error? Notice how both of these are true. When you have boolean variables. Like this tends to happen. And then you get, you know, fun little errors like this, right? Like, don't tell me you haven't seen this before, because I've definitely seen this before. And so we see this manifest in our application in many, many different ways.

[1:00] So, for example, let's say that you're submitting data in a form, right? So when you click on submit, but this might take a while. So you want to add, you know, a, you want to add a loading thing, like a loading spinner, so you add an is loading variable. This is in React. Doesn't matter which framework you're using, the same ideas apply. And so, you know you. Want to hide that loading spinner when you're done submitting the data, and so you know when an error happens, you also want to, like, you want to hide the loading spinner and you want to show the error.

[2:00] But you also want to give them a chance to maybe try submitting again, or you want to add cancellation. And all of a sudden, the logic in your app very, very quickly becomes well complex, and so complex logic is actually really hard to understand. Not just for non-developers, right? Obviously you try to show this to a non-developer like your project manager or designer. They're going to have no idea what's going on, but you try to show this to the rest of your team.

[3:00] They will also have no idea what's going on, unless, of course, you add comments, etc.

[3:00] And then if you ask yourself in a week or two what's going on, you're also going to have no idea. So, you know, logic just gets really complex. And so when I'm talking visually, you know, you might think I'm talking about low code, and so what comes to your mind when you know, we say low code? You might think of things like Wysiwyg editors, or tools that, you know, are really more intended for non-developers than developers.

[3:00] And you know, a lot of you might actually say no thanks, like, why would I use Loco tools? I'm a developer, I, I use code, right? But the reality is that we do use code loco tools more often than we think. In fact, I got started as a developer by using visual basic, like this is where I cut my teeth. I really, really loved using visual basic, I loved making games and small little applications.

[3:00] Just draw, dragging and dropping those buttons onto the screen, editing them visually and being able to simulate that in real time. And I thought that this was like super cutting edge back then. And I look back today and I'm like, I really still wish that we had something like this. How many of you have used visual basic before? Right? Yeah, so that's, that's a good amount of you. Like I, I love visual basics.

[4:00] So other environments like this we have, you know, Macromedia, flash, right? So, and we also had Dreamweaver, which you. Know, we don't talk about Dreamweaver and Frontpage anymore, because, you know, we try not to use that. But it's honestly where I got my start as a web developer it was, it was really, really good. So what do we use now? Well, mostly code, just code. And most of what we really need for websites and web apps are three things.

[4:00] We need some HTML, some CSS and some JavaScript, and of course, that's all hidden from, er, that's, you know, all abstracted away. We have like things like that compiled to JavaScript, and you could write HTML in JavaScript and things that pre-pre-process CSS and things like that. But at the end of the day, it's just these three things. But even so, we still use Loco tools more often than we think. And you know, even back in the day when I was doing.

[5:00] Wordpress sites like Wordpress itself, if we stretch the definition of low code a bit, could be considered a low code tool. But even this, like when you got to a certain point of complexity with Wordpress. I had to dive into the PHP, which was sort of a painful process, and dive into those templates and just edit things to make them look the way I wanted them to look, so they're, um. This is one of the big problems with loco tools, like there's what Loco tools can do, and there's what low code tools.

[5:00] What you need to do. And so then there's what code could do. Code could do everything that loco tools can do, and they could do. Obvious, obviously, everything that you need to do. So it's like, well, the lowest common denominator is code, so why not just write code? There was an article, called the case for developer experience by Jin Yang, and she works at Andreessen Horowitz. And so she writes that. One of the biggest core conflicts between developer tools is abstraction versus complexity, so there's two kinds of developer tools, right?

[6:00] There's tools that make complex things easier, so they are. They hide the complexity, so that's the abstraction category, and then there's tools that explore the complexity. And that's the that's the other side of it. And so when we talk about abstraction, it's a very good thing most of the time, right? From functions in classes to libraries and the tools that we use, these are all examples of abstractions. The problem with abstractions, though, is that they quickly become black boxes.

[6:00] Where if you need to debug something or do anything outside the happy path. These get really complex to work with, and so complexity is important too. Because I really like this quote. Developers work in rainforests, not plant gardens. So that means we don't code in the vacuum. We can't just use nice abstractions all the time, we have to really plug things in together. And so these things might not be compatible, we have to, you know.

[7:00] Use glue and tape and make all of these crazy bridging layers so that we could express everything that we need to do in our software. So, try and go to the next slide. Oops, but yeah, so how do we bridge these two things? Like both, sorry, let me go back here. So yeah, how do we bridge both abstraction and complexity, and how can visual tools help us balance that? Right? So I want to take a look at other industries.

[7:00] I was actually talking to someone who worked around here, where he said he got to start in visual basic and now he uses a bunch of tools for audio, video and things like that. And honestly, I'm envious of that, because in graphics design you have Figma, you have procreates, you have tools like that. And so these tools allow designers to create the most intricate illustrations. And so, yeah, they're really, really cool tools and so same with games.

[8:00] You heard some of this yesterday? There's, there's game development tools like Godot, Unity, Blender, there's CAD, which is computer assisted design tools. Like all of these tools allow game developers and auto mechanics, and just electrical engineers, and just all of these different fields. The ability to do the most complex things in a completely visual interface. Now, of course, you could jump into the code, but code is a part of it, the visuals are another big part of it as well.

[8:00] And so even with websites and apps, we're now seeing a proliferation of more things like, like Framer, we're seeing Clutch, IO, Prismic or Plasmic, just all of these different low code apps.

[9:00] With the intention of allowing you to code as much as you can visually, but also letting you jump directly into the code. So, we have code, right? But one of the biggest problems as a software developer is that code doesn't tell the full story. So we have code, we have user stories, we have user flows that we need to. You know, we need to make sense of. We have mockups from designers, tests, and also at the end of the day, we need to write documentation and tutorials and all of these things.

[9:00] And keeping these all in sync is really, really complicated. So, you know, as soon as you change your code, the tests may fail, so you change your tests. But also the user flows that your designer created might now be out of date, and so the user stories may change. And so, you know the documentation, you know, it might be hard to keep those up to date as well. So this gets compounded even more because we have three main personas in a typical software development team, we have designers, stakeholders like project managers and developers.

[10:00] And so all of these people are sort of fighting to try to communicate with each other and keep all these things in sync. And so, honestly, this is why I love the idea of executable models now. An executable model is basically a visual formalism. So it's a visual diagram, such as statecharts you see up here, which are extended versions of state machines and BPMN. So what these are? They're visual depictions of things, so they're diagrams, but they're they're diagrams that are actually useful because they work.

[10:00] Like, you could take this and you could translate it directly into code, and so that's what I, you know, I started researching this about like seven years ago when I found it absolutely magical that I could draw something. And it actually, it actually converted right to code. Some of you might be thinking that I'm talking about UML, like, Omg, is he really talking about UML right now? And I'm going to say, not exactly.

[11:00] And that's because UML is a little bit too rigid and it tries to formalize absolutely everything. So I'm not talking about UML specifically, instead, I'm talking about this. So this is. A basic state machine where you're in one state, logged out. And so when you log in, if you have the correct credentials, you know, obviously you should be in the logged in state. And then from there you could log out. You could do different things, but this comes from user stories, so we could translate this to user stories.

[11:00] Like, given the user is logged out, when the user logs in with the correct credentials, then the user should be logged in. And then we could take that diagram and we could refine it even further. So correct credentials, we could say all right, the developer is going to make an API call somewhere. Initiate an OAuTh flow, do all of this authentication stuff and actually provide the implementation for what correct credentials means, right?

[12:00] And so because of this, and this is what really, really, makes me so passionate about state machines and statecharts and all these visual formalisms. Is that, all of these three personas that we talked about now? They could share a common language so they could all talk to each other and share these diagrams and these diagrams. We could ensure that they don't go out dates now. This is part of the big reason why I created this library, called XState.

[12:00] It started as a state management library, it's more of a state orchestration library. Works with any framework, and you could see some of the code on the left side over there. I don't expect you to read this because you know it's. The code is small, but this code translates to this diagram. And so this diagram is something that you could share and you could simulate, and you could generate tests from it.

[13:00] And this is also a diagram that is, like, hopefully, easier to understand than the actual code itself. So for much of the time I've been working with XState, we've been taking that code that, you know, you saw in X8 and converting it to a diagram. But I really wanted to explore how we could actually go the other way around, creating a diagram and making it convertible to code. And maybe doing both at the same time.

[13:00] Now I don't have enough time for a full demo, but I do have this video over here, which is probably. Really hard to see, but on the left side you see code, and on the right side, hopefully. You see the diagram actually updating as I'm editing the code, and then while I'm editing the diagram, the code is updated as well. So this is the, uh. This is called the Stately editor, and so if you go to Stately..ai editor, you could start playing around with it.

[14:00] Today if you go to Stately..ai, there's so much more information. We also have a VS code extension, so you could, you know, you could do these things now. The editor. I don't want this to just be for XState, eventually, I want it to be for any state management library. Or if you just want to create flows like user flows, flowcharts, whatever you want for your application. I just really want to encourage this level of visual programming to just make our complex logic a lot easier to understand.

[14:00] And so with X8 itself, we have a ton of things planned. Please find me after my talk and I'll be more than happy to talk your ear out about all of them. So when it comes to balancing abstraction versus complexity, we could see how low code, whether you want to call it low code or visually augmented code, or whatever. We could see how these kinds of visual interfaces really, really help. And so that's why low code is more like pro code.

[15:00] Because we're enhancing the code that we're already writing, and we're using visual tools to make your code do more so with that. Thank you so much. Render ATL [Applause].