Code with Jason
Code with Jason
273 - Steve Ruiz, Founder of tldraw
In this episode I talk with Steve Ruiz about creating TLDraw, an open-source canvas SDK. We discuss the intersection of design and engineering, managing complexity through abstractions, state machines, and how multiple rewrites helped him discover the core problems. Steve shares insights on building developer tools and solving difficult UI challenges.
Links:
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says, thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says, Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says, just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsensemonthly dot com. That's nonsensemonthly dot com. I'll say it one more time nonsense monthly dot com. And now without further ado, here is today's episode. Steve, welcome. Hey, thanks. Um so you created something called TLDraw, um, which is a whiteboard type thing. But tell us about TL draw. What is that?
SPEAKER_00:Yeah, so TLDraw uh right now is a SDK that developers can use to build whiteboards or whiteboard-like products. Anything that really uses a infinite canvas or infinite canvas as like the user paradigm. So I think like you know, design tools, workflow tools, uh collaborative whiteboards, that type of thing. Um, we also have a we build things with the SDK ourselves. So we build essentially a glorified demo of the SDK at tealdraw.com, but it's also like a really good free multiplayer whiteboard. Uh if you if you're familiar with Excalibra, it's a lot like Excalibur. And then we also have more kind of experimental stuff that we built on top of TealDraw as well. Things like Make Real, which is this whole make a drawing of a user interface and have an AI create a uh working prototype based on that UI. That was really, really viral in like the end of 2023, actually, which is crazy how early that was. Uh then like last year we did something with Google to call TealDraw Computer, which is again like a kind of a product that we built with our own SDK, where you could kind of connect uh boxes and flowcharts and do this branching cycling uh AI thing on the canvas where you say come up with a story, okay, like you know, do an outline of the story, all right, create images for all the scenes in the story, uh, you know, repeat until the the story is complete and do things like that. It was it's pretty far out, but it's uh yeah, it was a blast. And uh yeah, we're still doing things like that, building on top of it, but uh the the core of it is always like this SDK, like you have a canvas, really, really tough piece of UI to build, it's done for you. Like, what do you want to do with it?
SPEAKER_01:And um yeah, okay, interesting. Um, and I can't help but be curious uh how you came to create this thing, like what made you want to do this?
SPEAKER_00:Yeah, right on. So my background is in uh design as like a I guess product designer, and uh I then I worked in design tools after that. So I worked for a company called Framer doing their design education, and then with a company called Play, just as a product designer. That was you know, COVID time, so I had a little bit of uh extra time as well, and you know, was doing open source around design tools and creative tools in generally, or in general. So uh one of the open source projects was like had to do with arrows, another open source project had to do with uh digital ink, like kind of pressure-sensitive variable width lines. Um, those are perfect arrows and perfect freehand uh respectively. And then yeah, I built a couple of other projects that just started kind of creeping towards like the kind of the canvas as like a paradigm. And every time that I did them, I would learn a little bit more about how to do one of these these applications. And also I saw like how much of the work was like repetitive or repeated. So uh yeah, just where the undifferentiated parts of a canvas are, um, the parts that are the same between every every app that uses this type of paradigm. And so in like 2021, I started building like just that as an uh open source library of saying like here's like something close to a excuse, something close to a uh game engine almost, right? Um for for managing like a canvas with pluggable uh primitives. So if you wanted to add new primitives on the canvas, you could do that. If you wanted to control it programmatically, you could do that.
SPEAKER_01:Um and sorry, was this just for fun or did you have an in-game in mind? What what was the thought there?
SPEAKER_00:I think at the time uh I had my only goal was like Twitter followers. Um you know I started taking sponsorship around Teal Draw, and that was that was fun, but it was really more like I'm really fascinated by creative tools. Uh I I wanted to work in this area, I wanted to there it was such an underinvested in product category also, and like full of really hard problems that just had no solutions uh or had no open source solutions specifically. Things like digital ink, um, where even even the the you know closed source, like product um uh proprietary solutions to this, I felt were like really bad. And I was like, oh, this is a great place for me to plug in. You know, I have the technical skill, but I also have the design sensibility and you know the the I even have a background in in fine art. I've spent my 10,000 hours working with and looking at ink. I could be the guy who who does the um the digital ink for for software and handwriting tools and things like that. Uh and I was posting a lot about my work on Twitter as I was as I was doing it. So it was a way of kind of building a following and building like a community around these these problems. And then yeah, once I started opening it up to sponsors, then it also kind of became like you know, content-driven development where the content that I was producing was attracting sponsors who were funding the development of it and kind of allowing me to focus more and more on it. Interesting. Why did the sponsors want sponsor because they liked me at first. Um and then uh after that, well, this was with Teal Draw, so like May of uh 2021, where um I'd built enough of this open source engine for for canvas to to um have like a demo that people could play with. But I made that demo, I set it up in a way where if you wanted to use the demo, you had to be a sponsor of me on GitHub. GitHub had sponsors had just come out in 2021, so yeah, it didn't matter how much you could you could sponsor me for like a dollar and you know as a one-off payment, but you know, that would put you on a list that I would essentially be programmatically like whitelisting so that people could create accounts and access tail draw. I mean, the majority of folks would were seeing me work on this project, and like or at least the folks that I talked to, like were seeing me work on this project and really wanted to support the you know cool Twitter threads that I was making about how rotation works in apps like Figma and Sketch and others. Got it.
SPEAKER_01:So it wasn't necessarily like high dollar corporate sponsorships. Maybe that was there too, for all I know, but it was like individuals sponsoring you because they were interested in the tool and that kind of thing.
SPEAKER_00:That's how it started. The the corporate money did follow. Um, so this was again like a project that really kicked off in like March 2021. By the end of 2021, I I think I'd had almost$200,000 worth of sponsorship between individuals and corporations. Um, and these are corporations that wanted to build with Deal Draw, as well as like corporations that like uh you know would have hired me or acquired me if there was a company to acquire if I was open to hiring, but I uh uh I wasn't. And so I was like, yeah, like help me stay unemployed, essentially. Help me develop this thing. Uh I mean it's in public, you can read my code, it'll be a good resource for your team who's solving some of these same problems. Possibly you'll adopt it in the future uh as a technology for your product as well. Like if it is like if I if I do my job right and if it's good. Um and yeah, just in general, like it was a pretty well-validated idea for a thing that should exist. Like by the end of 2021, I was like, okay, this is either I'm gonna do it or someone else is gonna do it, but there needs to be an open source or there needs to be something that a team can buy if they want to build something like this. Like if they want to build, okay, it's gonna be Figma, but it's gonna be like my AWS dashboards on it, and I need to be able to interact with it and all that stuff. Uh, like that team is not going to want to also solve all the weird linear algebra problems involved in like stacking transforms against each other and like uh you know managing a scene graph and all this stuff. They just want to build their their cool idea, which is like on top of this thing. Yeah.
SPEAKER_01:And uh interesting. So there are about 25 completely unrelated questions that I desperately want to ask you, but I'm gonna have to narrow the scope. Um, I I'm I'm really interested in people like you because I feel like I am kind of cut from the same cloth. And and what I mean is I don't know if you happen to have have read that um Walter Isaacson Steve Jobs biography, but he he talks about in that book, he talks about kind of the the marriage of art and engineering or or whatever you want to call it, um, where Apple is an excellent example of of that kind of mix where there's very high quality engineering and very thoughtful design as well. Um and and you know that puts me in mind of of other people like um Leonardo da Vinci, who was an engineer and not only so he was an engineer and one of the most accomplished artists of all time, um, which is a fascinating combination to me. And then people like Benjamin Franklin, who was a a scientist and a statesman and an inventor and and a writer, and and bringing together these disparate disciplines to create something that that could never have been created just inside of one of those disciplines alone. Like if you take Google, for example, Google is good with like numbers and stuff, but no offense, Google, their taste is very poor. Um and then there's there's of course tons of people who have amazing artistic ability, uh, but they don't have that engineering mind also.
SPEAKER_00:But it sounds like you uh you mix both I think the well, I mean I'll definitely take the Leonardo da Vinci and uh Jeffrey uh uh same breadth. Um I think I mean when I studied art, you know, when I did my master's and you know, got my MFA and all that, like um, you know, my my skill was was painting. Like the things that I was producing was were painting and drawing. But uh, you know, the the the thing you learn maybe at art school, or that I hope you learn at art school, I hope you would, um, is that like if you have an idea, if you have something that you want to put into the world, just you can do that. And that the world is a thing for you to put things into, like um that that you know, whether that's that's culture or or or politics or anything like that, that is that is those are made things, those are uh things that that people did, right? And and you're people and you you're you have full permission to like go off and like put something new into the world. Um and if the only thing standing between you and and and a world that includes whatever you want it to include is is like learning something, like that's easy. Learn it, right? Like uh I think in the in the same way that I having now done the whole startup thing, like often the thing that's standing between you and you know some ideas just like capital, right? Like uh uh and and in a way, like that is uh this is probably coming from a very privileged position now, but like that that's kind of like the the easier part of it, right? Is like just you know finding the the the the necessary things in order to to execute against some sort of vision, right? Um I think the the harder thing is just being able to enter into some sort of feedback loop that allows you to know what is a good idea or like what it what is wanted and needed, and that like if you boil down things like YC or other accelerators or other kind of like all the startup books that you'll ever ever read is really just like uh here's how to find out if what you are doing is something that people want, and if it's not, like how to adjust it to be something that people want. Um, I kind of got lucky in in tech that the the things that I was interested in pursuing, the um the problems that like attracted me also happened to be um number one, like desired, like other people needed those same problems uh to be solved for them, uh timely, in that like no one else had solved them, and that this was like in my case, like kind of collaborative whiteboards, were we're having a moment, and collaborative software was having a moment, and suddenly there were a lot of other things that unlocked um you know, the product category in a way where the the blocker was just the canvas, it wasn't the multiplayer technology, it wasn't the you know, browsers are fast enough to do this anymore, those types of things. Um and because I guess I was doing this in public a lot, uh, you know, and it had partnerships with said large corporations that were sponsors, like it was it was really easy to validate whether like uh what I was building was the right thing, and and to to have such contact, so much surface area with um with other people through Twitter and other other things, so that um yeah, I could be could be building the thing that that that that folks wanted um and needed. I think the you know, again, kind of startup culture founder mythos or whatever you'll hear about like founder product fit of like like is this really the thing that um you know or is this person really the person to be solving you know self-driving cars, or is this person really the person to be solving, you know, like uh uh uh uh reusable, you know, whatever. Uh and you know, it it's a legitimate question, you know, and then I think there does need to be a correspondence between the person and the problem that they they work on. But I uh I think in my case it was it happened so organically that that that that fit in retrospect seems seems very very close. Like, oh yeah, wow, uh design background, art background, working on design tools, uh also was like interested in open source, and that's just exactly the thing that needed or was needed, or something like that. Uh, but it it really just happened very, very stepwise, very uh one one bit at a time. And I was lucky that it, you know, the things that I do seem to matter to people.
SPEAKER_01:Interesting. Um yeah, there's so much to dig into there. Um, I myself have like cycled through a whole bunch of different startup ideas, if if startup is the word. Um a great example of something that wasn't a good fit was that I built scheduling software for hair salons. Um, and and I'm not like I don't care about hair salons at all. Uh no offense to all the stylists listening to this episode.
SPEAKER_00:How did you end up doing that?
SPEAKER_01:Like, I just gotta know like what my wife got a job at a hair salon um originally as like a receptionist and then as a manager, um, and I noticed that their software was really poor, and I looked at the um and and I was already like seeking ideas for a business to start. I noticed their software was really poor, and I looked at the competition and I'm like, wow, this is all pretty bad. Um, I think I can make something better than this, and so then I set to work making something that I thought was better. Um, and I did a bunch of uh door-to-door sales and got some salons to use it. Not very many. The my peak was like 10 salons using it. Um but I learned through that, I I could talk for hours about this, but I I learned through that that um it just just having something that's better is not enough. Um you you have to have sales channels in a in a way to reach the people who are gonna buy your thing. Um and if there's a product category where literally all of the options are poor, maybe that's a sign that there is some natural immutable force that is causing things to be that way, and it's a red flag that you should pay attention to. Um and in this case, what I mean is like it's it's just not a very good market, you know.
SPEAKER_00:It's it's like I was gonna say, like, just if if the margins are like razor thin anyway, then it's it's kind of a race to the bottom. And yeah, if if like a bad piece of software is good enough, you know, like that that's a really hard thing to compete against.
SPEAKER_01:Um, exactly. It it superficially looks like a B2B market, but effectively it's B2C because the um the the customers think in a consumer way and they have consumer levels of money usually.
SPEAKER_00:Which is to say not much.
SPEAKER_01:Yeah, exactly. It's like, ooh, 30 bucks a month. I gotta think about that. It's like fuck. Um so that that wasn't good. Um, and now um I'll just briefly mention um I'm I'm working on a CI product. It's like a competitor to Circle CI or GitHub Actions, that kind of thing. And that's a much better fit for me. Um for because I have a background in testing and stuff like that, and I have an audience that's related. I don't have to drive around and walk into salons and and try to whatever. It's it's much different. Um, and obviously it sounds like you're I I don't know if you had ideas that you had gone through before, but this particular thing obviously worked.
SPEAKER_00:I think the I definitely did. I mean, projects that I'd worked on before, for example, uh I I got really into uh uh state charts. I don't know if you've ever ever fallen into the kind of the X state or or essentially nested state machines type of uh type of world, but it's uh it's a deep one. Um but what what's fun is it's uh it's visualizable. You can create graphs that sort of represent the various states that your application can be in. Uh, and then you can kind of visualize a particular state, right? Like the user is logged in, the user has a menu open, the user is dark mode on, the user is hovering this item, etc. Right. Uh and you can you can kind of move between those states um uh as as movements within like a graph. You know, this event is gonna happen, that's gonna move to this other you know, active state, different part of the tree that's gonna be um can be active. And it's uh it's a very technical thing, but it's also a uh incredibly good way of making like really robust software because you everything is like finite, you know all the possible states, and you know like the events that can transition between those states. I'm going really technically deep on this, but like uh yeah, it's used in like I don't know, phone software or health, you know, things where like we we just need to make sure that we can uh almost like mathematically prove that this won't explode if someone pushes this button when it's in the wrong, you know, when it's not in the the launch pad is not ready or something like that, right? Uh but I loved it because it was uh within a design conversation, like I've I've designed or I've built this prototype, uh, which is what I used to do a lot when I was in in product design. Now I want to talk about it and I want to like discuss this this prototype with the engineering team. Um you know, software is complicated, and you know, how something works, as much as we'd like to talk about how like you know the design is not just what it looks like, but also like how it works. Like, well, it's really hard to communicate how it works. It's a lot easier to communicate like how it looks. Um and and this type of state chart gave me a way of a four formal way of like expressing the the how does it work. So I yeah, I built a whole uh like micro application around just that problem of of like defining your kind of like your your your states and then also having an interactive visual graph that that shows the current state and the like what's gonna happen when this event happens and all that stuff. It's called State Designer. It's still online if you want to try it. It's uh really fun. Okay, but uh like app.statedesigner.com, I think. Interesting.
SPEAKER_01:Um I'm I'm reading between the lines a little bit, so tell me if I'm interpreting this in in a way that makes sense. Um, but it sounds to me like you're making a fairly conscious distinction, which I'm in my experience is not a very common distinction, between the like conceptual essence of what something is and how it works, and the like code implementation of it. Uh something something that I say a lot is that a software system is made out of code only in a like superficial way. It's really made out of ideas, and a code is just an expression of those ideas. And if your ideas are coherent and elegant and stuff like that, then the code can be too. But if your ideas are incoherent and inconsistent and stuff like that, then nothing can make your code good because the code is downstream of the ideas. But that's something that that's a rare distinction. It's usually like, oh, there's there's this bug. Let's uh add yet another conditional to deal with this scenario, whereas maybe what they should do is back up and be like, hang on, what are all the possible states that this thing can be in? Does this design of this code is this in harmony with with all those states and maybe blah blah blah? Um am I kind of picking that up right?
SPEAKER_00:Yeah, 100%. I mean, like the the argument within the uh the the the purists or the the state chart community or or whatever the the state machines people is that like you know every application kind of implicitly has this type of thing. Like uh, you know, if you are creating a React component and you have some sort of like, you know, is loading, you know, like parameter like variable or or something like that, some state is loading, is you know, is error or something like that. Uh some little Boolean flag or something. You're kind of just implicitly just defining a state chart anyway, right? Uh it's just not going to enforce anything. So, like, oh, why can the user log out if they're already logged out? You know, um, either you plug that little like if if user is logged out, then ignore this event type of thing, or you come up with like a system where that can be that incorporates that, where like that would never be possible because the system doesn't allow it, because you haven't you know enumerated the events that this state can respond to, or something like that. I just uh oh yeah, sorry, go on.
SPEAKER_01:Uh I was just gonna say I had a brilliant thought just now. Um okay, so in in programming we talk about the idea of elegance sometimes. Um and and I think this came up on a recent podcast episode of mine. Um, but like I I think an idea is is elegant or a design is elegant um when the ratio of of uh well when the when the solution to a problem is this isn't a very elegant definition of elegance, but when when the when the the the simpler the solution to a problem is that answers the problem just as well, the more elegant it is. Um and then and then that that was a thought that I already had, but the new thought that I had just now is I think elegance is the lack of incidental complexity. And if if anybody's not familiar with that term of incidental complexity, that's like complexity be beyond what's necessary, like what you were talking about, where instead of having these thought-out states and having a design that kind of reflects those states, you just have these conditionals like if the user is already logged out, blah blah blah. Um but I I I like that realization if it's in fact true that elegance is the absence of incidental complexity.
SPEAKER_00:I think the I I I could track that. Yeah. Uh I mean I we use this same sort of like state node pattern in in Teal draw in in the in the canvas all the time because the uh we have no choice. Yeah, because like the uh when you think about it, a canvas only has like a couple of inputs. It's not like users are clicking on certain buttons in order to to advance the state of the app, they're just moving their mouse. Clicking and like releasing that click uh and occasionally pressing a modifier key, but that's pretty much it. Like, and those are the only events, you know, sometimes for minutes long that that you're sending to this system, right? They're just clicking and dragging, clicking and dragging, or clicking, clicking, uh, you know, and if we were handling those in a way that was like naive, there would be a massive switch statement, you know, on on the click handler to say, like, look, if did the user uh previously click on a selected shape, you know, and like uh are they in the the the middle of uh uh dragging something around, but also are they holding the option key? Because in that case, then they're they're duplicating that object, blah, blah, blah. Like it's just incredibly overloaded, these few interactions that the user can do. And so, you know, using this kind of uh tree of possible states of like, okay, what tool you know is selected, are they in in the idle state? Have they already started pointing on the canvas, or have they started pointing on another shape, you know, all of that type of thing, and and allows you to handle those uh those events in a way that it's like can actually be programmed uh rather than like like way overloaded or just just you know mentally impossible to do. And I and trust me, I've tried it every every way there is. Um and so yeah, when the like with this in particular, like you know, you you just get used to it so so quickly, not having to guard against these external you know situations of like whether the you know the user has started their click on a on a shape or the canvas or part of the UI because like you know that the system is already narrowing that. Yeah, what you're writing is only gonna run in that path where that's the case or something.
SPEAKER_01:Yeah, I I I think I'm really understanding what you're saying. Um you know, in in that famous book uh Code Complete by Steve McConnell, he he mentions how programming is all about managing complexity. Um and and there's like there's too much complex complexity for a human brain, you know, like even though you wrote TL draw, like I bet that if I put you at a random spot in the TL draw code base, like you'd probably have to take a second and like refamiliarize yourself with that area. Um and so there's just like again, the complexity of any system well exceeds like our our what we can store in our heads. And so what we have to do, and tell me if this is consistent with how you think about it, is we have to create abstractions, and and this is a concept I've been talking about a lot on the show lately, and it's a very um widely misunderstood concept. Um, a lot of programmers think about an abstraction as something that is generalized um for reusability or something like that, but to me that's not what that's about necessarily. Um it's it's about uh replacing low-level information with higher level information in order to make something easier to understand. Because again, I'm I'm I'm guessing, but I'm guessing there are various layers of the TL draw system which would be hard to understand if you tried to meet them at the low-level detail uh layer. But if you can put constructs on top of those and say, here's such and such layer, we're just gonna interface with this at a highly abstracted level, and we're gonna compose this system out of a relatively small amount of relatively high level of abstraction, then the whole thing becomes tractable, and like you said, it's it becomes something you can actually program because if you didn't have those abstractions, it would just be it would just be too much. Does that is that consistent with with how you think about it?
SPEAKER_00:Yeah, I mean that that tracks as well. I especially since TealDraw is not just an application, but it is a uh um an SDK. Like I expect other people to be building things with you know the this the software that I've made. Um and yeah, so the things like um this is a this is a shape, or this is an element, or this is a tool. Um, and making sure that those things are as consistent as possible in in the behavior that they encapsulate, so that you can just trust that they're gonna work, right? And like just trust that that you're able to think about that abstraction without thinking about what's inside of it. Um I think every abstraction is you know, whatever, leaky. I think that's a you know, you just have to uh assume that, but you know, you can you can increase the kind of the uptime of the abstraction, you can increase the the how you know the how how long can can this last without having to remember that this is wrapping up so much other behavior. Uh and that's um yeah, yeah, yeah.
SPEAKER_01:And I think the concept of modularity comes into the picture here, um, because the the the less that two uh uh entities are dependent on one another, and and to the extent that they can be considered independently from one another, the easier they'll be to understand and work with.
SPEAKER_00:Yeah. That sounds yeah, that that tracks as well. Yeah. Uh I think the a good pressure test on this uh for me was always like writing about what I was working on, what I was building. Uh and you and you, you know, sometimes it's when you're writing docs, you know, and then having to like like I without fail, I would always write something that sounded like um let me try and come up with an example. Uh to uh something like uh the to open and close the door, use the portal inverter or something. And you're like, uh-huh. All right, no, rewrite it, go back to my code F12, like you know, and then then come back to my docs and be like, uh to open and close the door, use the door open closer. Like, like use the just name it the thing that you would describe it as. Uh, and and just even just with naming and stuff, like uh, you know, that's just something that I still tell, like have to check myself on, but like I'll I'll I'll write it or I'll I'll explain it, and I'll somehow always format it in this way of like uh the X, you know, you can think of X as Y. And then I'm like, well, you know what? Let me just let me just rename it to Y to begin with, right? Let me just orien like architect this thing around the way that I would describe it so that it's it's just more self-describing. Uh Childrop was great because I was building that on Twitter, and so I was just constantly tweeting about both the design of the product, but also the design of the AI. Uh and so and like making like educational threads on it and all that stuff, and like uh just having to expose it would was so like almost every thread that I was making on Twitter in 2021 as I was putting this thing together, like would cause me to majorly refactor whatever I was building just because I was like like, well, I can't say this, like I can't show this code. Like, this is obviously like like this is this is obviously wrong. Like I can tell that this is a bad abstraction, like as I'm as I'm doing this.
SPEAKER_01:Yeah, it's so interesting how just like it's so interesting how articulating something to another person or even to yourself um reveals uh questionable ideas. Um like I was giving a demo of my product to somebody recently and I showed them something called the overview page, and they're like, overview? Why is it called overview? And I'm like, well, because uh wait, why is it called overview? Yes, it's not overview.
SPEAKER_00:Like I, you know, I was it was gonna be an overview page when I made it, but like, yeah, that's uh happens all the time. I uh I've had the luck uh to be able to rewrite tail draw from scratch like multiple times, um, which is is normally in software like a very bad idea, and you know, maybe it was for me as well, but um, you know, the because it is an SDK, because the code itself actually is gonna be like is the product, and you know, um then you know we we I I would write it and then I would like use it enough and and hand it to people and have them use it enough to be like, all right, now I understand the problem. Now I fully understand the problem. Now let me create the next version with my full understanding, and then that version would get used by me and by other people, and then like I would say, oh no, no, no, now I understand the problem. You know, let me start over again with this and design it for that problem. And uh, we're probably do another rewrite after uh, but it it took about four full rewrites before it was uh um like I felt well before like we could before it stabilized, before I felt like the the choices that we made um were like robust and and like could could it really capture most of the use cases that that people were using.
SPEAKER_01:Yeah, man, there there's this book that I've been mentioning on like every episode of this show, The Beginning of Infinity by David Deutsch. Um and and this is tracking with so many of the ideas from that book. So he talks about um how how science and knowledge creation is all about explanations. Um there's there's this kind of idea of a Bayesian epistemology where the sun has risen a bazillion times in the past, that's how we know that the sun will rise tomorrow. Um but that's like not a valid way of gaining knowledge. That's not why we know that the sun will rise tomorrow. The the reason we know is because we have an explanation for how the solar system works. It has nothing to do with how many times something has happened in the past and stuff like that. Um and something he says about good explanations is that they are hard to vary. Um uses an example of like ancient myths for like the reasons why we have seasons and stuff like that. Like uh there's there's some god that got uh his lover um ignored him, and so he went away, and when he went away, everything got cold and stuff like that, and that happens every year. Um that's a bad explanation, and that explanation can be varied almost infinitely. Um, and that's kind of a clue that it's a bad explanation, but the explanation that it's it's the tilt of the earth, um, and and that's why we have seasons, um, that's a very hard to vary explanation. You can't really fiddle with that and have everything still make sense. Um and th this has so many so many parallels or applications. And in in in your instance where you've rewritten this from scratch three times, um the way I interpret that is you have come up with with um increasingly better explanations, and it's not literally an explanation, but it's it's like the same idea, um, where there's kind of one right answer. Um and it took you multiple tries to arrive at that right answer where to tell me if this guess is correct. I'm guessing that these like right answers are hard to vary. Like if you had done it a little bit differently, it wouldn't have fit. The solution wouldn't have fit into the problem because the solution and problem are like very detailed puzzle pieces where the the solution has to fit this problem just so. That's a guess. I could be totally off though. No, no, no.
SPEAKER_00:I think uh so there's there's two places like good examples of of what changed between these big big rewrites and revisions. Um one what what what it often is is like multiple problems that all independently feel like the same problem, uh, and that all kind of suggest different solutions, uh, until there's an enough material and enough problems. Excuse me, the oxygen in this room is so terrible you're gonna have to cut this. Uh it's like a coffin. Uh multiple problems that that all feel like independent problems until you've seen them enough, and then you realize, oh my god, these are actually all part of the same problem. It's just that that that problem is is bigger than I thought. So a good example of this was you know, a canvas is full of a lot of reactive data that that depends on other reactive data. So the you know, the the normal thing is like you have nested shapes or nested elements on the canvas, and each canvas can have a uh uh rotation, and so the the the final absolute rotation of a shape depends on the transforms and the rotations of all of its parents, right? Because you know start from the origin of the canvas and then this and this is this, and then finally you have the the the position of the shape itself. Um, and you can't find that where do I put this shape on the canvas on the screen without also knowing all of those those uh those those other positions. Uh however, uh you don't want to be checking the entire tree every time that you you render this stuff. You need to have essentially a cached value which is stable but which would be invalidated have if any of its dependents change. Uh and then you also have multiplayer. You have a collaboration, which is something that you can do with TealDraw, that we have a solution for. Um, and where you need to be sending diffs uh of what has changed to a to a server and distributing those diffs uh to to all of your your connected peers. Uh those feel like the very different problems, right? One has to do with uh a complicated client state, the other has to do with um uh a distributed state. But what we found eventually was that actually the solution to both of those things is the same solution. Um and and uh that solution is very complex. Uh and believe it or not, there were other things as well regarding performance and um and and places in the code base that that needed to be solved, and we're like, oh no, no, this is also part of that same uh that same problem, and that um you know was not immediately obvious. And we could have had a bigger team solving each one of those problems separately and trying to mesh all those solutions together. But the the benefit of the state, I suppose, that we were in, or the the level of development uh that we were in with Teal Draw at the time that we kind of had this lightning moment of like, oh no, no, this is all part of the same problem, was that we could throw out the whole code base and start over, like rip out the entire client side and multiplayer and all this stuff, and and come up with an architecture that um you know used this kind of incremental diff-based signals uh library that that was reactive in this this way that also worked with multiplayer and like wonderful. We couldn't have done that de novo, like we wouldn't have thought of that as a de novo, like you know, it was not immediately obvious. This is the type of problem that you you hit after you know six months, or in my case, like a year and a half of working on a problem. Um but boy, I'm I'm happy that we were in a position to really solve it because that's such a robust system that we have for teal draw. Um, and that enables the type of like you know everything in teal draw was is really glued together and and and and you know solved using using that same problem solution, right? Like uh and yeah, that's uh it was a it was a solution to the problem that it was not even evident that it was a single problem, but it just really felt like so many different ones. And developing a theory of yeah, develop developing even even just developing the theory of the problem was like half of the problem, and that just we had to expose ourselves to the whole thing for months and we're to just yeah, yeah.
SPEAKER_01:Um, okay, there's there's something that I've been wanting to bring up for uh a long time during this episode, uh, which is it it it it has something to do with what I've been thinking uh uh up to last night, and then I read something that was a really weird coincidence, but um I've been thinking about like research versus creativity. Um and I've thought for many years, like so many organizations, software teams will like have teams get together and do these brainstorming sessions. And uh it has always driven me nuts because like you just get a bunch of people together who don't have all that deep of understanding of the problem, and they're just like, what if we do this? And you make a big list of all these ideas, and it's like, guys, this is like not the way to approach anything. Um and yet it's so popular, it's it's very frustrating to me. Um and what I think people do a lot less of that I wish they do more, is just researching the existing uh ideas in that area, because so many I so so many uh problems that we encounter in software are not novel. Um on some level they've been encountered before, and there are existing solutions. Um and even if even if the problem is, you know, in a sense at the same time, all of our problems are novel, but they're usually like some novel composition of existing problems that have been solved before. Um and then the thing that I read last night was it it used the words analysis and synth synthesis. Um you know, analysis means to break down, synthesis means to put together. And so what I realized is people are trying to do way too much synthesis before they do enough analysis. Um and it sounds to me like your your journey in TL draw has forced you to do a lot of analysis. Um again, I'm reading between the lines, but uh you know, you run into these problems, and maybe you thought to yourself, okay, I have this problem. What is this problem? What what is going on? And then maybe that made you realize you need to study linear algebra or or something like that, and then bring those things back. And to me, it's like a a good 90% analysis, 10% synthesis, even if that, you know, maybe it's like 99.1 or something like that. Um, but but does does that idea resonate with you at all?
SPEAKER_00:Yeah, I think so. The I mean there's there's kind of two things, right? There's knowing that you learn about your problem space as you kind of work within it, and there's no no avoiding that, right? Like the you're just gonna have a deeper understanding of the problem that you're trying to solve, and yet you're you're supposed to be creating solutions for your current understanding of the problem, right? Like there's no way to you know know what you don't know until you you run into it, right? Uh and of course, software itself is like hard to change um in a lot of cases, so often you just build up this kind of legacy system that's built on a pre previous understanding of a problem, but that's the one you have, so you kind of just have to improve it if you can or stick with it. Um I think everyone dreams of just re- restarting something, rewriting it from scratch. Uh I think with I guess with my journey with with Teal Draw and with you know perfect freehand and these other things before that, um I had no choice but to just uh well like just learn quite a lot because my own like technical skill set was wasn't deep and and these projects didn't emerge from me connecting you know things that I I'd learned. It was uh it was much more aspirational. It was like, I want to have this experience, let me let me figure out a way to make it. And so for for ink, like I I think the you know, I had a stylus, I had the you know, a little drawing tool that I'd made. I'm like, I know my stylus does pressure. How do I make my the thing that I'm drawing uh use the pressure that I know that the stylus can can do, right? Uh and just rabbit holing into that and learning learning all the things that I needed to do in order to make that.
SPEAKER_01:Yeah, I'm guessing there's like layers of either you know what you don't know or you don't know what you don't know, but you know that you don't know what you don't know.
SPEAKER_00:And that the whole uh Ashcroft uh yeah. Yeah. Uh I I think what it is is like a deep belief that this must be possible. Um you know, that like like I I've seen this before somewhere. Like this you gotta be able to do this, right? I I think uh a great example of this is uh in so one of the the great stories of the development of like the Mac um, you know, the first windowed Mac software. There was uh um you know, they they had they had seen uh Steve Wozniak had I think no, damn it. Uh one of the the Apple engineers had gotten a demo uh at Xerox Park uh of the the windowed system that they had been building. And uh, you know, one of the Apple engineers just spent so much time working on this problem of like, you know, efficiently kind of uh masking different windows in front of in front of other windows. And you know, been like, you know, this must be a way to do this efficiently so that you don't have to repaint things that that don't need to be repainted. Because I've like I saw it at that Xerox demo, like I saw it, I remember seeing this. You know, they figured it out. There must be a way to figure it out. And and sure enough, uh, you know, he did and and uh he cracked it and it was this you know great moment for the the software. And only afterwards did he learn that that Xerox had faked that, that that that they they hadn't actually solved the problem, uh, and that this was a completely original solution to an to a problem that had just never been solved before. Uh and I think the thing that uh had he not believed that this was possible, had he not falsely like assumed that or or presumed it, like he had seen the evidence that this was possible, I don't think he would have finished it. I don't think he would have built on it. So yeah, it's uh you know, sometimes that's uh yeah, that's half of the half of the problem as well.
SPEAKER_01:Um yeah, I I found that it's like you you can you can solve a problem so much more quickly and easily when you believe that the problem has a solution. It's like you know, if you like lose your keys or something, it it's way different if you know for a fact that the keys are in the room where you're looking, or if if they might not be there and they could be anywhere, it's a it's a very different endeavor. Um yeah, and that that brings to mind like um Henry Ford had this certain thing that he wanted to achieve, but I don't I don't know about cars enough to to know the thing, but he wanted to make like an engine block out of a single piece of metal. It was something like that. Um, and all of his engineers said, like, no, like that's that's just not realistic, that's not possible. And he's like, Yeah, I I know you think that, but like that's what I want you to do, and that's the only thing that you're allowed to work on if you if you want to keep working at Ford. Um and they just like kept working on it for like months and months and months, um, and finally they did it. Um, and I'm reading this Elon Musk biography, and I don't know, the the the Tesla battery pack, one of his engineers said that it was gonna have 8,400 cells, and he's like, that's too much, uh do it with 7200. And he's like, no, that's like no, that doesn't make any sense. But then sure enough, sometime later, um, he was able to get it down to 7200. Um and so I I don't think there's something like supernatural there or something like that, but again, there's there's a significant meaningful difference when you when you believe that it's solvable.
SPEAKER_00:Yeah, yeah, 100%. I think the the and you know, there's counterexamples as well, like from the same team at at Apple, like Steve Jobs had like really obsessed about like this low memory requirement in like the first Apple Macintosh. And that was just that was just the wrong idea. Like there should have been more, and they added it immediately afterwards on the second revision. Uh I think the thing that I love about as not just an application but also as as an SDK is that you know for that that same team that wants to build, I don't know, AWS dashboard, you know, term you know, views uh on a canvas. I think there have been people who built that with teal draw. Uh I think the thing that I can essentially the value proposition that I have around Teal Draw, you know, to those those engineers and to that team is that like um I have already gone through multiple iterations on this problem space. Like uh I've already found all the things that that don't work and that do work and had to make these like really nuanced decisions and whatever. Uh and that I've I've become, you know, I've gone gray over the the canvas and the transforms and all that stuff. Uh and um and have thought probably deeper about this problem than than you want to think about this problem. You would probably want to think this deep about Amazon dashboards on on the canvas, right? Like not necessarily how does undo redo work in a multiplayer app. Like that's a that's a very hard problem, but it's also like maybe not the thing that like gets you out of bed, you know, in the morning. And uh and which is great for me because this is the problem that gets me out of the bed out of bed in the morning, and uh and and I am very, very uh keen to uh to work on this type of thing. So yeah, it's uh it's a good fit. I I feel like the um, you know, I can I can I can look our customers in the eye and say, like, uh I've I've thought about this. Like this is as good as you can get. Um and and that that you know, you're a very, very capable developer. I'm sure had you spend the same time and the same energy on it, you'd you'd you'd you'd kind of also reach some of these same conclusions, but like you're trying to ship your education app, like you're not trying to build the world's perfect canvas or something like that.
SPEAKER_01:So like uh right again, it's a layer of abstraction. Like they don't want to deal with those low-level details and spend all that time on on that. It's makes a lot more sense.
SPEAKER_00:I don't want to ever build a payment processing, you know. Like I don't want to do credit card like I'm happy to pay Stripe, you know, for that type of thing. I'm I'm happy to pay uh, you know, for my cloud hosting and all these different problems that you know would be my problem. Uh, and they're just not the part of the problem that I want to solve or that I want to design. Um so yeah. But it it is it is really nice to stick deep into something enough to to feel like you really, really understand it. And I know enough about software engineering to know that that's not guaranteed with every role. So I feel very, very privileged to have it.
SPEAKER_01:Um last question for you. Uh if somebody wants to go and check out TL draw and and maybe like, you know, what do I do with it? Like, I know that I can go to Tldraw.com, but like let's say I wanted to do some hello world or something just to like see what it's all about. Um, you know, however you want to wanna share anything like that and any links, just whatever you want to share with people.
SPEAKER_00:Yeah, absolutely. So uh tldraw.com is the the free whiteboard essentially demo of the SDK. I mean it's it's more than a demo at this point, but it is uh an end user application. Uh and yeah, please. Please go for it, use it, use it for meetings, use it for brainstorming on the team. You know, I do a lot of drawing with my kid uh on teal draw. Uh, if you want to build with teal draw, you can go to teal draw.dev. Uh in fact, you can go to teal draw.dev slash code with Jason, uh, which is a little URL we put up that uh will will help my marketing guy know whether people uh went there via this podcast. So um it'll make both of us happy. Uh and we also have like a terminal tool, uh npm create, I think teal draw. NPM create teal draw. We have a whole bunch of starter kits that you know show like a very minimal like VT app that uses Teal Draw that you can just immediately start hacking on. But we also have starter kits for that contain multiplayer, the kind of self-hostable uh multiplayer backend that we offer. Uh we have uh one that that removes the background of the canvas and replaces it with like a WebGL context. And so the there's like a kind of an interaction between the shapes and the geometries that you're creating on the canvas, and then this, you know, I don't know, liquid simulation behind it. Um pretty fun, easy, easy to hack on. The the the coding agents are pretty good at writing shaders, so you can come up with something there. Um once we're building like workflows, and then maybe the my my favorite one at the moment is our uh AI canvas agent. So we kind of built a essentially looks exactly like cursor. It's like a sidebar that you can talk to that will use an AI agent, but um you know that it will be looking at your canvas and it will be creating on the canvas and it will be creating based on what you have on the canvas, and it can put stuff on the canvas, and it's pretty far out. And there's a lot of teams that are building like education products and other things that incorporate this um this like AI that can work on the canvas with you. And we should have some sort of uh maybe experiments around teal draw uh that uses these agents in teal draw.com later on this year. Uh but yeah, if you want to develop with teal draw, then tealdraw.dev slash code with JSON would be the place to go.
SPEAKER_01:All right, we'll put all this stuff in the show notes. And Steve, thanks so much for coming on the show. Yeah, absolutely. Thanks for having me.