#6 – Rasmus Andersson: Playbit, Software Quality, Data Models Tradeoffs

And so it's because it's local-first, we can synchronize it across all the hardware, right? And we can back it up on a central computer somewhere. And that means if you lose your laptop you go and buy a new laptop and you sign into Playbit. Everything is back there. Like the window position, text selection. And that also means that you can have many of these computers. And so we have this concept of workspaces, they're basically virtual machines.

And one of these computers you can share with your friends or with other people. Yeah. And then you have essentially Figma multiplayer, but like on the operating system level and these facilities like this data syncing is available , as a first party API, like for application developers. Welcome to the local-first FM podcast. I'm your host, Johannes Schickling, and I'm a web developer, a startup founder, and love the craft of software engineering.

For the past few years, I've been on a journey to build a modern, high quality music app using web technologies. And in doing so, I've been falling down the rabbit hole of local-first software. This podcast is your invitation to join me in the journey. In this episode, I'm speaking to Rasmus Andersen, who helped to build many monumental products, such as Spotify, Dropbox, and Figma, and is now working on Playbit, a local-first operating system built from scratch.

In this extended conversation, we go deep on software quality, the trade offs of different data models, and the importance of the web for modern applications. Before getting started, also a big thank you to Expo and Crab Nebula for supporting this podcast. And now my interview with Rasmus. Hey Rasmus, so nice to have you on the show. How are you doing? Hey Johannes, good to be here. I'm doing well. How are you doing yourself? I'm doing great. I couldn't be more excited to have you on the show.

I'm like a huge fan of so many products that you've worked on in the past. So really delighted to have you on the show. But for folks who don't know you, uh, could you give a quick background on what led you to today? Sure. Oh, God. What led me to today? It's almost like we should go backwards. I think I've found myself through various ways working on local-first software for quite a while. And we didn't really have vocabulary for it until pretty recently.

And so in the last couple of years, as you know, yourself, and Ink & Switch, you know, uh. Adam and Muse and so on. There's, there's like a whole group of people who have sort of like started questioning, you know, like, is this way we're building things? Is this, this is sound, this is like healthy? And sort of the idea of local-first kind of grow out is to become more of a vocabulary as well as sort of like the sort of handmade movement and stuff like that.

I've started realizing that these were values that I've had for a long time, but I wasn't aware of. I started programming when I was a kid and I had my first job as a designer at an automotive company when I was like 15. I think it was something like that. I started my own company when I was 17, maybe something, perhaps something like that. So, you know, very early in my life, I started working and I, you know, I skipped video games and I got gotten into those later. Don't worry. Um, but yeah.

But yeah, so, uh, here I am, you know, a couple, a couple of years later. That's awesome. Well, you're, you're very, uh, humbly skipping a whole bunch of really monumental chapters where you've like helped to start Spotify as a first designer there. And like, built a lot of the foundation there and later also worked at the Figma and Facebook, et cetera. So I'm really curious to learn more about those chapters.

As you've already mentioned, I think you've already been on a path to build local-first software way before the local-first essay was out there, but you still arrived at many, uh, Um, similar conclusions. So maybe starting with Spotify, as there is also this really interesting parallel to me working on Overtone, not trying to suggest I'm anywhere close to your level of polish with your work, but I'm certainly trying to follow a bit in the, in your footsteps. So I'm curious.

How you've thought about building Spotify back in the days and how you've arrived eventually on sort of like local-first ish paths.

That's a great question. And before answering that, I got to say, I think what you've got so far with Overtone is like better, higher quality than what Spotify is today, but anyhow, that's a slightly different conversation. I don't think you should sort of like undersell what you've created yourself. I appreciate it. Spotify came about in a time when the technological constraints pretty much forced us to a decentralized sort of local-first model. And so Spotify started in 2006.

This is when we started working on it. The web platform. And I think that what is, what has been in historically and still is today amazing about the web platform is distribution. And so, you know, that wasn't lost on us at that point either, but it was just like, none of the technology was really there to support something like Spotify. And so, you know, we built a, it's like a fully native thing. You know, we built a native Windows app, a native like Mac app, Android apps.

There's a long list of native apps that we built. You know, we had a NAT hole punching traversal stuff, things way above my head of, you know, like getting through firewalls to implement our peer to peer system. And there was like, you know, this parity stream model where you can get Like different pieces of data to fill your cache was very, very complicated. Right.

I would say that 90 percent of the complexity of, of the Spotify client and even the server side was due to the fact that it was local-first and that evolved over a long time and there's, there were many revisions, like kind of major revisions to the way, uh, they implement and solve these problems at Spotify. That's awesome. Yeah. And I think there.

Since then it's slowly but surely degraded a little bit from its local-first origins and slowly, but surely also being visible in the app, becoming a bit slower, et cetera. But I guess that's the price you have to pay as the company grows larger. But so after Spotify, you worked at Facebook and also at Figma.

And I think there you've worked on some aspects of the products that where you've also arrived on some similar data models and data paths if you look at it from a certain angle, look like local-first. So can you share a little bit more about that?

Yeah, sure. When I was at Facebook, I led this like OS project that they had. And we never shipped it, but you know, that's kind of in line with right now I'm working on an OS, so that's kind of interesting. And that, you know, after a year of that, it kind of ended up not leading to where we wanted it to be. And I worked on Facebook messenger, which it was in a company that had been acquired, not long before I worked on this. And this is like, I think early 2012, something like that.

And the team that they came with sort of the acquisition of the product that, you know, later on underpin Facebook chat, but these were like two things technically for a while was kind of local-first. And I think it had to be for similar reasons that an email client has to be local-first. And so it was iOS technically very limited platform at the time. That was kind of interesting to see. Did I have to work? Upwork and GraphQL together with, uh, Lee Byron, Nick Schrock, Dan Schaefer.

And that was really interesting. So, you know, I started out like a year of, as a designer at Facebook, and then about a year as a software engineer. And after that, I worked at Dropbox actually for a while and worked on their like data store thing, which is kind of local-first thing with like automatic merge and, and, and diffing and stuff and some other projects as, as well. Yeah. And, and Figma of course, like fun foundationally is almost a CRDT kind of data model.

Um, although it is a hybrid centralized, decentralized type of product. So all of those products, uh, I think all super well known. Most of those products, I would not describe them as like, Oh, they're of course, local-first. I think now that you highlight it, I can certainly see certain aspects of them following some of those principles of local-first, but I'm curious in your perspective, what makes each of them local-first also from today's perspective.

It's. Oh, that's an interesting question. Obviously, like if you disconnect from the internet, they keep working, right? That's the basic litmus test of local-first, right? If I can send with Facebook messenger, for example, which is still around, which is still local-first. If you open up that app and you send some messages and you know, you do some stuff like make changes and you're offline. That works.

And when later you come online, those are reconciled with any changes that might've happened by other people. You don't like lose the stuff that you've done. And I think that kind of sums up how I would think about local-first. There are always limitations to these things, right? Like there's some, like, where do you draw the line? I think you have to think about it from a human perspective.

When doing this litmus test and not from a computer technological perspective, meaning that there is just some data that is just impossible to get. Right. For example, if you have in a chat application, if you have a idea of presence, right, if someone is online or not, like that's not, that's naturally not data that you can get when you're offline. Right. And if you did, like, it wouldn't really be useful if you showed like cash data, like, Oh, Johannes is online.

Like two months ago, like that that's useless. Right. So I think you have to think about it from a human perspective. Like if I sent Johannes a message and I hit the send button, you close the app or close my phone or whatever I do. I know Johannes is going to get the message eventually.

That makes a lot of sense. So switching gears a little bit, uh, and thinking about this more from like a developer perspective, how you built those systems, what were, are there any sort of similarities that Emerged from building those systems, maybe in terms of like how the data is stored and how the data layer looks like. Yeah, it's interesting. So you and I have been, you know, we've, we kind of friends, so, you know, we met a couple of times.

So we've been talking about these things in the past. So I think, uh, you know, where this is going, uh, there, there certainly is. A very interesting, I think, uh, observation that I've made with these like projects and with these projects, I mean, like we mentioned these three so far, like Figma, Spotify, Facebook Messenger, there are more. I've worked on a couple of more ones, but I think these ones Perhaps some of the listeners have heard about there.

It's almost like all of them end up like sort of, if you think about a signal oscillating and then slowly stabilizing into a line that is an equilibrium, it's almost like all of them have stabilized around, like pretty much the same data model. Which is this kind of ordered map of, of data, very practically speaking. And I think that's really interesting.

Like if, if you have these individual separate, like engineer organizations, even in different points in time, ending up like with similar, but pretty different, like practical, like product problems, and you end up with like a very, very similar data model, like could there be so that that data model that they have is like actually a pretty good one. I don't know. So Facebook messenger.

Is probably the outplay here in this little, maybe a little bit different, but anyhow, , how I would describe this like data model that I'm talking about is think about a list of things, right? So think about this thing as an array. Meaning that like an item in this list has like a, has an explicit position, right? Position one or five or 2000. And now each like entry in this list is a key and a value. And really it doesn't have to be key in the value.

The point here is that you can say, give me. The fifth item in the list, but you can also say, give me the item with this key in the list. And then the value, it's just like a couple of bytes, you know, the value is not some like JSON document or anything like that, the value could be an identifier of another list deals like this, right? So now like you have a graph, right? So let's say you want it to build on this so we can take Spotify as an example.

So Spotify has playlists on the sidebar and the desktop app or sort of in the mobile app, if you go to the home screen, you have all of these things. They have a list of playlists and you can make folders and put playlists and playlists. Right. And you have playlists from, you have your playlists and then there are sort of a, you can browse for other people's playlists. Right. And all of these things, at least for a very long time, were all the same data structure.

They were all like this type of list. It's right. A playlist, think about it. It is pretty much like what I'm talking about, right? You have a list of songs. They have a specific order, right? Since you might want to play this song before that song. So that's important. And a song itself. Can be represented also as a list. But here you use the keys, so a key could be artist, right? And sure, there can be many artists, but let's simplify it.

So a key can be artist and another key can be, you know, song title. And another one is run length and so on. And now your playlist is essentially the identifier. Each entry in your playlist is an identifier of a list that represents a song, a track. I think it's perhaps obvious at this point, you can now have a, uh, a folder. That's essentially a playlist with links to playlists. Right.

And now you have a graph and you can build this graph up and this list of things that is the guarantee, the ice date is the isolation, like primitive in something like Spotify. So like, if I say like, make these, like move these songs in this playlist and move these songs in that playlist, then these are two transactions. If you want to think about it that way. You cannot like, you cannot say either, like move these things in these two playlists or don't move anything in these two playlists.

You can also only say, like, in within this list, make these changes and have those, like, give me some sort of guarantee that they will be reconciled in a predictive manner in all instances that have access to this playlist. So the diffing and emerging happens on that kind of list level. And interestingly, this is kind of how Figma works too. And there's like some articles, this is not any trade secrets here.

Some articles published about this on the Figma blogs and Figma pretty much have the same principle, right? There's a graph that's built up by these sort of like entries. So you can think about them as a log or you can think about them as like a serialization of a graph. It goes both directions and that's the level where you different merge. And one of those lists is one document on Figma. And so one document is that like.

You know, it's a unit about isolation, like either of these things change, you know, or they don't like one document that's kind of in one known States and Facebook messenger in a similar way, you have like messages and a message, you know, similarly, it's like part of a list in a conversation and so on. That's super fascinating. I think most listeners on this podcast, when they think about data models and data systems, there's typically one of two reference points.

The most common one would probably be like a traditional database, whether it's on the server side where you have something like Postgres or MySQL, et cetera, or if you're a mobile developer, you are used to using SQLite in your client directly, or that's now also possible on the web. So I think that's the most traditional approach is like. Rely on a data system as a database. So I'd be curious how your suggestion kind of compares to that.

I would assume maybe what you've described can be a foundation of a database, but what would be the downsides of using a database directly to build your app? Contrasting with your approach and also now with. A local-first CRDTs is a very common approach to have data structures that are also allow for collaboration. So maybe you can contrast your approach that you've described to using a database or CRDTs directly.

Yeah. I think this is an interesting conversation, which is like, what tools do you use at one point in time? And like, what is a good fit for your problem? And there's almost like. If you imagine some sort of graph between perfect fit and time required and stuff, there are these two lines and they meet somewhere. And it's very specific to each project and you want to kind of hit that spot. Okay. Let's, let's think about like a bunch of different projects, right?

Everything from something like Spotify, there's like a, you know, a big undertaking, like a company where, you know, we're going to be, okay, we're going to spend a year or two of like 10 people. And we just kind of like, you know, pour like tens of thousands of, of hours into making this one thing go well. And on the other side of the spectrum, think about like a, you know, sort of a Robin Sloan home cooked meal type of like, I'm gonna like make an app in an afternoon sort of thing.

I think these two, you gotta take very different approaches for these two things, right? If you build this company-size thing by just like just throwing some generic thing on it where it really matters. And I got to say, you know, there, there are going to be. A hundred different problems you need to solve and 95 of those problems, you should solve a generic technology and it's really hard to know upfront. There's 5 problems that really will set your product aside from the competition.

And those are the 5 problems where you want to think really hard and solve for really, really well. So say that you've identified those 5 problems. You don't want to throw something generic on there. Because that's going to like ruin your opportunity to really differentiate with Spotify. For example, we knew that like to skip in a song that should never be slower than 200 milliseconds. And so a lot of engineering went into just making sure that that was true. Right.

And that's kind of how you find some of those like five things with the home cooked meal type of like, I'm going to spend a week and making an app kind of thing. You don't, you just don't have the luxury of that. Right. Even if you do identify, these are like one or two things that Like make my thing like different. Maybe my friends will like it more. You got to be creative.

And I think in that scenario and find either really hacking solutions or like just be super lucky and find some existing stuff that does that. And I realized we're on a bit of a tangent here, but I think like it's important to have that, like setting that like picture frame, so to speak. Right. So with something like Spotify and something like Figma, which both end up with like pretty much the same or very, very similar data model, those data models are specific for their problems.

They're both in both sides. They are one of these like five things that makes them stick out. Right. Like if Figma had not came up with it's a sort of CRDTs smelling semi centralized sort of, uh, document graph format, whatever, it probably wouldn't have been as fast and, you know, probably wouldn't be able to scale and it probably wouldn't feel that very good if it wasn't that fast, right.

And maybe it would never have gotten traction in the market and wouldn't have been successful as a company. And similar for Spotify, like if collaborating on playlists and stuff will be really slow or you would just like sometimes lose data. You would probably also have lost users early on. And these solutions were very specific. So I think that that tension exists. And when building something ourselves, maybe we're not on the extreme of like, I only have, you know, 10 hours to make this.

Maybe it's more like, you know, I've got maybe 200 hours over the course of two months. I think it's very, it's very like. Attractive. To reach for an existing solution, but I think in many cases it ends up costing us as much to use third party code as it does to write it ourselves. So think about it. Let's say you use like a library someone else read. So you put that in there. It does mostly what you want, but at some point it will not. Right. Like every single piece of code has bugs, right?

Like I've never worked on something that doesn't have bugs. Everything is bugs, right? So you just assume that that's the thing has bugs too. And at one point there's gotta be, uh, there's gotta be an issue, right? Or like, it doesn't do the thing you want it to do. Maybe there's a bug and it does do the thing that you want it to do. Right? So basically now you have to fix that code, right? Or change it. And that means that you have to read the code and understand it.

And I argue that probably takes a very similar amounts of effort in the common case as it would, if you wrote it yourself. You probably, to understand it, you're going to have to go beyond the code and understand the, you know, the logical aspects of it. Maybe you have to read some like technical papers or some books or speak with some people to understand how things are solved in a way, not just like what the code does. So I'm not saying like people should always go and write their own thing.

Obviously there's gotta be a couple of things , that don't fit this, they're outliers to what I'm saying. So if you, if you say, I kind of need like a relational database and you're like, okay, I'm going to build my own Postgres or SQLite. That's, I think, obviously a bad idea since like there are existing solutions, really well tested, really high quality. If they don't do what you want it to do, it's extremely flexible. You can probably bend it to do what you want it to do.

If you were ever run into performance issues. You can solve the problem then, right? Assuming that like the solution fits the problem that you have. I really like this mental model of like, you choose for like 95 percent of stuff. You use like the default things, but like on 5 percent you spend your innovation tokens and that's super interesting. I, and I definitely agree that choosing the right foundation for your data model.

It's a super high leverage bet that you can place your innovation tokens on.

One more thing to consider is the, almost like the, how well the glove fits or like the Swiss army knife problem, if we call it that. So let's say you've got to, you're going to cook some food and you need some tools to cook. You need some pots and pans and some knives, right? As a cutting boards. I think one approach to doing this is you have one pot. Or maybe you need two pots because you're doing two things concurrently. But like you have this kind of minimalist mindset.

You have one knife, you used up all your, all your chopping. You got like, you know, one or two pots and you cook everything in it. And then you got on the other side, you got the maximalist mindset. You have like 20 different knives of different sizes. You're right. And you have like 14 different pots and you have rice cooker for that kind of rice and a rice cooker for this kind of rice. And you know, there's this like specialization. I think that this thing happens with technology too.

And especially early on. I think that there's a, an appeal to using something that's very flexible early on to have those 20 knives available just in case I need like a tiny paring knife or a big butcher's knife. Right. Just in case. Right. And so I think a lot of people reach for something like SQL late early on, just because they think, oh, I might need like some inner outer join search thing hidden, you know.

Functions in a database kind of thing, maybe down the road, I need that, you know, maybe I need to do like some something, you know, I need to set up constraints and to protect myself because like, maybe I'll forget what I did and stuff like that. And, you know, that, like, like everything, there might be some, there might be some truth to that being like useful, but I think in most cases it's not. And I think in most cases, we start out with too much flexibility.

And the problem is that anything that's simple will grow to become complex. Or another way of thinking about it and complexity always grows, right? Anything you have, it's like kind of the law of entropy, essentially, like whatever you have your computer system, whatever your app over time will only grow complex. And you have to work really, really, really hard to do the opposite, to make something complex, grow the other direction to the towards simple. And so, you know, if you agree with that.

It's, I think it's pretty reasonable to say if you start out with something that is pretty flexible, it's probably pretty complex and it will become very, very complex in the future. And so I think in most cases, what people need, it's just like a key value store early on. And I mean, I mean, that's what SQLite uses under the hood, right? SQLite is like, you know. A set of like functions is essentially on top of a key value store to make that easier.

And I think in most cases, if Facebook messenger is a key value store, for example, at least when I worked on it's a level DB before rocks DB thing. So yeah, anyhow, I just want to say that and wrapping that up, what I was trying to communicate here is that when starting out with something new and thinking about databases can be, you're smiling because I know like with Overtone, you've been thinking a lot about this and I think coming to the similar conclusions.

Start out with something that's like a glove that really fits your hand instead of like a whole wardrobe full of like potential winter clothes you might need. Yeah, I love that analogy. And I've seen this story now so many times that either you start out with a database and then step by step you like remove layers from the database because you need to go more low level and you need to have that performance or power.

Or you go the other way around and you start it up from scratch and then your app kind of becomes a database. I don't think there is a right or wrong. I think there's a good fit for the right use case, but I agree that this is like a super common scenario. And it's very interesting to see that all of those different companies that you've worked at, that this emerged in a very similar way. Moving on a little bit from the data nitty gritty details. On to a more broader topic. The most.

popular platform right now, the web, you've been building things on many different platforms, but I think that the web has always been like a common factor in all of the systems that you've built. I'm curious, what is your perspective today on the web?

The web is what got me into programming computers in the first place. Well, that's not strictly true. I started with like in a friend's basement on basic. But the thing that really pulled me in was like the web in the nineties.

And I thought it was like absolutely magical that I can go on a webpage and it usually said CGI bin in the location bar and I can go to a webpage and I can like make a change and then I can go to a friend's place who also had a modem and we can look at the page and I can see the change that I made. And that to me was like. That that's magic. That's like, that's amazing. Forget everything else. I don't want to be an astronaut anymore. Like I want to make that thing.

So like, I've got, you know, I've got a lot of love for the web and yes, I worked on a lot of web stuff through the years. And I even worked on like a, together with a friend of mine in 2010 or so, we had like a, a fully local-first, like website, and then even, even the like image processing. Like decentralized on clients, computers and stuff like that. No Bitcoin mining, but you know, it kind of smells like that a little bit.

So I think the, in the last 10 years though, it's like gone in a direction that I'm not super happy about. So first I want to say that like what is really, really powerful and valuable with the web is not HTML and CSS. I think that's mostly like a historical accident. What's what is so, so powerful is the distribution, the fact that I can give you just like a URL, which is a piece of text, which is like the most ubiquitous data format. And, you know, exactly what to do.

I don't have to ask you to like, Oh, by the way, with this piece of text, you have to go to that app and do this thing, you know, right? I can send it to, you know, exactly what it is. So it's ubiquitous, the human understanding of what a URL is. You see that. My mom sees the URL, she doesn't understand HTTP like, and she doesn't have to, right?

But she sees it, she knows the URL, she punches it into a web browser and she will see something that's like pretty similar to what I see, you know, it's like, you know, it's similar enough that it feels like it's the same thing. And that I think is, is so valuable. That all the downsides of the web and all the valuable things of other platforms are just like, just not tipping the scale, right?

Like this is way so heavy on sort of, uh, you know, an imaginary scale that the web platform I think has won. You look at like a tech workers, like laptop today, it's probably a MacBook, but do they run any native apps on it? Like probably not, which is kind of like bonkers, right? You're going to, you're going to look at it and use Slack. It's a web view, right? And they use Figma. It's a web view. And they use like, uh, Discord. It's a web view. And they use Spotify.

It's these days, it's a web view, right? And then they probably have a web browser with like a hundred tabs. And, and that's obviously a web thing. And what's left, I don't know, files on their local, like those, those are not like web things. Right. And so I think it's like really hard to argue that the web platform hasn't like won in terms of.

Becoming the dominant platform and platform, including like Microsoft windows and iOS and Mac OS as platforms here alongside web, um, because the web really does feel like a sort of an operating system or a platform. It's like a target for software development, right? And distribution. So where web has now has definitely won is the. best distribution mechanism that we have today. I think we've also sacrificed a lot when I think there's like the sort of fuzzy word of like, is the app native?

I think there's like no clear line of an app being native or not. I think it's rather like, does it feel native , corresponding to a certain platform? So where would you hope that. The web would go further. Where do we leave money on the table in regards to the web?

That's a good question. And I realized now that we're a little bit off topic of the sort of general, you know, theme of this podcast, but I think that's okay. I think this kind of relates somehow. And I think what you were saying Johannes is I think really like stirs my mind in a really good way, which is, you know, What is native and perhaps it's something that like feels native. Right. And what does that mean?

I think what, what it means to me is if I run JavaScript or if it's objective C or Swift or Android Java or go, it's all the same, right? Like all of these things just, you know, Are translated different ways to the same instructions on the CPU and use the same memory. There's really no technical difference below a certain level of any of these technologies. Right. So it would be incorrect to say that like web is a different, it's like a user, a different CPU, like the JavaScript CPU, that like.

That's not a real thing. Right. So these are all the same thing at like a pretty low level on the computer. And so what leaves us then is like, not really like, does it run a different CPU because it doesn't, it's more about that feeling. I think that feeling comes from and why it, why it matters. We can talk about too. But I think that feeling comes from just like things looking the same and behaving the same. Looking the same, I think is less important behaving the same.

I think it's a big deal and looking the same where it's important is to recognize that something looks similar. So let's say we're walking outside. We walk in a park, right? There's like trees and stuff. We can identify a tree as a tree. Although we don't know if it's like an oak tree or a pine tree, right? Or like some specific, like, type of oak. Maybe we do know that, oh, that's probably an oak tree. That's probably a pine tree.

But we don't know the subspecies, but it doesn't matter the fact that, like, we can tell that that's a tree and that's a rock. This is the sky and this is the ground. Like those things are really important. Then if the grass is green or yellow or brown, that's less important for our, like, you know, ability to, like, navigate, right, the space.

And I think the same is true in a, in a user interface, that if I see something that looks like a pop up button and, or something that looks like a button, Right. The most fundamental of UI elements. If it doesn't behave like a button, like my mind will break, but it doesn't, it doesn't have to like, look exactly like the button that I'm used to.

Right. If I'm using macOS and the button, this button we're talking about now looks totally different like aesthetically, but I still identify as a button. The fact that it looks different is not important. Right. As long as it behaves the same. So I would say that behavior is, is really the most important part. It's like recognizing that it is about the yes, that behavior, big deal. And I think this is where the web platform has a huge problem because it comes to not an analogy, right?

So imagine that we have like a planetary system with different planets, you know, Mac OS or iOS, let's take that as an example, iOS, that's one planet, right? You got a set of like rules there, you know, grass grows in a certain way. There's a certain amount of gravity. The sun rises in a certain time. There's like a bunch of rules and there's a world and everything sort of is.

In harmony with these like laws of physics there, and then you go to Microsoft windows and there's a different world and some things are similar, but like, a lot of things are different. Right? And then you go to the, to the, to the web, right? But the web is not a planet. The web is another planetary system. There's like, not one website works the same as the other website. This is actually a problem from a business perspective.

And it's like a lot of big things, you know, run by businesses and they care about money. And so I think they're leaving money on the table. By making things like behave differently, right? I go to, I don't know, uh, a website for, uh, for getting groceries delivered, right?

And now this website has like some pop up menu that's like some homemade thing and it doesn't work the way I expect it to and now like that, that becomes like a cognitive, like work that becomes like a, a road bump that becomes like, like a detour. Right for myself, that's something that I have to spend my, my limited energy on. Maybe I go to this website. And again, order groceries. I haven't done it before. I'm like, is this going to, is this, is this a good idea?

Should I do this instead of going to the grocery store? Blah, blah, blah. Then let's say that this website would be like, there's a big hand coming up in the middle of the website that says like, fuck you, man. It's like, you suck. And like, I would pretty quickly as close the website to go somewhere else, probably if it started, like, assaulting me sort of verbally. So that's like a very extreme version of it.

And I think these small things are these, like, tiny things to build up to the same thing. Right? Eventually, when it's like, I filled something out in the form, and then I switched tabs and I came back and like, They had some server side session or some like insane idea like that. And it like wasted all of the stuff I read them because I hadn't submitted it because my, my session expired. Right. I'm going to be furious and things like that.

Those kind of, they almost account toward like a rising thermometer. And when it gets too warm, I'm like, Ooh, I'm starting to sweat. I'm out of here. I know I'm like saying a lot of words and it's a little fluffy, but I think that there is some, some real value left on the table here in terms of like,. Removing that friction and instead having that like limited cognitive supply of a user of a visitor of whatever thing you have focused on what makes your thing different. Right?

If I go to Overtone and I use Overtone, like how, like I scroll, that shouldn't be like the thing that I spend time on, right? How I select what happens if I double click like these things, if I have to spend my brain energy on that. I'm not going to have much brain energy left on like what actually makes Overtone interesting. So I think then, you know, where, where is this not true that I'm saying? I think it's like with entertainment and art.

Right. If I visit like a website that is supposed to give me an experience, what I'm saying does not apply, right? If I like play a video game and part of the video game, it's just like, there's just some, some ideas about you. You kind of want the person to think about like how you interact with something instead of a button on top of like the screen, maybe you like, there's a 3d world and you interact with some liver.

So, so it doesn't apply everything, but I think in vast majority of web apps, What I'm talking about is like an issue. Right. Uh, I always look about like the web as a spectrum from going for like what the web was originally created for websites to now what we are also using the big web hammer for is like for web apps, and I think there is this spectrum and my theory is that we're.

the web apps, this is where it really matters that the apps feel more native and that all the paper cuts are really like worked out, but they are not. And I think this is where we are using the wrong, the wrong hammer for building those, those web apps. And so I think one way to think about addressing that is I think to build those apps in a, in a more local-first way as a way out of that misery. Would you agree with that? Or do you have other ideas how we make the web better in those cases?

I think the local-first approach is one of them. I think that it's. It's interesting how making a web app local-first is kind of like playing on hard mode, I think, since the web is fundamentally centralized, if you think what, what defines the web? Well, I think hypertext, like, you know, originally defined the web. And I think today it's more like web browsers define the web and hypertext is like 1 medium, you know, you could open a PDF, you know, in SafarI can open a PDF.

I can do that in Chrome too, but it sucks. And it's fundamentally like built on this idea that like, I have a portal that connects to a service somewhere else over the internet. And, you know, now we have like things in the web browser that kind of fuses the border. But, um, if you think about like a local email client instead, right. Or an email client running on iOS or something like that, then you're not starting out in an environment that is.

Already set up against you, so to speak, if you're not trying to build something local-first, right? It's kind of neutral ground, right? You can build an email client that works like a web browser, right? That like the first thing that does when it starts up is to connect to a server somewhere and ask it what emails does Johannes have, right? Another way of doing it, you can, but you have to write that code, right? And now they're like conscious, like choice that you can make is.

Let's read from a database. What emails I already know Johannes have. And now I'm going to go and ask a server if there are any new emails to put in that database. Whereas on the web, like you have that first choice made for you. And to some extent, like you can't even undo that choice. You have to kind of work around it. So I think like your question was really about like, does local-first make the web better? Like, what can we do to like fix it? And what's the issue?

I think the, the solve here is, is more about the user experience. I think. You said the web was kind of made for web pages and, and I would go a little further to say the web was kind of made for like documents, right? Like text document. I think your average marketing website when information about some service or product or whatever, or like, uh, you know, an essay or an article about to learn about something that HTML and CSS is great for, I mean, this is what it's made for. It's fantastic.

It's like a layout tool for like, you know, text and images and video and stuff. Right. And of course we've gone way beyond that. We can now have interactive elements to learn about how like a, I don't know, some sort of water lock on a boat works right. By like playing around with it. And that's super cool. And I think that's where it like really shines the medium. But then you think about something like Figma where we, where we spent over 1000 engineering hours on just the context menus.

Which is insane and they still kind of suck, you know, and that that is like, not okay. I think it's a good, like, think to think about, like, do I want to spend if I care about quality? And I think a lot of people listening to this do care about quality. And it's maybe 1 of the reasons they even started thinking about local-first. If If I care about the quality of the thing that I'm building and the people have a good experience with it, there's a couple of trade offs I have to do. Right?

Like, first off. Yeah. You can't just get quality for free. Quality has a cost. So usually that means I will have less features or fewer features. And it probably also means that I will have to spend more time in a couple of areas that are like hard to identify. And in turn, that means I have to spend time identifying those areas, right? Something like context menus at Figma. Time, like trying to understand, like, what, what is a good context menu? Like, what do people expect?

This is still a lot of, still a lot of product or engineer work or whatever you want to call it, design work, but it's not work where you like write code or like draw things. This is like, you speak with people and you thinking whiteboard and all that kind of stuff. Right. But that's still like an important part.

Uh, on the road to getting to something that has like decent quality, because then the next step is going to be, now that we understand like what people expect and, and I think quality and expectations are very much intertwined. Now we know what, what to build. And then you have like something like the web platform with this input event model and it's focusing system and all this kind of stuff you have to sort of like, you know, that's another like place where you got to invest time.

Right. So I think like what a possible better future might look like is if you imagine in a web browser, Having a different content type that's like, I don't know, um, application slash application. I don't know, whatever. It doesn't matter. So like a server, like sends back like a blob of data that is this different format, uh, instead of HTML for something that's an app. Right. I think that's a stopgap solution.

And I wouldn't be surprised if someone like Arc or something is like working on this right now. But that's going to require developers to like write apps in a different way. And I think that's a. Big deal. And you're still going to be in the scenario for web browser. That's fundamentally centralized, right? The whole model is like you're in inside this like little box on your very powerful computer. You put this little box inside your like amazing powerful computer.

That's like literally like visually a little box inside and this little box inside now can only use some of your resources, right? It's single threaded mostly. And it can use maybe two gigabytes or four gigabytes of your like 90 gigabyte, like memory. And, you know, you got all of these like kind of weird things and that is not going to go away, but, and, and the more long term solution might be something, something a little different or like maybe bringing back native apps, whatever that means.

I don't know what that means, but anyhow, the user experience here, I think like moving away from HTML and CSS, it's, it's a, it's a, I don't even, I can't really see the path. Toward that, but I think that would be like a true improvement to quality where I can say, I want a context menu with these things in it. And I know that it's going to work and work everywhere. And people know what to expect.

And I can spend like maybe one day on putting that context menu together and testing and stuff instead of like, you know, a year. What do you think? Like, you've been asking me a lot of questions. I'm also really curious what you think about these things because you actually think about this like day to day, right? When it comes to like the web. Would you agree or do you disagree when it comes to like the, you know, the quality and the fit of HTML and CSS here toward like a model that's better?

I completely agree. I haven't reached the context menu stage yet in the app development journey, but I've so far spent a lot of time on tables and just making the app fast. We haven't talked, we've like somehow touched on performance, but another aspect besides just raw capabilities of the web is also just making the app fast.

Building a fast web app is something that's like you said, like it's, it's an hard mode, not just hard mode in terms of capabilities, but also hard mode in terms of performance, since if you want to build things in a like rich, interactive experiences with that HTML, CSS document model. That's not what it was built for. And so this is where I find myself reaching for other approaches now.

So I'm specifically for like the table component I've mentioned, I'm using a great tool or a great software project called Glide Data Grid, which, um, is like a React table implementation, but which is rendered entirely on a canvas. Um, and so that allows you to get like 120 FPS smooth experience and way outperforms any other react table implementation out there, but you gotta switch your mindset a bit. So you're no longer tweaking CSS values and wrapping things in 5 deeply nested divs.

But if you want something more custom, you got to reach for like the canvas API and go back to drawing rectangles and so on, which I personally enjoy. And I think a lot of other people have also come to like rediscover this approach. That is actually quite nice.

But I think, Looking at this more broadly, I think there could be almost like a app kit kind of abstraction, what you got on, on iOS, on Mac, but maybe for the web, maybe like a whole new, whether it's, uh, the MIME type like application slash application or something else, but that I think we have now really powerful primitives, whether it's web GPU and WASM, et cetera, where we can have like entirely different model, we leverage the distribution mechanism of the web.

But we're going for like a flash 2. 0, but I think there's some really interesting developments there. And, uh, this glide data grid canvas table that I'm using, I think that's just like the beginning of, of new approaches. So another, uh, notable project that comes to mind is, uh, it's called eGPU. I think, uh, no, sorry, eGUI. Oh, by Emil at, uh, uh, Rerun. Exactly. Yeah. So that, that's a really compelling project.

I think it's still, um, I think it's both come along really, really far, but it's still early compared to like all the primitives that you're getting from like HTML and CSS, and it's kind of a miracle how capable browsers still are and how. Relatively speaking, how performant all of those things are compared to the complexity that they can afford. So I'm of the same opinions like that. I have a love hate relationship with the web. Yeah. I just want to like reflect on what you were saying.

It's, it is interesting though, right? How you're talking about the table component, how you're basically just like exiting out from. All of the HTML and CSS, right? It's kind of what the canvas is. You punch a hole through all of that stuff and you say, I'm just going to go like start from scratch, basically, and draw pixels. And now you're going to, you're going to make some trade offs, right? Like you're going to have to implement your own like shadow DOM for accessibility.

And you're going to have to like, you know, re implement things like scrolling. And you're going to, there's like, now there's like an ocean of stuff you have to do. And perhaps that's why you use the third party code that maybe has already climbed this mountain for you. But it is interesting how, like the solution, so to speak, for your problems there was just like, not use the web platform essentially. Right. Like not use HTML and CSS.

I think that's why, like there's eGUI, there's like, you know, there's, uh, Deere image GUI, there is make pad, there's like Zed and warp. And there's like, there's so many projects that develop their own. UI frameworks, some of them target just like some unknown platform. That's kind of all of them. Some of them specifically target the web, but I think what they all have in common is that like, they don't use the web.

Right. And I think the web is like the dominant HTML and what makes a computer fast, right? Like, or what makes software on a computer fast? So the hardware we already talked earlier about the hardware that we have today. It's like. So ridiculously fast. It's hard to comprehend how like fast computers are today. Even computers from five years ago are like mind blowingly fast, but software keeps getting more complex. Right?

So there's always that, like, there's the balance of hardware, hardware engineers makes things go faster and software engineers make things go slower. Right. There's that, that it's like a pump. It goes like that forever. And so, yeah, you take something like, like one of these, like, uh, new GUIs that are implemented on just like, uh, Canvas or like Figma, right. They are fast because like, they just do less like shit. Like it's as simple as that, right?

They just like cut out some stuff that they don't need. What makes software go fast on a technical level at 15, 20 years ago, it was, it was like, uh, processing speed. People will do a lot of smart things with caching to make things go faster. Today it's memory, right?

If you, and memory and context switching, and you know, you can go further up in the abstraction stack, but like fundamentally you have a CPU, right, or like a core of a CPU and you have a conveyor belt and on the conveyor belt are instructions, right? And there are things like load something from memory. Uh, and load something else from memory, add those two things together and then put the result, like upload that to memory here, right? That's all it does. That's all the computer does, right?

It just goes like this forever. The speed of this conveyor belt, and that's the CPU. It is so fast that it's basically today. It's like almost fully limited. By its ability to communicate with memory. So memory is really the limit. It, of course there it's more complex than this. And there's like many levels of memory and stuff like that. But I think what happens is we use these like high level things like JavaScript running in a, in like virtualized in some container on top of something else.

So now like you got basically none of the benefits of really fast memory. That is the CPU has like a memory built in called registers. And then it has like a. A very small piece of memory that's nearby it. That's like the first level of like a cache, like a line cache and and further and further away and fetching something from memory. It's kind of like, imagine you're sitting by your desk and you need a pen to write on.

If you have opinions next to you, that's kind of if it's in, in, in the line cache in the CPU, you just pick it up. Be right with it. And now like getting the pen from memory, it's like walking to your neighbor's apartment to borrow a pen, going back and writing one thing and then going back to the neighbor again to leave the pen. Like that's the order of magnitude of difference. Right.

And now you use something like, like a higher level thing, like JavaScript, the Python, or there's like many, many things. I'm not saying one thing is like bad or good, but just the concept of it. Urea is always going to have to go to the neighbor for that patent, right? You can very rarely like use the same. If you have things adjacent in memory and you access them, like you're looping over like a, an array of things that are all in this contiguous array of things, like in memory.

That's like, that's like basically free. If you have an array that points, like that are pointers to things. That's just like a hundred times slower, at least it's, it's, it's not even like a little bit slower. It's just like incomprehensibly slower than the first thing. And so what a lot of like performance stuff does today and some of these UEs, like they recognize this fact, like memory is the limitation. We're just going to put things in a race. We're going to use like memory allocation.

We're going to be conscious about memory and the web platform. Like that's the second thing, right? There's like, there's a blob of things. There's a bag of stuff and you have pointers and you have a huge graph. And so I think this is like, why a lot of those things are fast because they have the mechanical sympathy, right?

They, they kind of realize that this is kind of how computer works and here are the constraints and weaknesses and powers of how the actual computer hardware works and, you know, things like scheduling and virtual memory. And we're going to use that to our benefit, right? And on the web platform, even if you do have mechanical sympathy and you do understand this, there's nothing you can do about it. Even in WebAssembly, you don't, there's no stack, right?

I guess it's like this implicit kind of stack machine. And even at that level, you have some, you have some very limited abilities to manage that, you know, that very sort of low level to squeeze the last performance out. I think video games is like a, an interesting like place to look because they, They have a very, very tight frame budget. And that is like a holy thing. You don't break that. you might drop an entire frame. You might drop objects.

So you might like just what the modern games do today. Instead of dropping frames, they, they drop objects. So they drop quality. Maybe the textures like gets a little fussier for a little while just to make that happen. And we're talking about, we're measuring things in microseconds at this point. And I think a lot of people who work with web software, like even if they wanted to, It would be kind of like, uh, you know, an uphill battle. So you measure things in milliseconds.

They're like, Oh, this is takes only eight milliseconds. And that's like eight milliseconds. That's like an ocean of time for someone working on a video game. That's like, that's like basically the entire game. Like running. It's, it's entire like thing. It's like eight milliseconds. Right? Yeah. in the web, we don't even have. Uh, mechanisms to get more fine-grained resolution than milliseconds in, in most browsers, like, I think for security reasons.

I think there, there was once, but I think it's mostly been removed in, in many browsers. But it's a, it's a very interesting parallel, what we've been talking about in regards to getting the best performance in the web. You gotta abandon a little bit of the primitives that the web gives you. Punch through and go more lower level.

And it's a very interesting parallel to what we've talked about earlier in regards to the data models, whether you use like a really powerful database and then you start peeling off the layers. It's basically the same story just for a different, um, for, for a different use case here, whether one is like fast UIs and the other is fast data.

So you as someone who's so prolific in building apps, building tools, I'm curious whether there is any apps or tools that you particularly admire and love using today.

I think that there's quite a few, but not as many as I would like. One that comes to mind that I started using recently, maybe three years ago, it's called MimeStream. It's by this indie developer. It's a Mac app. It's a native Mac app. It's an email client. And it's the first time in a very long time. I used an email client that like I liked using. I think mailbox on iOS was the last time I used an email client that I liked. Everything since then has been like a bit of a disappointment for me.

So that's just like a piece of software. I think in recent years I've been sort of pleasantly surprised by. Sublime text is like that. That's usually the editor that I use for, for writing. And I'm kind of a person, I have used a few tools and I use them for, for everything. So I have very few like programs that I use and I tend to use each program. For a lot of tasks, the sublime text for me, it's like fantastic. It, and iTerm is another one, but it's very, very niche thing.

But, uh, sublime text kind of, uh, text works the same on pretty much the same on like Ubuntu, Linux, Windows, Mac OS, but it like respects like the lay of the land of these different platforms, like shortcuts, like window behavior, scrolling It's very, very fast. Most operations, like you just finished when you ask for them. You know, there's no sort of measurable delay.

One thing that I think is really neat about sublime and this, this goes for a few other apps, like, uh, I termed that I mentioned or something really, really cool as well in this vein is like, uh, they, they care about state sublime text care about state, right? And I think there's a lot of apps today. Even iOS apps, like don't do this anymore. Meaning that if it is come on cute, just quit sublime, right? Let's say I got a bunch of windows open.

Each window has a bunch of tabs, different text files, some of them not saved. Some text selection scroll, we might be talking about 100 files open, right? Think about your web browser and tabs and like scroll position text selection. And I quit it and first off quitting it takes like a 2nd, right? It doesn't, I don't have to, like, if I quit Chrome, I have to sit there and wait. And then if that was a mistake and I started again, what happens is that, like, all the windows come back up.

Um, exactly the way the word, the same Texas elected skull possession. And this might seem like, Oh, that, that doesn't seem so valuable. But what it does is it makes me not afraid of software. It makes me not hoarding tabs. It makes me like not think twice. If I, when I'm going to reach for sublime, because I know that the cost is like basically zero, right? If I like, Oh, I should write something. I'm going to start sublime. And I, and then I realized, Oh, I shouldn't. And I can just quit it.

Well, it was a lot of other software. There's just like, we touched on video games a couple of times in this conversation too. I think video games is this problem too today where I have to like commit to this big time chunk of investment. If I want to use something, if I want to switch tools, if I want to play a game on the PlayStation, I need an hour to like apply updates before I can play it and then get through the menus. It takes 10 minutes, right? And then load the game.

And now play for, for 10 minutes and now, Oh, time is up. Right. Or like I opened some web app and I have to wait like five seconds for it to be functional. And you know, there's this old cost. And if I quit the tab now, right. Baxin or whatever, I've lost most of my state. So I think that there's some good software, but it's, uh, they used to be more good software in my opinion. I'm also like an old dude, so you know what they say. Everything invented after you're 30 is just wrong.

So there's, there's some bias here, but I think that there's, um, there used to be a lot of software that would qualify him in my book as being pretty good. And there's not that much anymore. How about you? Do you have a, do you have an app or, or service or something you think it's, it's doing particularly well on these, these accounts? Well, so I definitely share your perspectives and observations.

And I wanted to also ask, like, whether it's just my feeling or whether that is de facto, the case that they used to be. More higher quality software in the past, and that has sort of degraded over, over time for in terms of like apps that I, that are really like, uh, I can plus one of the ones you've mentioned, I think, uh, telegram as an app on, uh, macro as an, an iOS is, is one that I, that I like that just feels like very snappy.

But, uh, I agree like your observations in terms of, uh, like preserving state kind of like respecting the, where a user left off. And then when you come back, that is still all there. That gives me confidence and just makes me less afraid of using it. I definitely agree. And then also, even if it does remember everything, just making things fast or keeping things fast, that is another, another aspect of just like respecting my time. It's another.

Paper cuts when I'm using software and it takes forever to load. It just makes me, it's not like that the software is broken, but in a way, it like sucks out a little bit of joy out of my day. And this is also something where I'm spending out of like the 95 to 5%. This is where I'm spending probably one of the five, uh, on, on Overtone. And given that Overtone is targeting the web, that is like you say, Very much on hard mode and you got to poke through a lot of layers on the web.

And I take more inspiration from native development and app development to try to get there, but it's really hard, but I do think it's possible. I think it is possible to get the best of both worlds, at least like directionally where you get the distribution of the web and directionally closer to the to the performance of like a, a native platform. I'm curious why you think that is that, uh, software in the past was maybe felt higher quality, was higher quality. Do you have a theory on that?

I do. I think it's like as simple as technological constraints. Earlier in this book, In this episode, we were talking about, or I was talking about Spotify and sort of how they came about in a time where a web browser, like the web platform just wasn't a fit. It just didn't have the features. You couldn't just play audio randomly or there were no web sockets and stuff. I think a lot of like.

Software that we're talking about that we say like, Oh, that was kind of good, like an old version of Outlook from Microsoft, or I know like, uh, Microsoft Word these days. It takes like 10 minutes to start on my computers. I don't know. Not 10 minutes, but it takes a long time. I mentioned to you in the past. I have this, uh, Mac book, a power book from 2002 and it's a bit of a time capsule. Uh, it still boots up just fine. And it's like pretty fast.

And if I start certain apps, they start right away. And I'm like, This got a mechanical hard drive that's like, I don't know, 20, 20 something years old. This shouldn't be this fast. Right. And I think it's that fast because there's a human, almost constant, like set of thresholds. If we forget about computer for a second, there's like, what is a reasonable amount of time to wait for something to be ready for me to use?

I think the answer is it will be in relation to how important it is to use that. If I'm going to travel across the world somewhere, I am okay with spending four hours in like taxis and airport security and stuff and getting on an airplane before I get to the, into the air, on the air, in an airplane. Whereas if I'm just like going to the grocery store, I would not be okay with waiting four hours. To like get on the bus to get to the grocery store.

It's in proportion to like the threshold or like the, where the amount of, and the threshold is like, if I'm going to say, yes, okay, I'm going to do it, I'm going to wait for it. Or like, no, I'm going to find a different solution. That's kind of the threshold. It's in relationship to how important it is. And I think this is a human thing and not something that's like, Oh, that was the case in the nineties, but now it's different. Or like, Oh, that's has to do with computers.

And so now let's say, yes, for the sake of conversation, uh, opening an app, my threshold is like two seconds. If the app hasn't started in two seconds, some app, whatever, Microsoft Word, then I will probably just go and find a different solution. Maybe I'll use notepad and windows to text that into macOS and I'm just going to be fine with some features not being there.

I think that developers like have been very conscious about this or found this out through research or somehow like know that like what this thing is, right? Okay. We need this. We need Microsoft Word to start within two seconds. Let's make that happen, right? Otherwise we're, we're not going to get customers. And then 20 years ago, you had to go to some pretty great lengths to make something start within two seconds because you know, like computers were a lot slower, right?

Hard drives are a lot slower and so on. And today I think we have the same, we have exactly the same like human. Properties, but now we can boot up like an OS, like I'm working on an OS. We can boot our OS up in 250 milliseconds from scratch. Like the kernel and everything and drivers, right? We can boot up like our OS 10 times over before like Word even, even has started on my Mac. And that, like the fact that like our thing boots fast, like that's kind of irrelevant.

It's more like a comparison that like you can make something quite complex, like an operating system, like do a lot of stuff. Right. And so what does Word do when you start it up? And it takes like, you know, 5, 10 seconds for it to start. I don't know, but it must be doing a lot of stuff. And so I think that's what keeps happening over time. We just keep doing more and more and more and we're doing less and less like clever stuff. And I think now wrapping all of this up.

I think there is a strong correlation between what we do here and like, the local-first, the purchase, the local-first approach in a nutshell. Right? Again, it's kind of like, you make sure that things like work when you're offline. Right? And you make sure that, like, if you, if you lose that connection forever online, you can still use something, right? You're not totally lost.

To an extent, I think that goes hand in hand with like making things like fast within a certain realm of things, right? Like if the first thing you have to do is to like re index like all, and this could be a problem for local-first as well, but have to re index everything that exists. That's just going to take a long time. Every time Dropbox starts, it's gotta, it doesn't know which like files have changed on the computer, right?

So, if you have a 200.000 files, this guy has to go and look at 200, 000 files, right? And that's a challenge you might have as a local-first thing and not as like a centralized thing, but as a centralized thing, you always have this problem. You cannot get away from it. Yeah. I think you're, you're always paying sort of like for the worst case by having, by like threading everything through typically through the network, et cetera. You can't quite like.

Go off the happy path where everything is like as close as, as possible. It's basically an extension of what you've described earlier with the memory, where it's like, it's not, not, not just to the neighbor's house, but it's literally across the ocean to get that pencil often. So I think there's a lot of similarities.

So we've been exploring a lot now, like here, the data systems you've been working on, uh, on, on previous companies, not just data systems, but that's what we focused on and talking more broadly about the web, the benefits and challenges. But you've mentioned a few times now that you're working on an even more ambitious thing, your own operating system. So before digging more into that. Yeah. I'm very curious what led you to going on this audacious journey of building your own operating system.

I think some of it actually comes from a lot of what we touched on today of quality and software and the joy that I can find that many of my friends can can find or have been able to find. In making software, I think it can be a very like fulfilling and fun thing to do.

And the, I got to say the web platform, I think over the, over the past 15 years, there's been such a relentless focus on scale because it's been such a focus for a huge economy that we have made very conscious trade offs in terms of like joy and ease and simplicity. In favor of scale, like economic scale, technical scale, you know, the ability to have like a million concurrent users on like a thing. So today, if you want to like make a fun, if you want to make a home cooked meal, right.

If you want to build like a fun thing for your friends or just for yourself. I even tried making a homepage with a guest book today. And if you have, if you have like maybe a weekend, you're going to spend that entire weekend just like trying to figure out which of the 200 different AWS services do you need and like, which databases, how do you set it up? And like there are keys and there's so many layers of virtualization that is compatibility and there's this and that and different dev tools.

And, and all of this, I'm not saying this stuff exists because like. People are dumb or anything like that. This stuff exists for very good reasons. Right. And these are reasons for like, you know, scale, like big companies, basically like big things. And I felt like, you know, the time when you can just like either just make a native Mac app, for example, in Cocoa, or like make a kind of a guest book with a CGI bin script, like a Pearl script on an FTP server, like there was some joy to that.

Sure. It wasn't a secure and safe and sure it wouldn't scale as well, but it was for a different, like recent and different audience and so. Three, three and a half years ago, I started really thinking hard about these things, or four years ago, I started, started really thinking deeply about these things and feeling that it's something I care a lot about.

And around the time I learned that Apple were thinking about getting rid of Mac OS, at least Mac OS as we know it, which I think has been a very important player in the having fun making apps. I don't know if you ever wrote a Cocoa app, sort of its heydays, like 2010, 2009 or so. But it was just like a, a, a really like joyful way of doing things. You earlier, you mentioned you need a table view, like in Cocoa, there was a table. There was not three different ways of making a table.

You, there was exactly one way. And that was really performant, very flexible. It did usually what you wanted to do. Everyone used that. There were a lot of really quality cocoa apps, like their companies, like panic that still exists today and still make great software. But there used to be a lot more like companies like that that did really cool software. Yeah. Like sofa, like the, some of the people at sofa now, you know, are working on framer. Who made some incredible backups.

There were Cocoa apps and they all felt good. And so at the time I was like, I thought, I thought a lot about this. And then I decided to leave Figma where I worked at the time and go and, and try to do a little bit of research, trying to figure out like, what, what, what's going to happen five, 10 years from now? Like, are things better? Where are things moving? Where are things going?

And, uh, and that's, I think when I saw sort of like a couple of possible futures, uh, and one of them I got kind of excited about. Yeah, and I think that shows already in the name for, for your project and undertaking playbet.

I think there's a, there's a, um, a person on Twitter called Anselm, who I think in his bio has like, uh, Something along the lines of like, uh, work doesn't work play works, or I think something along those lines, but that really resonates with me where, like, if something feels like work, I don't like it, but if something feels like playing. Then this is where it can be most productive and I can do my, my hardest, what other people would describe as work for me, it's not work for me.

It's just joy and playing. So your focus with the name already, Playbit, really resonates with me. And also just how you framed is like software that feels good. I think that's something that I'm really striving for. And that's rather the exception than the rule today. And I think building a foundation where that is just the default software that feels good, feels amazing. So I would love to learn more about Playbit. What is Playbit and what is your vision for it?

So Playbit, imagine that you have that kind of app kit you were talking about before. Right? So you write a program and that developer experience is pretty similar to what you have today, but you know, it's, it's vastly simpler. And every time you hit build and run, imagine if you use Xcoder or Visual Studio or something like that, you kind of have, you can change a line of code. You can hit command R or something like that. And you try your app out and you, that's kind of how you iterate.

Every time you do that, you also have a web version of that app. It's kind of a Figma. Grade. Type of web app, right? So, and so Playbit is an operating system. And I think, uh, two big challenges with trying to build something like an operating system or platform is one, you're asking people to go to some like foreign planet and asking people to go to a foreign planet is always going to be, uh, you're going to have a huge drop off rate where like, it's just like a very fundamental human thing.

The things that we're, they're familiar. We're. Much more prone to approaching things unfamiliar. We're kind of naturally afraid of them. Uh, so we survived the bears and tigers and stuff. Right. So that's what, that's one problem you have. And now the problem is like a chicken or the egg or kind of a bootstrapping problem, right? If you're to say, well. Let's get some people like on this platform who like build programs for it. Who are they building those programs for themselves? Right?

How fun is that? In some scenarios, the answer has got to be, Oh, that's fine. Because like, maybe I'm building up some tools for myself or for my friends who are also on this platform, but I think this is also a huge hurdle. And so the first one. I think it's really, it's really hard to do something about if you make it too familiar, then why even bother making it? Right. If it's just like something that exists, like why even put the effort in?

If it's too strange, like, I don't know if anyone listening here used Google wave back in 2009 or whatever it was. I think that was like, it was too novel. It was a great idea, but it was just like too strange. You know, you got to hit the sweet spot there of being like novel enough. So that it matters that it exists, but still have some familiarity. So it's not totally like scary to try. The other part I think is kind of important and fixable.

So again, kind of what I was talking about with Playbit, you make this app and we just kind of cross compile it like, you know, the compilers is capable of compiling to native code, right? x86 or x64 and just like in an ELF executable. I think you're kind of macOS. app thing. You just run it and you just zip it up and send it to a friend or whatever you want.

And then the other thing you get is a, is a folder with like an index that HTML file that just contains like a web assembly version of this. So our GPU API or like our graphics API is web GPU.

So you can do full compute, you can build some AI and train ML models and stuff on this, you know, it's like you can really use the GPU through this, which is not possible through WebGL, but there's no other levels, like, although we're using the Linux kernel, it's kind of private as much Linux as Android is Linux. So not a lot of it is Linux, but we do use the Linux kernel. And so you could say, well, I can just use something like Vulkan to instruct my GPU.

And that's a possibility, but like in the ethos of some of what you and I have been talking about before in Playbay, we want to like reduce the number of choices that you have to make, and we want to be. We want to be very careful about like what we sort of introduce as like a choice or like a path. And so we're starting with the only way you can draw things to the screen is through web GPU. That's it. And so of course you got a full file system access and all that kind of stuff.

And when you're running something on the web, like we have a translation layer, essentially something that, you know, it doesn't emulate a Linux kernel. You don't have the full feature of, uh, of like a Linux kernel on the web, because that would be too slow. Instead we have sort of like a system layer. System call, like layer that emulates that and translate that to the web platform. And certain things are just not possible on the web, right? So there's gotta be some sort of like limitations.

So is my understanding correct that you've drawn the, uh, analogy to Figma where me and many others, um, I'm sure like first tried out Figma in the browser were blown away from it, but, uh, by, by, but they would have never, really bothered to install it in the first place, unless there was a really good reason, but the web brought down the barrier to entry by so much that this is where you fall in love with it.

And then when you use it more regularly, you install it actually on your, on your real machine. So is there like a similar. two step process there to Playbit that maybe the first time you interact with some Playbit apps is in the browser, but then the next big step of commitment is not just downloading a desktop app, but, uh, actually like, uh, flashing it on to your computer. Is that sort of like the two steps? Not quite. I think we're a little bit more pragmatic or I believe we are at least.

So Playbit does, you know, I can boot it on hardware, but that's not our goal. In five years, yes, you can just like put it on hardware, boot it on hardware. We're maybe a month or so away from starting to, um, starting to open up for like an early preview access to Playbit. And the way that works is we have a Mac app and a Windows app. Um, then you just like download and run like a video game and the user runs full screen. And it contains like a virtualization environment.

And so you basically a startup and it's just play a bit and you can use it as like, you know, on your current computer, we're not asking you to like, get a second hard drive and do installations and stuff. None of that who wants to do that. And so one way of thinking about it is like. Another one, another way of thinking about it is like, uh, uh, a developer tool or like an authoring environment, or even something like a fantasy console, like peak weight or something like that.

Although Playbit is more, you know, as, as, as very different like aims and the. Yeah, and the applications that you build, let's say you make like, I don't know, a guest book, right? Or something like that. Like how, how does that work? Sure. We can make a GUI kit and that's fine. It's a lot of work, but that's just one piece of the puzzle. Like where are your messages stored, right? How do you authenticate people? Like all this kind of stuff. And that's also part of playbits.

And so the whole operating system is like local-first from the foundation. Early on, we explored, could we do like the thin terminal play, right? Of like, we have a server somewhere. That server actually runs the computer, we send a video signal over, it turns out that doesn't work. I mean, there's like two aspects of it. We can talk more about it if you're curious, but the speed of light is like pretty slow actually.

And the human cognitive center has like a limited, has some interesting features. If you do this with like a, a video game pad, and if you use something like PlayStation, the latency is actually quite high, even if the PlayStation is right in front of you, like 100, 200 milliseconds. And that's fine because like, we have this, you know, we have this kind of coalescing, like Nagel algorithm, like thing in our brains that can, you know, synchronize audio visual input and other sensory stuff.

Right. To make that feel like it happened at the same time. Although it didn't like someone clapping their hands. Like we, we see the clap at the same time we hear it, but obviously we'll technically we see it beforehand. And so that ends up just like not working out the thin terminal thing. And so, yeah, so Playbit works when you're offline. And one of like the things that we really believe in is the software should live for, for a long time. So it's kind of an archivist mindset in a way.

And this is like a secondary thing. And, and some features won't like work this way. Yeah. But we say you should be 50 years from now, Playbit might not exist anymore. Maybe it's not developed anymore. There are no servers online. You should still be able to like boot up Playbit and do something and get to your stuff. If it's to like migrate it out of there, or if it's because you want to continue using it, you That should always be possible.

So those are 2 of the 2 of the main drivers of why it's local-first. And then the other part, when it comes to data is that it's also fully multiplayer. So play with computer is this sort of like, it's essentially a virtual machine that transcends your hardware. And so it's because it's local-first we can synchronize it across all the hardware, right? And we can back it up on a central computer somewhere. This is one of the things that wouldn't be available in, you know, a thousand years.

And that means like, if you know, if you lose your laptop, maybe you drop it in the sea or someone steals it or something like that. And you go and buy a new laptop and you sign into Playbit. Everything is back there. Like the window position, text selection that we talked about, like Sublime I was speaking about before. And that also means that you can, you can have many of these computers. And so we have this concept of workspaces. They're basically virtual machines.

And one of these computers you can share with your friends or with other people. Yeah. And then you have essentially like imagine Figma multiplayer, but like on the operating system level and these facilities like this data syncing facilities and stuff is available to, you know, as a first party API, like for like application developers. So you write your guest book, as I was talking about before.

Then you just put messages in there and authentication will be, you know, maybe that's a problem that you have to solve, but everything else, data storage is you just get that for free and it's just local-first. And if Playbit is gone or the servers don't work, like your guestbook will still work on your app. Like, so it's not sort of bound to Playbit itself. That is incredible.

I mean, I can't imagine a more audacious path forward and a foundation to build, but, uh, the way how you've described it, uh, makes, uh, makes perfect sense. you still get the benefits of the, the web in terms of distribution, but you're leveraging the most powerful way of building web apps right now.

By leveraging web GPU, et cetera, taking care of all the data in a local-first way and unlocking even more power by letting you use the, like the virtual operating system there as a full blown native app on your given operating system, hosting operating system at some point, like real operating system. I love that progression and it already unlocks from, from day one, a lot of utility. So I can't wait to see what a Playbit app will, will feel like.

I'm also curious what it will both in terms of feel like to use, but also to write. Can you share a little bit more about, uh, the local-first aspects of what it means to build a local-first Playbit app?

Yeah, we have, we have these like three types of data. This is kind of in the conversation about like what, What information is there? How do you like categorize information? What guarantees and sort of like attributes does this different information have? Right. So you have something like an email client. Let's say we have like what email is currently being viewed. What text is selected? That's one type of information. Another type of information is like.

What is in the email, what is written in the email, right? Who sent it, which time was it sent? And, uh, there's, there's other kinds of data too, but sort of like thinking in this way, right now we can add a third type of data, sort of like a very ephemeral, like imagine that there's a friend in there, so there's a second cursor on the screen, like where the cursor is, who that is, like that, that's another piece of data. I think these like have different, you have different expectations about.

Where it is the synchronized hot, like what reliability of this is, what the latency of this data is roughly speaking, like what's in the email, what'd you expect there to be correct, but it can take a while to load. I'm exaggerating here now, obviously everything should be correct and be fast, but you gotta make trade offs the cursor, right? It's sometimes you can drop a frame, so to speak, and it's not that important. Right? Like you can lose this information. You don't have to cache it.

The information about like what's selected and like scroll positions and stuff like that is, is things that can have lower integrity than sort of like what's in the email, right? And that information might, you might not want to share with others. Right. Like what's, what texts do I have selected? Maybe that's something that shared in a different way. Right. Let's say you have two people looking at the same email. Then if you shared the tick selection, like what does that even mean?

Right. If I want to select something, I would change your tech selection. That's kind of like weird. So you've got to treat that differently. So there are, there are different categories of data. One thing. So more concretely to your question, it's like when you write a Playbit app, there is some of this information that's just handles for you automatically. So things like the sort of scroll position and stuff like that. All handles for you automatically, you can override any of that.

And if you wanted to manage your own scope position, of course you could, then there's an API and we call this like game state because you know, often we talk about, and we look at video games, because I think there's a lot more to learn there than, uh, comparatively to utility apps. So game state is essentially like the state that the program has that's unique to the program.

And earlier in this episode, we talked a little bit about like, uh, like almost impotence mismatch or a match between sort of like the, the fifth of your problem and the database and stuff like that. And so you have a similar problem here that, like, we, we could just give you, like, I just like put things in a SQLite database and they will automatically just like. Be synchronized, right? The problem is like, that's not possible. That is not, not possible because like it's hard technologically.

That's just impossible because like a real life human level. It's not possible, right? We cannot possibly know. And the same thing is true for like a file system. We cannot possibly know what these like chunks of bytes mean without trying to interpret them, in which case you're not on a file system level anymore. But on a document level, and so to like, solve this problem, we choose to not solve it. And this that give you the tools to solve it yourself.

And so imagine that we, we make a game like a tic tac toe game and we can play that together. It has like, it has a, it's a turn based game, right? So 1 and it's a 2 player game. 1 player is across the other 1. It's like a circle. And. Let's say you start out and you do, you click somewhere, you can choose, right? And then it's my turn. And so now game state in this example is whose turn is it?

What sort of like what on, on this kind of like three by three or nine by nine or whatever you end up doing on this game board. Like, what is the state of that? Which cells are empty? Which are currently like filled? What are they filled with? Right. And then you have conditions and this is not part of game state. It's like. Did someone win? Like, Oh, who is leading? Like, this is stuff you derive from the game state. And the game state itself is essentially a key value store.

And on the key value store level, we give you the, we give you transactions. And so if you say like, uh, change this to the, to that and change this to that, and you can make up your own keys and values, we guarantee you that Those things are merged with all the other clients with the same result within that one transaction. So we give you this kind of like primitive, that is a key value store with like CRDT transactions.

I don't know what to call them, but this is kind of like a notion of transaction. And on that level and beyond that level, below that level, We as like, we had all of the diffing and merging and syncing for you automatically. Then of course we finally, we give you like a, the lowest level. So the highest level is like, you don't use any of these things and you get some limited multiplayer functionality and the scene graph of the whole, like the whole desktop, if you will, is synchronized always.

And so that's the highest level. That's the simplest thing. You can write like a 20 line program that has some limited multiplayer functionality. And it's fine. All the defaults in Playbit, like in our APIs, if you don't opt in for something, you will get something that we think is a good default, right?

If you don't pass, if a function call has like a flags attribute or argument, if you just pass zero for that, we will like, instead of giving you a window, for example, sorry, this is a tangent in macOS. If you say. And this window, create a new window. It's the API for creating a new window. If you set flags to zero, like no special flags, you get a window that's useless. You can't close it. You can't resize it. You can't like do much with it at all. You can't even move it.

And so you have to like set certain flags to get the default window. And, and it's kind of like folk knowledge. You just know which flags to set and which flags not to set and the caveats. In Playbit, we're trying to like have an ethos that is like, when you don't opt in for something, you will get the thing that is that you probably want. And yeah, so this goes for the data layer too. And yeah, we'll see. So you got these three kind of like, I want to start easy mode. You just give me a thing.

It will be multiplayer. It'll be pretty fine. And then you say, actually, I want to like have my, the state of my app, my game to be multiplayer so that two people can play tic tac toe together. Then you use this like fairly straightforward, but still you got to model your data now. Um, like this database and then at the very lowest level, you get something that is kind of like a socket, but we, we handle like encryption and you know, the actual connectivity of it for you.

So you can say, give me a connection to the other instances of this app. And now your app can, you'll send like arbitrary data if you want to do something really like wild. Right. But now there's no different emerging. It's, we just give you an ability to say, send bytes between, um, between different like instances of your app now. Got it. So that's how, how data flows. Um, I'm curious, what is the authoring experience for me as a developer?

Um, do I have to use like a certain programming language for that? Can I choose between different programming languages? Is there, can I bring some outside technologies, for example, something like react, or is there sort of a bespoke way to do all of that? You have to use our own flavor of Fortran. That is backside. You know, no, it's a, so. Um, This is obviously an important thing. I think that there are two paths that you can go.

You can either say, here's a blessed programming language, and this is what you use, or you can say like, bring your own language, here's like a minimal API. And I think the two like common examples of this is like on, uh, on iOS, you got, I guess a little complicated. Now you get Swift and Cocoa, but for a long time, you had just Objective C. And if you want to write an app, you write an Objective C and you use these libraries.

And there's some flexibility if you want to do something else, but it's like pretty much zero. And then you have something like BSD or Linux where you say there's a syscall. It's essentially like a single function, uh, that's called syscall, which is really just like a CPU instruction, but it's a syscall and you give it a number and the first number represents like the thing you want to do, like open a file, close a file, read some bytes, right?

And then you give it some number and it's a fixed number of things you can give it arguments essentially. And that's the entire API surface. This is one function to your entire computer. So these are two extremes and with Playbit, we're closer to the second, because that gives you the flexibility of if you want to use Python or Node. js or BUN, you could do that. And I think that's important. Some people have opinions about this.

So Playbit has a C A B I and B as in, as in Bob, as a binary interface, basically any programming language today can interface with a C A B I. It doesn't mean you have to write it and see the developer experience currently in Playbit. And so, you know, Playbit does exist and we use it day to day and we develop Playbit inside of Playbit. It's kind of weird sometimes is we got something that's a little bit like Xcode, something that's a little bit like developer tools, like on the OS level.

And so in our version of the finder or windows file explorer, there's a button called new app and you can click this and like a new app is just made for you and it's called like, you know, new app that app and inside it, like, you know, there's a main dot C because we got a C compiler and system. So it's main dot C and it's already ready for you.

And when you, when you create a new app, there's another toolbar button, like in the file browser, this says build and run it, click build and run and your app starts up. And there's, you don't need to use terminals or anything like that. You got standard out and standard error. You can get those kinds of things like in, in a more friendly sort of developer log. We have an inkling to this now, but there's also a couple of ways to like, look at the dom.

So we have the scene graph that your app has, right? You can inspect that. You can inspect actually the scene graph of the entire desktop if you wanted to. So that, you know, this opens up some very interesting things for accessibility, for example. But anyhow, so the developer experience is very much like, it's very like straightforward, very lightweight, very opinionated right now. So again, you click, you click a button to just create a new app.

And you can just rename it by changing the folder name. And if you don't want to even open a text editor, you just click the building ride button, which is the same place your app is built and is run. And it takes like a couple of milliseconds. And now you can just like, and it's just going to say, hello world. It's just a window that opens hello world. And it has closed buttons, you know, it's very basic. And what you can do now is that you can open the source file.

In the text editor, it's only in graphical environments. And now you can, you can change them, right? You can change, for example, like where it says hello world to say, you know, hello, Johannes. And then you hit build and run again. And now like it restarts and says, hello, Johannes. And then, you know, there's some generated documentation for the API. There's functions, of course, for, you know, we've got.

Grid functions, all of the kind of really gooey things you might expect, you know, pop up menus and scroll bars and radio buttons and all of that stuff. And if you want to bring in libraries and stuff, you can do that. And if you wanted to use Python instead, then you will call these functions through the C ABI and FFI functions in Python, right? So that's kind of like the, currently the developer story in PlayBit. That makes sense.

So you've like laid out the absolute foundation and that allows for a lot of layers, optional layers to be built on top where you want to follow like a certain flavor of app development. And I think that also allows an ecosystem to be built around PlayBit. But I think the new level of primitives and the, this new, um, More like 2024 foundation that you're laying where you get things that are, that was probably shareable by default, that's collaborative by default.

So, uh, a lot of the local-first aspects, what makes local-first software great, having that be baked into the foundations of an operating system. Uh, that is not something I would have expected in 2024 to already exist, maybe rather 2040. So you make me feel like living in the future. But I got to say, I think that there, it's almost a logical conclusion when I'm going to come to here. But I think, first off, I want to say, I think, I think of Playbit as being a platform.

I think it's very interesting to talk about, like, what is an OS? Like, what is a platform? We've been talking about the web a lot today for really good reasons. And the web to me kind of smells like an operating system, you know, in a way, and it is a platform. And I think Playbit similarly, although it is like, technically speaking, a real operating system, you know, it's like manages memory and hardware and all of that stuff. I think, or I hope at least it also can become the platform.

That has a primary environment, which is, you know, its own OS and a secondary environment, which is like other systems, like the web, right? Other platforms. And the logical confusion I was mentioning, thinking about what, what does a platform OS do? Why, why does it exist? Why do we have them? Historically and an operating system does really is two things, right? One, it abstracts the hardware. It used to be so. That if you want it to write the disc, you would have to like write the disc.

You have to have different code depending on the specific hardware you're writing, which is kind of insane. But that's how it was. And then someone was like, Hey, what, what if we have like a layer in between? So like you say, right to hard disk a or hard disk B and you use the same like function calls, even if this is like a, you know, a hard disk from this manufacturer, if it's like a floppy disk drive. Right. And that is like, Those are like drivers or whatever.

That is like one important role that OS serves. the other category, it's very interesting. It's like the OS then needs to provide services for like the tools that run on top of it. And this is where I think we as like, we as kind of like set back in our chairs, you know, in, in like the late nineties and said, Oh, we're done.

You know, I mean, iOS is like built on macOS, which is built on next, which is built in the eighties and we have windows, which like still has like some parts in it that are from, you know, the nineties or maybe even further back than that. And so a lot of these OS's that we use today, and even like the windowing, like the compositing windowing system is sort of like an ancient idea, right.

Of like, that comes from like X11 and stuff like that, or, you know, even earlier stuff, of course, X11 was not the first, but, you know, you have a window. And you have a window and these are two like bitmaps or textures, if in GPX or either. And each window is like a process or whatever you want to call it. And they like use the same library code to draw the same button into their bitmaps. And then on the desktop, you put these bitmaps together and that's how you have windows.

I was like, gee, the huge problem with this is that how do you like introspect what's on the desktop? How do you do things like accessibility? How do you, how do you like, uh, debug something that goes wrong? That crosses the boundary of two windows. Like you, it becomes really hard and you end up with this like really weird patched on things at the, at the end. And so I think that the services argument, right?

Like then we think about, so why is it so that today you look at someone who used a Mac book And what apps do you use? These are web apps that they use. They are not native apps, but they have this like Mac OS running there. Why aren't there Mac OS apps? I think it's because Mac OS doesn't provide the things that people want, right? Developers want. I want to be able to just like fetch the thing from the network, right?

I can do that one line of code in JavaScript or like a fucking million lines, excuse my French, of codes in, in like a Mac OS native, right? There's just like a, there's a mismatch between the services that an OS provides. Another thing is like, like payments or like subscriptions or whatever, like revenue. Let's say that I read a little thing. And it's a hobby thing. I can't spend too much like time slash money on it, but I still spend a lot of like my time and money on it. Right.

Even if it's like, you know, five hours a week and now I'm going to ask people who really like it. It's kind of the shareware model. So like, give me a dollar, like a month, if they like this thing or just like one time. And obviously I'm not like pitching anything novel here, like the, you know, Apple app stores are very successful and everything else that comes after it. But the problem with that is that it is sort of like a monolith. It's this sort of like it's in the planet Apple.

First off, if you want this to work on other platforms, like you can't, it's iOS or nothing. And if you want to market this somewhere else where you really can't, it's in the app store or nowhere else, and you have to build it specifically for them. And there's all of this, this whole list of cabinets is basically like there's a little bubble, you can put it in the bubble. If you don't want it to be in the bubble, you're on your own.

You got to Do a Stripe integration or something that's going to take you a lot more time than you have. And so I think that there's a lot of hobby developers out there who make something truly valuable who will just like, just pass on it, right? They will just pass on the revenue they could get because it's just like not worth building it. So that's just one example.

Uh, multipliers we were talking about is another example, like data syncing, all of these things that like the OSS that we use today, they just don't provide But the web platform does. So we moved to the web platform instead. Yeah. I love that, that vision. Uh, and, and so I've mentioned before that I am trying to build the best of both worlds for like embracing the web, still making the app feel native and, uh, the app also following the local-first ideals as much as possible.

This is really, uh, building an app on the hard mode compared to how you build other apps. So. Um, chasing that quality, et cetera, but it's so hard.

Um, and this is where in the future, where I can just build Overtone on top of Playbit, this is where I can put all of my effort on making the, like spending the quality on like even, even more higher leverage things, and you've been taking care of like the tough foundation that the app is collaborative by default, that it feels more, gives me better primitives.

The app feels native where, depending on where it's running, whether it's running in the browser or whether it's running on, on someone's more, more native environment. So I'm really looking forward to that future. I have one tangent question. Uh, you've been mentioning that you're developing Playbit inside of Playbit.

Looking at this from a similar lens, I'm very curious whether you can already have a browser running inside of Playbit and then open a Playbit environment within the browser running Playbit. Oh, we don't have a web browser yet. If there's anyone out there who wants to join us, I mean, play, but it's like a venture backed company, like, you know, we can pay you a salary. It's like a real job. If you want to come work with us and, you know, put Chrome or Firefox in play, but yeah, hit me up.

Or if you want to work on like GPU stuff or the Linux kernel, we are looking to hire a few people. So yeah, there's no web browser yet. It will, it will be a mind band. Yeah. To like run it inside a web browser, because then you can keep going. It's like you take a video camera connected to a TV and you point it at the TV, you know, you got this like, Infinity mirror effect. Yeah. That's kind of fun. Uh, exactly.

That's what I had in mind, or I think you get the same when you like use like Google meet or something or whatever it's called these days, but yeah, I would like take up that, that job offer opportunity in a, in an instant, if I had the background that fits it and If I wasn't already knee deep in all sorts of other things, but I'm sure there, there will be someone out there who is the perfect fit and I'm sure that's an amazing opportunity.

So before wrapping up, you're all, you're not just building such an ambitious startup, but you're also about to become a father. So I'm very curious, uh, from a personal perspective, like how are you navigating that? How do you balance going after such an, such an ambitious project, uh, and also navigating that becoming a father, raising a family and so on.

I think I've just got a bit of perspective of what I think it's like important. And less important, the more important and worth spending time on. Like earlier in my life, there was one point where I found myself like in a heart intensive care, minutes away from like dying because I wasn't sleeping and I was working all the time. And it was like an absolutely insane lifestyle. You know, I would be partying and I would sleep like basically three hours a night and have two jobs and party.

And you know, one day my body almost like give up and it was died. And that was like a pretty good wake up call. But that didn't fix it. I was still like insane. And so this was before I joined Spotify and it's Spotify. I, you know, I was, I ran the whole design department for four years alone. So, you know, I would do marketing stuff and all of the UI and everything. You just one person, right? There's no other designers. It was absolutely insane. And I didn't know better.

And I worked all the time. And I mean, like basically 24, 7, 4. The first, like, year or 2 and, you know, I paid like a pretty heavy price from both of these experiences and it's, you know, just like a waves on a body of water, you know, the cost and effect, there's a quite a bit of delay. And so I started to realize that.

You know, what the costs have been and losing, you know, friends and, and losing out on like social events and, you know, losing my girlfriend and like, yeah, it's losing a lot of things, losing health and, you know, all of this kind of stuff. And anyhow, so that, that was a long time ago, you know, that was like mid 2000s. And now I think that work is like, yes, it's a part of life. And if you're lucky.

You'll find something to work on that creates a passion in you know, when in the morning you wake up and you think about it in like a good way. If in like, I gotta get make a cup of coffee and like get jump into this layer. That thing I think that is like. All one can wish for when it comes to like work that is like the, if you, if you get to the level, you're like, you've made it right.

If sure, if you, if you still need to make money, that's another problem, but like beyond, beyond that and then everything else in life. So I think as I just have this philosophy that like work is important and it's about passion, you know, if you can make it so, and with play a bit specifically, and I made it very clear to everyone involved in play a bit from like day one that. This is something that will be done on, uh, like, uh, on a balance.

This is not a, I'm going to give up like five years of my life just to make this happen. This is not like a, I'm going to like get rid of my friends because it's more important. And so, you know, starting a family and like moving and having hobbies outside of work is like an explicit goal. And it's the same with true for like our employees that there are no expectations to work. Outside of working hours and compensation does not happen on a time basis.

Not like if you work four hours, you make more than if you work two hours. I think that model is just fundamentally incompatible with this mindset. And that also goes to like, you know, we don't really have sort of like milestones or, or, uh, measurements of like how we're doing. It's more like we have a roadmap and we build things toward it. And we have different areas of responsibility. How well we are doing is measured in like the actual product. Like, can it do the thing, right?

Have we done the thing that we said we were going to do? Like, if, if not, we're not doing well and we got to figure something out. If it does, we're doing well and let's keep doing it. Exactly. And if you have that passion, like getting up in the morning, being super pumped about doing that, that is the, that's the best fuel to get there. Probably even more efficiently than if you'd have like the best product managers who figure out every, every step along the way. I think that's right.

And I think it's like, it's, it's such a nice kernel of an idea, but to build things around, like you think about, okay, now, how do you, how do you create that? Or how do you maintain it? If you have created it, I think that's really hard. And it's a lot of work to make that happen. Right. For once, if you, let's say you like to eat pizza, if you eat pizza every day, pretty soon, you're not going to like pizza anymore. Right.

And so like, if you work on the thing that you're really passionate about, like, Unhinged like totally all the time, very quickly. Will you like burn out or whatever you want to call it? It's not going to be fun anymore. So you lose it. If you don't get to exercise what you're excited about, it will like wane away. Right. So there's like more dimensions to it. Managing that I think suddenly becomes done an effort. It's not like we're working less. We're just working hard on different things.

Right. And so like, you know, the way we work now, sometimes maybe someone like feels like tired a day or like feels like they have a cold or something like that. Yeah. You just don't work that day, just take the day off or, or it feels like, Oh God, I've been like, we're, we have this like memory corruption bug. Uh, we weren't sure. Is it in the kernel? Is it in the compiler? Is it, there was this thing that was lasting for two weeks and we were like, okay, we just got it.

We need to take like two days off and just like, I don't know, read a book, look at a tree, play a video game, whatever. And came back to it and, you know, we, we, we found it. And so I think like, you know, part of this is also taking like a break when you're like, you know, uh, climbing a mountain and it's like really hard. You need to take a break. Otherwise you're just going to overextend yourself and fall down. Yeah. And, but I think it's like similar to food.

It's not just like that besides pizza, everything tastes bad, but there's plenty of other good things that taste really well and you can, you can just Choose and like cycle between them. And I think this also shows in your portfolio work, you've not just tackled super hard data problems or, uh, or performance problems, but you also took like more scenic routes, creating one of the most popular fonts out there, enter.

And, uh, for, for me, I can, can totally see how just switching a little bit of, between those different things can be really re energizing. And I love that mindset and that, that balance that you're striking for. And I think that is, is very on brand for, for Playbit that it should be fun and playful. Yeah. Life is really short. It's much shorter than we think. And we usually don't realize how short it is until we lose something. You know, like a family member or health or whatever it is.

So I think it's never a bad idea to reiterate that like life really is short. And the one thing we all have the same amount of is time, right? That's, I think that's like your body and your time are your two most valuable resources and everything else is just secondary.

Right? Well, thank you so much for making the limited time that we have more joyful. by great software and, uh, thank you so much for taking this huge amount of time today out of your day, uh, to share all of those stories on the podcast. Thank you so much. Thank you so much, Johannes. This was super fun. I love just talking about these things with you. If it's on a podcast or over a cup of coffee, and I hope we can do more of this in the future. Awesome. I couldn't agree more. Take care.

Thank you. Bye. Thank you for listening to the localfirst.fm podcast. If you've enjoyed this episode and haven't done so already, please subscribe and leave a review wherever you're listening. Please also tell your friends about it. If you think they could be interested in local-first, if you have feedback, questions or ideas for the podcast, please get in touch via hello at localfirst.fm or use the feedback form on our website, special thanks to Expo and Crab Nebula for supporting this podcast.

See you next time.