Local-first, y/n?

Welcome to Changelog and Friends, our weekly talk show about mostly local. A big thank you to our friends and partners over at Fly.io, the home of Changelog.com and the cloud for developers who ship, that's you, that's us. Check them out at Fly.io. Okay, let's local first. What's up, friends? I'm here with Kurt Mackey, co-founder and CEO of Fly. As you know, we love Fly. That is the home of Changelog.com. But Kurt, I want to know how you explain Fly to developers.

Do you tell them a story first? How do you do it? I kind of change how I explain it based on almost like the generation of developer I'm talking to. So like for me, I build and shipped apps on Heroku,

which if you've never used Heroku is roughly like building and shipping an app on Vercel today. It's just it's 2024 instead of 2008 or whatever. And what frustrated me about doing that was I got stuck. You can build and ship a Rails app with a Postgres on Heroku, the same way you can build and ship a Next.js app on Vercel. But as soon as you want to do something interesting, like as soon as you want to, at the time, I think one of the things I ran into is like I wanted to add what used to be like kind of the basis for Elasticsearch. I want to do full text search in my applications. You kind of hit this wall with something like Heroku where you can't really do that. I think lately we've seen it with like people wanting to add LLMs kind of inference stuff to their applications. On Vercel or Heroku or Cloudflare or whoever these days, they've started like releasing abstractions that sort of let you do this. But I can't just run the model I'd run locally on these black box platforms that are very specialized. For the people my age, it's always like, oh, Heroku was great, but I outgrew it. And one of the things that I felt like I should be able to do when I was using Heroku was like run my app close to people in Tokyo for users that were in Tokyo. And that was never possible. For modern generation devs, it's a lot more Vercel based. It's a lot like Vercel is great right up until you hit one of their hard line boundaries and then you're kind of stuck. There's another one we've had someone within the company,

I can't remember the name of this game, but the tagline was like five minutes to start forever to master. It's sort of how we're pitching fly is like you can get an app going in five minutes, but there's so much depth to the platform that you're never going to run out of things you can

do with it. So unlike AWS or Heroku or Vercel, which are all great platforms, the cool thing we love here at Changelog most about fly is that no matter what we want to do on the platform, we have primitives, we have abilities, and we as developers can charge our own mission on fly. It is a no limits platform built for developers and we think you should try it out. Go to fly.io to learn more. Launch your app in five minutes. Too easy. Once again, fly.io. We are here with a couple of Local First aficionados and frequent Changelog guests. I think for both of you, this is your fourth appearance on our pod. So welcome back. We have Johannes Schicklin and James Long. What's up guys? Not much. Great to be here. I'm super excited to

be back talking more about Local First. What was my third time? I know I came and talked about

actual, and then I talked about something else. I didn't know this was my fourth. Hitting me on

the spot. Sorry about that. So for a time, for a little while, we produced and shipped the React podcast here on this network. So you were on Changelog Interviews 242, The Burden of Open Source, and then you were on the React podcast talking about React and Electron, which we published, and then actually Open Source talking about actual. So with us, with Adam and I twice,

but on the network three times. Got it. Awesome. Technically with me several times. Nice. And you just once, Jared. Fair. Good fact checks, guys. Cool. Fact checking you on there. Johannes,

do you feel good about three? Does that sound right to you? Yeah, sounds about right. I guess one or two maybe about Graphcool, Prisma. Yep. Another one about something afterwards. I don't

know. About using the effect library. Are you still an effect fan? Oh yeah. That was on JS Jabber though, I think. That's JS Party, which is a far superior JavaScript podcast. No, just kidding.

And we're just doing conflict resolution right here live. That's right. All of our podcasts are

resolved in a CRDT. So I just use that in a way which probably showed that I don't know exactly how it works, but let's move on swiftly. We want to talk about local first because we have, of course, Johannes, the purveyor of local first.fm. And James, you've been doing things locally in the browser for a long time, pushing the limits. I would say both of you. And James recently posted a post, which is what you do now. You don't tweet anymore. You post in which you said that after a long time of trying it, doing it, et cetera, you don't think it's the future for all kinds of apps, which there's a question about, is that the case? Now it's a blog post in progress. Whenever I see somebody with a blog post in progress, or it should be a blog, but it isn't yet. And they're talking, I think let's have an actual conversation because this will help all of us think through things and iron out our thoughts. And so I want to start there, but before even that, I think the definition of local first is also ambiguous or perhaps up for debate. So maybe we can get on the same page about what a local first web app is. And is even the word web supposed to be in there? I think it is, but Johannes, maybe start there. We'll see if all four of us agree about what local first really is.

Yeah, I would say that web is not a necessity of local first. I think local first has kind of so far gone through two rounds of like a definition attempt. The first one was through the Incan switch essay, I think in 2019 or so by Martin Kleppmann, PVH and so on. And that was outlined in a set of seven ideals that define what local first software is. And that's along the lines of like no spinners, the network being optional, et cetera. And none of that is really about any platform. I think at the end of the day, software runs wherever we use a certain device and at some point it might run wherever. So the web is just a very common platform. And then the second attempt to define what local first software is was last year, or technically, I guess this year from Martin Kleppmann at the first local first conference, where I think he tried to simplify it a little bit more what local first software is, where I think he said it along the lines that a computer that you're not aware of even existing should not prevent your software from running. And I would say that this is, we can take it apart what that definition means, but I think it's kind of intuitive. And given that a lot of software runs in the browser, I think that's where particularly our mind goes. And I would say it's particularly hard to build local first grade software in the browser. It's somewhat possible, sometimes not fully practical. And I think we'll go deep into that. But local first has nothing inherently, is not inherently bound to the web. James, anything to add or subtract, agree or disagree with what he's saying there?

No, I think that all sounds good. I think the web is definitely kind of anti local first in some ways. And so we're the community, it feels like we're kind of pushing it back. That's why we have to push the boundaries because it has a lot of boundaries around doing things locally. Because I mean, honestly, it began as this client server model, which is a really powerful model. And so we're trying to figure out how to kind of pull it back from that. But no, totally agree. I think these kinds of terms are helpful for conversations because it's a very simplistic term. It's like a code name almost. But these things always naturally are actually pretty ambiguous and difficult to nail down specifically. And I think it's worthwhile to have conversations to actually define the nuances a little bit more. And they can also be under the umbrella of local first. I don't think we need to, you know, mince words too much. But it is worthwhile to kind of like take a step back and actually talk about what that means exactly to different people.

Right. And I might also add that I think local first is often seen as sort of this binary thing. But I think that's, at least as of today, not too helpful of a perspective. I'd rather encourage people to think about local first as like a aspiration and a spectrum that you can take many steps in that direction. Would you have reached all the seven ideals of the local first manifesto? Or would you fully already nail the definition of like, if another computer stops working, does your software stop working? Probably not, but you're already well on your way there. Software like linear, et cetera, is not local first by definition, but it's way further along the lines there compared to other software. And I think that's what it's all about. Like being aspiring to building better software. And I think local first is a way how we can think about

getting there. When you have the question, what you have to follow up with why. So we know what it is now for, we all agree. Why go local first? Why aspire to the spectrum? Why aspire to the binary?

Why aspire at all towards this local first direction? I can start with why I, so I sort of

naturally fell into this around 2017, which was around the time the, I think the essay came out like a little bit later after I had started going down this path and it sort of crystallized a lot for me. But yeah, when I was building Actual, which is a personal finance app that I built and tried to sell for a couple of years, it actually met most of the principles of the original one, where it's actually completely local first. Literally all of your data is local and the server is a super dumb server. And in that architecture, you can even like end to end encrypt, which felt appealing. I think it was more appealing idealistically like, or like ideologically appealing because it was just like, hey, like it's your personal finance data. It sounds cool to encrypt it. I think a lot of my evolution from this is like, nobody really cared that much about that. And so I'm sort of reeling back from some of the like deep research I did back then. But anyway, the main reason I did it was for performance and just like simplicity. Like it just felt really cool to just like write SQL queries and have this SQLite database totally available to your entire local machine, where rather than like an HTTP request that came back with like most of the fields, but some of them were missing because they needed to join some table that was on a totally different sharded database in a separate place. And so then you have to do a follow up HTTP request and GraphQL sort of follows some of this, but it's GraphQL just feels like super overly complex. And when you need to do mutations with GraphQL, it's just like really locks you into this like specific format. And then you're always like waiting on loading spinners and things like that. And it's just like the super compelling simplicity of like, hey, SQL query, get my data back within like five milliseconds, render it, and then like subscribe to that data. And it's all completely local and you don't need like a web socket to a remote server that could die, like die any time now. So that was my main motivation. And I think that

might hold for your reasons, Johannes, is that right? Yeah, I think I want to very much subscribe to what you've already said. I think there's two major perspectives for me. One is the perspective from me as a builder who wants to build a product for end users. So what do you want the experience, the end user experience to be? And obviously performance is one that very, very quickly comes to mind what I want the app to feel like, like it should be a great user experience. And I think local first, that's a really high bar. This is where software like linear, et cetera is. So that makes it so clear that this is just like a high quality app and local first helps you get there. But the other one is from a developer experience perspective and not just even from a developer experience perspective, but also like you've mentioned the word simplicity. I think this is what typically ruins both the user experience and the developer experience that we're just drowning in complexity. And local first for me was sort of like a promise for like eventually we can do much better. We can build more ambitious apps in a way that is actually simpler to build for the developer. And this is a promise that I still strongly believe in. We're not quite there yet. We've already made a lot of progress in that direction, but that is what is for me all about is like that, like we're drowning in complexity. Typically the more ambitious of an app we are building and local first gives me hope and gives me a promise that we can do a lot better, that we gain simplicity for some category of apps. And this won't hold for all category of apps. This is what we're also strongly agree with your point that you've shared local first is not the panacea for all apps, but for some apps, it can be a much better trade-off. And this is what's got me so excited about it. What category of apps do you think that applies

to? Because when it comes to simplicity, I think the mental model for developer that I operate a server and a client makes a request to my server and I do whatever I'm going to do. And then I respond and the client renders it. To me, like it's hard to get more simplistic than that, but that admittedly is a very basic application. However, there are some applications where it's like you're reading a newspaper. Does it need to be local first? Because the actual newspaper content is not in the device, it's on the server. And so what good is it without the server? So I'm sure there's like, I mean, you keep mentioning linear. It's probably like hit out of the ballpark use cases. It's probably like pretty good use cases. And that's probably like maybe what James has been finding is like, well, is it the future for all apps? He doesn't think so. So in your definition, Johanna, so your thoughts, like what are like the greatest local first apps? And then what are some good ones? And then maybe we'll get to ones where it's like, yeah, it doesn't really

make sense. Yeah. So I don't disagree with James that it's like, it is not the future for all apps. I do think it could be a better future for some apps. And so that how I would categorize this as a starting point, at least, is like anything that really centers around my data as a user, or as a small group of users. So for example, a note taking app, I think that's a very prototypical example for where local first makes a lot of sense where it's simple to build. And where it also from an end user perspective makes so much sense, because all the data that's ever created in this app, I probably created, I've written down by myself at some point or dictated, et cetera, all the data is coming from me, very opposed to like a newspaper where someone else has written everything. I'll never gonna read all of it. So that I think is a anti-use case for local first, anything that feels like a social network or newspaper, et cetera. Anything where a individual user, small group of users have created some data, I think that is a very good use case. This is where you have like, if you think about the data as a graph, you have like, it's a very highly connected dense graph. And it's very easy to, in terms of the quantity of the data that it actually fits on the devices that we're using. So this is like a rough idea of what makes a good fit for local first app, but then it's also like scales a bit beyond that. So for example, if you wanna not just work on some data by yourself, but maybe in the realm of like a smaller group, let's say your family, or let's say your small team, your medium team, and the larger it gets, the less of a good fit it possibly is for local first, since trust is another matter. You're probably trusting all the members in your family. You might also trust all the members in a small team. Once you're like a 5,000 person company, you have like legal obligations, et cetera, that you need to have like strict boundaries in place, and someone needs to be able to remotely delete all of the data. This is where it gets a little bit intention, but the more it is all about like a user's data or a small groups of users, I think this is where it's a great starting point.

So James, you said in your post that you think it's cool for some very specific apps like Obsidian. You use Obsidian as an example, of course, this is an app that's operating on your local markdown files, and then also building from there and doing additional stuff. You built a personal finance app in the browser, right? Or with web tech. And that sounds like something Johannes is very much defining and you gave it a shot. So curious your thoughts on that being applicable in that

circumstance or what you found with regard to what sounds like a good use case for a local first,

according to Johannes and makes sense to me. Yeah, I think, I mean, it's just hard because that kind of reasoning still resonates with me. It's super amazing to just like have this three megabyte SQLite file. And for me personally, like I have maybe eight years of transactions is maybe scaled up to five megabytes. It's not ever going to be remotely a problem to have this all local. And to me also, it was really compelling at the very beginning. So I actually started with web tech, but it was wrapped with Electron. So it was a fully native app. So I didn't have to be actually in the guardrails of the browser. So it literally used native SQLite. There was a SQLite file locally on my computer. And what's so cool about that is I could just like fire it up from the terminal and just like run some select queries. The problem, there's a lot of things that kind of have tripped away at that for me that have made me kind of take a step back to kind of rethink some of it. Even for some of these apps that do seem at the upfront better, one is like the web is the biggest, is the distribution king. You cannot get away from the web. Like I, it was very clear early on that like downloading this huge 300, it wasn't 300, it was like 75 megabyte Electron app. And everybody was like made fun of you for building this like web thing that was so new. I was just like tired of having to deal with all of that stuff. And also the notarization and like actually deploying things through the native stuff. It's just like, it is the worst thing I've ever experienced. I also built like React Native apps too, which is like biggest regret of actual, which is like overextending myself. But for every single thing that you distribute it to, you have to like notarize it. You have to pay money to actually distribute it through it. You have to like get a certificate for Windows. I had to get this other like weird Sectigo certificate chain. So it was a lot. So I deployed to the web and I could make a bug fix and deploy it in like three seconds. It was amazing. The problem there is like I lose the local SQLite file capability, right? So they do have this new technology. So I built Upstart SQL, which was like this SQLite abstraction over IndexedDB. I still think it was like super cool. Now they have this like OPFS capability with like the file system access API. So you can do real files, but they're sandboxed within the browser. I don't know. They might exist somewhere locally, but I'm pretty sure you're not really, I don't think they do. I think that they're compressed in a weird way that you can't actually just have a local SQLite file. They give you basically like a virtual private file system. And so you lose this ability to just like, hey, have a local SQLite file. So you have to compile WebAssembly down and lose some performance. I don't know exactly what that overhead is, but it's slower. And Johannes, you probably have way more experience because you've done a lot more of this like more recently. So I'm curious what that perf is. We can talk about that in just a second, but it is a little, there's going to be a little bit of overhead right there. Like if it's C running, I can fine tune it. I can tweak it, but I mean, web always blows me away. Like maybe it actually matches the native speed now. But there's also just the fact that your data is still sandboxed in this thing, right? And so that was one thing is that I lose the ability to just like locally query stuff. And so now if I want to do that, well, now I have to like, if I wanted, like, let's say that I had a script, right? That like I've had this idea that was kind of this weird idea where I think I saw this person on Hacker News a couple of weeks ago. He had this printer that every day would like print out something. And I love that idea. And I'm actually going to do that. I'm going to have this printer that prints out things. And one of those things is going to be like my latest transactions things, like how much have we spent on food? And then I can go up and like print that on my refrigerator and my whole family can see like, my wife can see like updates to our budget. To do that, to have a service running on my machine now has to, it's just really awkward, right? It has to like, I guess it has to become a client in this whole distributed system. And so it has to download the entire SQL file, the entire data, and then download the whole app to interface with it and then like run those queries. Whereas if it was just an HTTP API, I mean, just like you said, Jared, this is incredibly simple. You just make that request to the HTTP API. So it scales complexity-wise across use cases that I think are more interesting. And so I think that there's like, there's something that I'd love to talk about later in this podcast about like what I think could be the next step for some of these kinds of things. But I do still think that like, for like note-taking things and things like that, it does still feel like, I use Bear, which all uses like a local SQLite database as far as I know. And then it uses like the iCloud linking. And I love it because it's so fast. Like I can just like pull it up on my phone and I know that it will come up instantly because all the files are there. So I think there are still use cases there, but there's still a case where like, well, then I can like, I guess it feels nicer because I can just rsync my files to my server and then I can build a little HTTP thing like around it. But it just feels like this like complexity that I kept having to hit for like, oh, there's this like thing that everybody else is used to doing. And I can't do that now because I've built this other thing that has good trade-offs. But I'm, I think that there might be architectures that have similar benefits without losing some of that kind of weirdness. And also my final point I'll make is that like those complexity things and like there's these libraries now, Johannes, I need to look more at yours, but like I'm scared to build on top of something if, especially if it forces me to use their own APIs, like their own database abstraction. I like the ones that do let me use raw SQL, but even those are like, this is a fundamental abstraction in your stack, right? If you are a startup that blows up and you get stuck with that and it turns out to not scale or be bad or that the people making that burnout or like go away, that is a hard place to be in. So we're going to have to be really like, this is just like a chicken and the egg type thing where it's like, if you want local first to be really good and build these things, you're going to have to work really, really hard and long to make this like a robust foundation. So that's my initial number of thoughts. Happy to.

Yeah. So in your experience building actual, are you saying that you kept hitting these walls or you would hit the walls if you had to scale on a network and add clients or add collaboration, so to speak, this local first direction took you in places that locked you in and couldn't let you scale or do things differently, I suppose. I'm not finding the right words, but essentially locked you into a place or choices and you couldn't get around them. Basically, that was one thing that

was hard. And like some of that is because I built it myself. And so if I was able to use it, there is this like amazing library, like the one that Johannes has built. Is it LifeStore? Is that the name of it? There's a couple of them out there. Yeah. I need to check that out. It definitely would have helped me a lot if I had one already that was there that solves some of these problems for me. But I think some of this is a fundamental piece of the architecture where people just wanted to build a little client around it like themselves and access actual's API. I was like, hey, okay, we don't have an API. I ended up building one and you know how it worked? It was the entire app which downloaded the entire data first. And so to boot up the API the first time you run it takes seconds, like 10 seconds. So very, very slow and not very tenable. And the other thing that I was going to say is things like protected data. So if you wanted to like have these like roles and authorization, I think that's something that I think that that part I think is not fundamental. I think that's solvable, but it is hard. Like if you wanted to say like this user can like input this transaction and I want to hide it from my spouse because it's like for Christmas. Those kind of things just got really tricky. And just these weird things were like, okay, you're logged out and you stopped paying for the product, but you still have it all locally. And so people could like keep using it. And it's just like these weird things where like you log out and you log back in as a different user, but the other local data is still there. And like, it's just like, to me, I was like, I want to be a startup that focuses on the problem, like the solving the actual you. And I kept having to be dragged into this like weird mind state of like, how do I deal with this like crazy weird mind bending situation that local first. So I think that is the benefit of some of the, why the community has moved towards this newer model of local first, where it's like a really heavy kind of cash where it's like, it's still is a little bit more dependent on the server and it's not completely local first, but it's, it adheres to the principles where you query your data locally, but it's not as like, I got a new name for everybody. I'm gonna stop calling it local first. It's called mostly

local. Okay. Mostly local. You're swimming upstream there. I think we have critical mass

calling it local first at this point. Okay, friends, I'm with a good friend of mine, Afthar Suithan from Timescale. They are positioning Postgres for everything from IOT, sensors, AI, dev tools, crypto, and finance apps. So Afthar, help me understand why Timescale feels Postgres is most well positioned to be the database for AI applications.

It's the most popular database according to the stack overflow developer survey and Postgres, one of the distinguishing characteristics is that it's extensible. And so you can extend it for use cases beyond just relational and transactional data for use cases like time series and analytics. That's kind of where Timescale, the company started as well as now, more recently, vector search and vector storage, which are super impactful for applications like rag recommendation systems and even AI agents, which we're seeing, you know, more and more of

those things today. Yeah. Postgres is super powerful. It's well loved by developers. I feel like more devs because they know it, it can enable more developers to become AI developers and engineers and build AI apps. From our side, we think Postgres is really the

no brainer choice. You don't have to manage a different database. You don't have to deal with data synchronization and data isolation because you have like three different systems and three different sources of truth. And one area where we've done work in is around the performance and scalability. So we've built an extension called PG vector scale that enhances the performance and scalability of Postgres so that you can use it with confidence for large scale AI applications like rag and agents and such. And then also another area is coming back to something that you said, enabling more and more developers to make the jump into building AI applications and become AI engineers using the expertise that they already have. And so that's where we built the PG AI extension that brings LLMs to Postgres to enable things like LLM reasoning on your Postgres as well as embedding creation. And for all those reasons, I think when you're building an AI application, you don't have to use something new. You can just use Postgres. Well, friends,

learn how timescale is making Postgres powerful. Over 3 million timescale databases power IoT, sensors, AI, dev tools, crypto, and finance applications. And they do it all on Postgres. Timescale uses Postgres for everything. And now you can too. Learn more at timescale.com. Again, timescale.com. And by our friends at Eat Sleep, I love my Eat Sleep. Check them out, atesleep.com. I've never slept better. And you know, I love biohacking. I love sleep science. And this is all about sleep science mixed with AI to keep you at your best while you sleep. This technology is pushing the boundaries of what's possible in our bedrooms. Let me tell you about Eat Sleep and their cutting edge pod for ultra. So what exactly is the pod? Imagine a high tech mattress cover that you can easily add to any bed. But this isn't just any cover. It's packed with sensors, heating and cooling elements. And it's all controlled by sophisticated AI algorithms. It's like having a sleep lab, a smart thermostat and a personal sleep coach all rolled into one single device. And the pod uses a network of sensors to track a wide array of biometrics while you sleep. It tracks sleep stages, heart rate variability, respiratory rate, temperature and more. And the really cool part is this. It does all this without you having to wear any devices. The accuracy of this thing rivals what you would get in a professional sleep lab. Now let me tell you about my personal favorite thing. Autopilot recap. Every day my Eat Sleep tells me what my autopilot did for me to help you sleep better at night. Here's what it said last night. Last night autopilot made adjustments to boost your REM sleep by 62%. Wow. 62%. That means that it updated and changed my temperature to cool to warm and helped me fine tune exactly where I wanted to be with precision temperature control to get to that maximum REM sleep. And sleep is the most important function we do every single day. As you can probably tell, I'm a massive fan of my Eat Sleep, but I think you should get one. So go to eightsleep.com slash changelog. And right now they have an awesome deal for blind Friday going from November 11th through December 14th. The discount code changelog will get you up to $600 off the pod for ultra when you bundle it. Again, the code to use is changelog. And that's from November 11th through December 14th. Once again, that's eightsleep.com slash changelog. I know you'll love it. I sleep on this thing every night and I absolutely love it. It's a game changer and it's going to change your game. Once again, eightsleep.com slash changelog. It seems like the difference between James and Johannes is like James is trying to build an app for production and Johannes loves building dev tools and like things to enable developers. And so you're kind of trying, I mean, almost like James would be your eventual customer or user, because like he's talking about this live store and like you, you see this future and you're

trying to create it, right? Well, that's not entirely true. So the reason why live store came into existence in the first place is actually based on a predecessor project called Riffle that I collaborated on with Jeffrey Litt and Nicholas Schieffer. Jeffrey did his PhD project at MIT about this last year. And this was like a two-year collaboration where we've worked on Riffle. The entire idea around Riffle was what if you can make your app state management, not just like the backend data management, but actually your app state management. What if you could also use a database for that and bringing reactivity, et cetera, right into your app. So kind of going one step even further to what James landed onto using SQLite, I think typically on a separate thread where you asynchronously work with that SQL database. We took it one step further and we saw SQLite being so fast that you could actually run it in the main thread. That's a different can of worms, technically very, very interesting and was also quite a challenge to build. But the reason why I got involved is actually I took a bit of a step back from Prisma where it was all building dev tools. I wanted to get back into the shoes of building my own app again. So that was actually in terms of the chicken and egg where live store is maybe the egg, but the chicken that was also needed was me working on my own app and that's called Overtone. So Overtone, I think we've talked about that on a previous time is a new music app that I'm building sort of like a third party client for wherever your music lives. So think about it like what's superhuman is to Gmail. Overtone is to Spotify or to your own music collection, to YouTube music, to band camp, et cetera. And that was my primary driver to even want something like riffle and like that now led to live store and I'm developing both live store and Overtone and tandem. Overtone is still sort of the most demanding use case that informs all design decisions around live store, but I'm not doing this in a vacuum, even though I am like with one foot in the dev tool building situation, but with the other foot and firmly in the app developing a situation. But I think where I can now also subscribe to the point you were making, I am less strict about like making harsh time-wise trade-offs in favor of shipping earlier. I'm taking a more long-term minded approach and I'm making design decisions around the technologies and around the product that might cost me a couple of months, maybe sometimes years in terms of actually shipping everything where it take a more long-term minded approach. And your typical startup thinks about like, how can we reduce the scope for initial MVP and just launch it? And this is where I take a different trade-off. Gotcha. Okay. That makes a lot of sense. So

effectively what we have is a different way, a new way of building for the web, which is the opposite way that most of us have been building for the web, right? So client, we call it client server, but we really are server oriented and the client does things and the server is the source of truth and all of that. And that's a new and perhaps better way of doing it. However, there's a whole bunch of groundwork that has to be laid because you're basically pioneering and what James maybe you have found as you pioneered through this on your own with actual is like, there's lots of different gnarly, nasty problems that have to be solved in order to do this stuff that us architecture astronauts don't really think about when we're just, you know, on podcast talking about new paradigms and a different way is like, well, what happens when somebody cancels their account and this local first, like that's, you ran into that in reality and you're like, Oh, I have a whole new problem I have to solve. Whereas on a traditional web app, like we've been there, we've done that. You can just look it up or whatever you got to do to be like, Oh,

here's what you do. And those trade-offs for you, James today, at least over the last few years

have been not worth it. Fair? Yes, I think that's fair. And I do think that there are, I think I want to make sure that my points are, my main concern is that some of my problems are just completely inherent. Like if you are assuming that you're going to query your data locally, like first, and if it's like not there, it can fall back to the server. Even if that, there are things inherent into this that I don't think are completely solvable. And I don't mean that that means that it's dead in the water, it's a bad idea, but that there are problems that I think I don't see mentioned or that I think people say, we'll get there. Like we'll figure it out. But to me, it's like, it's an inherent part of it. So it's less that like, there's all these things that I think I don't mean, and I don't mean to like put cold water on this at all. I do think that like Live Store and other things can make this significantly easier and solve a lot of the hard problems. And there will be many apps built on things like that. But I think there is, there are a couple like trade-offs here that are just need to be kept in mind as well that might make

it hard for other people. Right. Newsflash, it's not a silver bullet. And not only are there problems that haven't been solved yet, but you think that just like anything, there are trade-offs

and there are problems that you don't think will be solved. The API one is one I hadn't really thought about. Johannes was kind of shaking his head in the affirmative as you talked about it. Is that a solved problem, Johannes? Like you have client first apps, like how do we build a generic API for a client first app like Action Wolf, for instance? Is that a solved problem now?

When you say how do we build an API, I'd love to hear a clarification of that since one idea around local first apps is that you actually, you should ask yourself, do we still need an API? It's all about the client side experience at the end of the day or some other things that you need to build. Maybe you want to send an email if a certain thing happens, et cetera, and you might want to do that on some server side thing. But one of the ideas of local first is trying to nudge you away from that very API centric way of thinking of an architecture. If you're building, let's say, a calculator app that just happens to synchronize between your phone and your tablet, then you could try to think about that as like, oh, we're going to have an API here, et cetera. But if you just start out working on that in a single player experience, you would never think about, do we need an API for a calculator? No, we just built that thing client side. And now if you have that as a starting point and you want to synchronize data between your different clients, you don't necessarily need an API for that. You just need a transfer mechanism between the clients. And that's rather where the local first idea comes from. That being said, you can still interact and integrate with APIs. But I think with local first, you'd rather think about how do you synchronize the data and less how do I request

response with an API? Sure. Well, we don't have to invent hypothetical API scenarios because, James, your customers were asking you for this, right? Yes. They're like, I'm in my terminal and I want to just write this script that dumps things out and to put it on my second monitor. I think maybe it was just like, maybe this is, I can't paint too broad of a stroke here because I think maybe this is one app that just would have benefited from a standard API because people wanted to query their data. They wanted to write scripts on the remote server to set up their own notifications for when a transaction came through that was too much. And so I know in this specific case,

it would have been nice to have an API. So the way how I'm starting to think about scenarios like those is similar to how we're using Git. I think we're thinking less about Git as an API endpoint that you correspond with, but you're thinking about Git as a semantic protocol that you use in a very specific environment. In this case, how you evolve your code repository in a semantic way. And I think the same analogy could have also hold true for your scenario. So obviously this would have taken quite a bit more effort to define and develop this and so on, like, and build SDKs for the various target platforms, et cetera. But I think from a mental model perspective, there's nothing inherent that this needs to be an API. I think the synchronization mechanism still holds true to this. And this is where Git is sort of like a very commonly used synchronization mechanism. And I would like for apps to embrace the sort of more Git less APIs mindset where often that can be more declarative instead of like APIs often being kind of like very hand-wavy in an imperative way. But yeah, it will take time to get things off the ground there and kudos to you again for just putting in so much effort and the pioneering work that you've done over the years. And particularly also targeting the web. I think the web is both like a blessing and a curse. It is a blessing that it can already do all of those things that it's possible with right now, the ubiquitous distribution you're getting with the web, et cetera, but it also lags behind in terms of capabilities that we've already had for decades on more native platforms. I'm very bullish on the web, even catching up with those native capabilities. Just want to add a few points on what you've mentioned before in regards to file system support, et cetera. So you've mentioned OPFS as sort of like this origin private file system, which I think by definition is sort of like non accessible to the user. I think the current way how it works, for example, in Chrome is there is actually like some folder somewhere, I guess under like application support or library somewhere on macOS or in different places where you can actually see the real files, but this might just be an implementation detail. It's not meant to be user accessible. However, also in Chrome, there is a, I'm not sure whether it's even newer, but there's a separate API with mostly the same API surface where it lets a user actually mount a real file or a real folder system from their actual hard drive into the web app. And you can read and write from it. So with that, you get like real files in your app, and those files don't go away if something happens to the web app, unless the web app decides to delete it. But this way we're already taking another big step towards native capability apps, at least in Chrome for now, I'm not sure what the current status with other platforms with other browsers, but stuff like that gives me a lot of hope. And the way, if I'm now wearing my application developer hat for Overtone, what I'll probably do is like, I love those capabilities and I'll embrace them for the given browsers. So I'll probably say like, Hey, if you want to use the web version and not the desktop version, and if you want to have the most advanced experience, then please use Chrome, use Arc, et cetera. And if you use another browser, then I'll diffuse the capabilities a little bit. And hopefully in two years, Safari and other browsers have caught up. So I'm more long-term minded on this and I don't see it, like I don't look at a feature and say, if I can't have it on all platforms, I'm not having it at all. I'm rather like opting into features progressively enhancement way, step-by-step. Yeah. And that's, I had forgotten that.

I think that I saw that was released and I think you have to like, there's a notification that pops up for the user, right? And then they just have to say allow. Exactly. And that's great, but I love that. I think that moving towards those kind of models for apps that this works well, is going to unlock a lot of like really, really cool stuff. I think that that is a huge blocker, that that was one of my biggest gripes. And so the fact that that is starting to be solved is

amazing. I think overall the web is sort of like in this weird spot where the web has traditionally always been like a website distribution mechanism, but we all want like more and more app-like experiences in the web, but there isn't really this binary way of like flicking on the app mode in the browser and everything by default is treated as a website. And that makes for a worse experience, even so that like Safari takes some pretty strong steps in that direction. If you don't visit a website for, I think seven days or so, it just like wipes all of your data, which can be very counterintuitive and very much, I think, hampers the trust that you can put in web apps, making it again, like the self-perpetuating prophecy that, oh, it's just a website and you can't have real apps. And I guess the closest we have in that regard is like that you pin something to your dock bar. That actually does change the defaults quite a bit. So, but yeah, that's sort of with my web optimism hat on. Yeah, I think some of my reaction and

pulling back and evolving my ideas, I think are founded in like good stuff. Some of it is just that I just so burned so like so many times on things that aren't a problem anymore that I'm still kind of evolving my ideas, but like I did one, like, so I built AbsurdSQL, which like was SQLite on top of IndexedDB before all of this other stuff was available. And like, there was definitely just like a time when I loaded up actual and like, it was like, okay, log in or I think I was logged in, but like, none of my data was there and had to re-download it. And like, luckily the syncing stuff was nice because I'm mostly online. So I didn't really lose any data, but like, it was just a really bad taste in my mouth to be like, man, the web just sucks. Cause like, like it just blew away my, it just like all of my IndexedDB was gone. I guess like my disk was running low on space or something. Now to be totally clear, like you were saying, Johannes, I think this has all been mostly solved and is way, way better, especially if we're starting to use real local files. I think, I don't think the OPFS even suffers from this, but yeah, like that, the web has a lot of trust issues, I think with, with, with people or people have a lot of trust issues with the web and yeah. Well, it's an attack vector, right? It's networked. Obviously there's gonna be lack of trust.

Yeah. Also it's not in your control because the browser vendors control browsers.

And it sounds like too, both of your perspectives push against what the browser wants to be for an application. For example, it doesn't seem to want to be local first. It wants to be connected. It wants to assume the thing it's rendering is connected or wants to be connected. So you're kind of fighting upstream to this, to the platform essentially that you're building against. So you have to get better buy-in from browsers. I wouldn't subscribe fullheartedly to that

statement. I think this is mostly like a matter of like the hive mindset that we've developed in the web over the last decades, really. And I think this is also where the local first mindset gives you a bit of like a bias counter to that point, since you can actually build a lot of web things where you treat the network as being optional. And I think if we put ourselves at least temporarily in the perspective of a mobile app developer, I think this is where it's much more common that you want to build for an assumption that a developer, that a user doesn't have a connectivity all the time. So, and the way how you build the best experience in that regard is by really treating the connectivity as an optional thing that enhances the app. And you can very much build a web app in the same way. And we have a lot of ingredients that I think are highly underused in that regard. So we have like service workers, et cetera. And by just forcing you and constraining yourself in the way how you build the app, where you say like, actually I separate every network into action behind like some little surface that I have like under my control in my application. And I want to make sure that the application may be initially installed similar to how you install an app from an app store. And from there, the app is functional. From there, the app is enhanced with network, both enhanced in terms of data synchronization, loading media, et cetera, and also loading new app updates. It's very feasible to do that in the web. I think it's just not really helped by major frameworks, something like Next.js, et cetera. It doesn't help you at all with that. So I think it's mostly a mindset thing. And the mindset thing is also holding back the technologies that are being developed and the lack of those technologies don't evolve the mindset. So I think it's a bit of a chicken egg problem in terms of the mindset. And we see the most development coming really rather in the mobile world where those assumptions

are much more common. I'm fascinated by Overtone then as a local first application because, I mean, it's playing my Spotify playlist for me, right? Like how does Overtone useful in a local only context, like in an offline mode that would make it like a great local first app?

Yeah. So, and I think that's actually also raising an interesting question in regards to local first that it's, again, not binary that is like either fully local first or it is like embracing all the APIs. Overtone is a great example where I need a hybrid. I do want to integrate with all of like the different music services, music sources that you might have as also want to support, or I do support things like RSS, et cetera. And there's also a licensing question and a copyright question that comes into play here. Some data I am allowed to download, some data I'm allowed to actually cache or store locally, some other data I'm just allowed to stream on demand. So for example, if I'm playing something from Spotify, I obviously can just stream that, but I can't download it. Whereas if I've bought something on Bandcamp, that is something that I actually do want to bring on my hard drive. So it really depends on the kind of situation there, but I'm building this in a way that gives you kind of the best of both worlds that keeps local, whatever you can, and you're allowed to keep local. And that's kind of de facto yours stuff that I'm buying from Bandcamp or from other places or stuff that I already have in my Dropbox, et cetera. There shouldn't be any reason why I shouldn't be able to use that on my hard drive or on my computer while I'm doing a road trip. Whereas there's other data or other kind of content where I might already have seen the metadata and that metadata should still be accessible to me. For example, that I see it as like, oh, I liked those things or have the playback history, but I'm not temporarily until I have connectivity, I'm not allowed or I'm not able to stream that data. So it's sort of like a hybrid mix, but typically with a web app that is built in a more traditional way, at best, you have like some offline caching that breaks the moment you first click on an album and then it doesn't have all the data you need and you just get a

spinner. Right. So I'm curious on your thoughts on this, because there's two more points that I wanted to bring up in terms of the things that I have found hard. One of them also is just like integration with services. And so with actual, obviously, I want to pull down transactions data. And so it's like you have to have a server, obviously. For you, it's like you need to pull down the music to actually play it. So that forces you to have this kind of hybrid model. And I always found it hard to like fully have a local thing, but then bolt on all of these additional services. I guess it was harder for actual, especially because it was this whole privacy focus first thing where it's like it's all privacy focused. And yet you have to pull down your transactions from this third party thing where you log in and give them your data. And then it has to flow through my server because I have to like have a key to work with that service. So it flows through my server. So it's like it's not privacy focused at all. So that was maybe a hard thing for me, but really to step back even more so. I love having, I don't know, I guess a hybrid can be, it's just like an additional complexity and heart. And like if it's all from the server, all flowing down, bolting on a new service is like, it flows through the exact same pipes that everything else uses, right? Now we have this like two different models. And has that been hard to kind of like think through for you? Because for me, sometimes I'm just like too many things going on and it feels nice to have a single model, but how has your

approach been to sort of tackle that overhead? Yeah. I mean, if you're just building a notes app where the only person who's going to write down a note and possibly you write it on your computer and you write it on your phone and those are connected somehow, that is much, much, much easier. And this is where you're like in a fully isolated, like homogenic local first world. And once you're in that more hybrid world, this is where there's a lot more that could go wrong. And if I would be all focused on like shipping something within a couple of months and I need to like get users, et cetera, maybe I've raised VC money and I need to like run faster on the treadmill, this would have been the last approach that I would have taken. However, given that I want to build this for the long run, I'm taking a much different kind of trade off. Like I want to be able to not hate my life building this app continuously. Once I've launched, I don't want to just like move the problems under the rug, but I want to, if there's something that can go wrong with a high probability, it will go wrong. And so I'm basically just making this a problem of tomorrow. And once you have more users, this doesn't make things better. So I want to address those in a more principled way. And yes, to answer your question, yes, it was pretty hard and took a pretty long time to figure out principled approach as principled solutions to those really hairy problems. And I think my solutions that I found here are very tailored to this specific use case. So I'm not sure whether it's going to be applicable to many, many others. However, what I found for this works really well for me. So what I'm basically doing is I ask myself, like, what would make my life a lot easier working with those external data sources and the fact those data sources give you not sort of the git style history of everything that has happened, but just give, they just give you API endpoints of partial snapshots of like, this is what our API things, what our systems things like the current state is. And so it gives you like a here's like the first 50 tracks in this playlist, and then you can paginate over that, et cetera. And that is very much built for the sort of like temporary client experience. The client doesn't remember everything, but what would help me a lot is if I would get more of like the git style evolution of everything that has happened in this playlist, everything like this track was added at this position. Those are the information about this particular album, but this particular artist, et cetera. And I've built myself a little module that basically gives me that sort of that worldview and reconstructs a history of everything that has happened about this. So it gives me basically a change log, no pun intended, about everything that has happened about this particular thing, about this particular playlist, et cetera. And I basically isolate the heavy lifting, eating my vegetables on that particular problem. And once I have that change log of all the histories, then it's basically redux style, just applying that. So isolating, separating the problems. And that has made such a huge difference for me. And that allows me to actually do it. And this approach works for every data source that I've seen so far in regards to Overtone. Cool. Well, friends, I'm here with

a friend of mine, Michael Greenwich, co-founder and CEO of WorkOS. We're big fans of WorkOS here. Michael, tell me about AuthKit. What is this? How's it work? Why'd you make it?

WorkOS has been building stuff in authentication for a long time, since the very beginning. But we really focused initially on just enterprise auth, single sign-on, SAML authentication. But a year or two into that, we heard from more people that they wanted all the auth stuff covered, two-factor auth, password auth, with blocking passwords that have been reused. They wanted auth with other third-party systems. And they wanted really WorkOS to handle all the business logic around tying together identities, provisioning users, and even more advanced things like role-based access control and permissions. So we started thinking about that more how we could offer it as an API. And then we realized we had this amazing experience with RADIX, with this API, really the component system for building front-end experiences for developers. RADIX is downloaded tens of millions of times every month for doing exactly this. So we glued those two things together, and we built AuthKit. So AuthKit is the easiest way to add auth to any app, not just Next.js if you're building a Rails app or a Django app or just straight-up Express app or something. It comes with a hosted login box. So you can customize that, you can style it. You can build your own login experience too. It's extremely modular. You can just use the backend APIs in a headless fashion. But out of the box, it gives you everything you need to be able to serve customers. And it's tied into the WorkOS platform so you can really, really quickly add any enterprise features you need. So we have a lot of companies that start using it because they anticipate they're going to grow up market and want to serve enterprise. And they don't want to have to re-architect their auth stack when they do that. So it's kind of a way to future-proof your auth system for your future growth. And we have people that have done that. People that started off and they're like, oh, I'm just kicking the tires. I'm just doing this. And then poof, their app gets a bunch of traction, starts growing. It's awesome. And they go close Coinbase or Disney or United Airlines. It's like a major customer. And instead of saying, oh, no, sorry, we don't have any of these enterprise things and we're going to have to rebuild everything. Just go into the WorkOS dashboard and check a box and you're done.

Aside from the fact that AuthKit is just awesome, the real awesome thing is that it is free for up to 1 million users. Yes, 1 million monthly active users are included in this out of the gate. So use it from day one. And when you need to scale to enterprise, you're already ready. Too easy. You can learn more at authkit.com or of course, workos.com. Big fans, check it out. 1 million users for free. Wow. Workos.com or authkit.com. So how warm is the water then, Johannes, in the local first world? So you've been taking it slow and steady in order to solve a lot of the problems. What about devs out there? Maybe they're more like James or like, I have a product. I want to get it out there. I have an idea. Maybe I have 18 months runway, but I got to go from zero to customers in 12 to 18 months. Is it warm enough that local first can make sense or is it like,

you're going to have some tough sledding? So I would say that right now, if you're on a strict time budget, then local first is probably not yet for you. I will probably give a different answer. I would have most certainly given a much more stricter answer along those lines two years ago. So I think right now it's already less irrational to go this path, but given that there is still a lot of like infrastructure missing or it's not quite as mature yet, I would say maybe in two years from now, I would confidently say, okay, the water is pretty warm for those specific use cases. I would say the more of a specific use case you have where you feel like, no local first is so perfect for this and this will give me like a strategic benefit further down the road, for example, that you build something where user privacy really matters or for other reasons, if you have a very specific reason, then I would say actually the water is warm enough that you, that you can swim or do whatever activity in there. But as a, so it's not a silver bullet yet. It's not like the catch all scenario yet. So I think for that, you're probably still better off with your typical like street tier web app, but it is trending in the right direction. We have so many more off the shelf technologies already there that people can try out. There's actually quite a couple that are just about to launch in the coming months. So the space is really getting there. And I'm very confident that for this mentioned set of use cases, I think within the coming years, we'll see it flip that it gets easier and simpler to build apps in this way in the medium to longterm. Since at the end of the day, if you build apps that have a rich client side experience, there is just by definition, there's a distributed system to be solved. And this is what like notion is struggling with right now. This is where many apps are actually getting worse over time. My notion calendar doesn't work offline, et cetera. Like those are things that is just almost impossible to retroactively address where you need to choose the right architecture from the get-go. And I think this will be a better starting point in

a not so distant future. I feel a pain of notion, honestly, like I think notion is the unique scenario where you almost want slivers of it to be local-ish first or mostly local. I'm still sticking to that because like obviously you want the calendar to work. My calendar app from the, you know, on native Mac OS works just fine offline. Why in the world is notion calendar not? And the same thing with opening notion to write things. You cannot do that. It's very challenging. Like you can render some of the things, like it'll cache some of that stuff and you can view it, but you can't interact with it. So basically notion is unusable when not connected. And that's super sad because you're mostly creating. There's a lot of things that happen in notion because notion can be very simple and notion can be very, very, very complex. Once you sort of add team members and scale databases and have permissions and different layers and all these things. And so I really do not envy the engineering challenge they have to solve their mostly local problem, but there you go. Yeah. And I mean, I have so much admiration

for the folks who have been building notion, particularly in the early days, but are also who are like scaling notion right now. And I think it's like almost like an impossible trade-off to make right now, because something like Apple software, Apple notes, et cetera, they have a very specific target audience, which is like you who bought the computer, you as a primary user, it can be all about you. There won't be like some super SIS admin who says, no, like you, you won't have access to all of your notes anymore. It's your computer. All of that stuff on that computer is yours. Whereas like with notion as they go more and more into enterprises, this is where they need to have certain constraints and certain guarantees that some intern might, if they accidentally got access to some confidential data, that someone can revoke it and not store it for eternity on their device. So it's very, very different trade-offs that are more in favor of an enterprise and less in favor of an individual who owns that data. And I think that's almost an impossible trade-off to make. And even that trade-off aside is just a very tough engineering challenge. If you start out with a relatively thin client and then slap on more and more caching, you got to go all the way and treat this to some extent as your source of truth that you can reasonably build an app experience around that. And in that regard, Apple has to, if you're a bit more generous to the definition of local first, Apple has kind of been the OG of local first apps in some way. And most iOS apps and so on, I guess, Android apps as well are much more local first than the typical web apps.

Yeah, I think this idea of like partial sync basically is kind of what you're implying that notion is kind of needing this idea of like, some of it is offline, but you can't download the whole thing, right? Because the intern should not be able to access those private files. So it can't be one big database. So you need this like partial syncing thing where maybe it's like multiple databases and like one full database that can be individually downloaded. And that's where I've seen some of the more modern electric SQL, I think has partial sync. And what were the two other ones that I was just looking at? Power sync and yeah, there was one more that there's this idea where you can like download part of it, which solves some of my complaint where like you want to boot up this thing to use it as an API, but because of the way it works, kind of what you're saying, Johannes, is like a Git thing where you can just like download the data, you could download just the data that you need to do the work that you need to do. And it's like this partially sync thing. But to me, that just sounds mind-bendingly complex to figure out how that works. And I haven't dug into how the current things work, but it does seem like a very hard

problem. What is the notion used with the things I want to do or I want to create a new document? Like I want to be able to note-take. I want the note-taking app to be able to take notes,

no matter if I'm connected or not. I mean, that's a very simplistic, like don't give me anything else. I can, as an individual user, I can understand trade-offs that, okay, I'm offline, I can't see the full table. I can't manipulate data in the cloud. I get that. And there may be some users out there who are less savvy. I don't think that's very savvy, honestly, but maybe less savvy than that, that don't get that. They get upset. But I want to create a note. I want to be able to do things like that. But I get the challenge there. I mean, there's so much complexity that you could have in Notion with what it does. And I just don't even envy the engineering task to even accomplish that mission they've got. But they need it. They need it in certain ways. That's why

I think mostly some of it, certain tasks could be local-first or local-minded. One of the, I think,

I would encourage if I was to say anything to the local-first community right now, I think one of the things that would get me very interested is an incremental approach to all of this kind of stuff. Because I think my problem is like, yes, you want to create a note and you want to write that note. Notion does a crap load of other things. And you might not care about 90% of those things working offline. You just don't care. But like we've been talking about, you kind of need to buy into this from the very beginning, right? It's a very different development experience. And it can be a great development experience. If you have all your data locally, you just run your SQL queries even on the main thread, like Johanna said. But if you, I want to just build my app the freaking way that everybody else is building it, because then I can use all the services everybody else is using. I can use all of the analytics things. That was another thing I ran into actual. When I wanted to use Mixpanel, I literally had to fork their client because it didn't work in the way that I needed to, because you have to run it locally, right? You can't run it on the server anymore. And I remember it didn't work in, because I was compiling node to run in a web worker, doing something weird like that. And of course, this third-party SDK, which assumes you're in node in the server, would work that way. So I had to fork it, fix all this bug. And every single time I had to do something different. Whenever you walk a different path, it's hard. And I think I want to build my apps. I want Notion to build their apps the way that everybody else is building it, the way that they're normally building it. And then you can figure out how to add on the local first thing. And it's a really hard problem. But if they should be able to say, I want to make the ability to add a node and sync some basic properties of that node in that special cased way. But the other things are just hitting an API. To me, that sounds interesting. I know that's almost even harder, because now we're back to a real hybrid. But to me, it's like, then I can do my startup, focus on just the normal everything. And then as we get bigger and harder and things get harder, I can specialize parts of the app to be local first. And that, to me, is that I don't

know. It sounds interesting to me. So for what it's worth, a lot of the technologies that are in the works right now, like off the shelf local first-ish technologies. So you've mentioned some of them, such as electric. Another one that's coming out soon is called zero sync by the folks at Rosie Corp. Their previous product was called RepliCache. And so what both of those technologies have in common is that they lean into your existing Postgres database, that you can partially sync the data that's in that Postgres database onto your client. And then you have an experience where you can still locally work with the data in either an optimistic way or save some of the writes offline and process them when you get online again. And that is sort of like a sliding spectrum of what is not yet possible, eventually possible. But they're heavily leaning into that incremental adoption story, which I think makes it much easier for people to say, hey, we have our existing app. We have our existing API. We have our existing, for example, Postgres database. We want to build a new feature. We want to overhaul this existing feature. And for that, we want to lean into sync. We want to build a real-time collaboration experience. So it is getting there. But I think if someone does have the freedom and luxury to build a greenfield app and who wants to really, like, in the same way as people are trusting Apple Notes, it's like, you pull it up, you click that new note button, and like, off you go. There's like nothing in your way. If you want to have that sort of like no Asterix experience, I think the best way to get there and also have a great developer experience is to fully lean into it.

Well, I've certainly clicked on new note inside Apple Notes and seen a loading spinner. So I'm not sure if anybody necessarily has this problem solved. Wasn't there before iCloud sync, but as soon as they added iCloud sync, now all of a sudden it was waiting for something to update in the background. And I could not enter text. That was recently, probably within the last year or so, but a one-off. And which makes me think about the state of sync. You mentioned these new tools that are upcoming. We had DHH on the show a couple of weeks ago. We were talking about Rails 8's embrace of SQLite and some of the possibilities that unlocks. He was very excited about the potential of having multi-tenant apps where each app gets their own SQLite database. Of course, this is how many local first things work in the first place, James's actual app. You know, you get your own little SQLite database there in the browser. And I mentioned, yeah, you could have like your own little base camp right there in your client. And then it just syncs and everything's good. And he said, he's very happy about that, except for the one I said, it just syncs. And he's like, I don't think sync is a solved problem like that. And I'm curious, what's the state of sync tools, the community? Is it a solved problem? Obviously partial sync is not a solved problem, but can we rely on the state of the art in syncing libraries and tools? I would say this is a heavy area of

research development and various attempts, various different trade-offs. So probably not yet by the time when this episode comes out, but in a couple of weeks from now, I'm planning a collaboration with a friend of mine, Jess Martin. We're working on a comparison landscape resource that compares the various like syncing engines, the various local first stacks, et cetera. So that tries to give you a much more matter of fact, nuanced differentiation of the different technologies. But what I can already offer is like a high level answer to this is that there's a couple of different approaches to syncing. Some of them are based on CRDTs, which has the trade-off that it can work in a fully peer to peer decentralized approach. And then there can be also like approaches where you still have a central authority. Each of them have different trade-offs. Each of them have multiple technologies building those. And it's really a matter of what is like a good fit for your application use case. So for example, if you still want to run a central sync entity that has the authority that implies a bunch of other technologies. So things are coming along nicely. There are also a few that synchronize SQLite databases, for example, directly. So it really depends on what works well for your app. And I would say we're a lot further along than compared to five years ago. And in hopefully a couple of years from now, there's just defacto best technologies for the various trade-offs. And you can just use that. A couple of shout outs I would give at this point where I think it mostly just works for the use case that you have is something like Yjs or AutoMerge if you're using CRDT. So if you use something like Firebase, but you want to go more local first, those are great options. There's also jazz tools. So this is for Greenfield apps. And then for Brownfield apps where you want an incrementally adopted things like electric SQL, parsing, the upcoming zero, et cetera. And there's many others, but I would say it's good if you're curious to build something with it, just to tinker, maybe not yet fully go into production. Now is certainly a great time to get started with it. And for many production use cases might be perfectly reasonable already.

I think a lot of the academic research is probably good enough to where we should be able to have something that would be really, really good, but it's just hard to actually build out the actual, because the academic research is really complex math and to distill that down into a product that's actually stable and has the trust of the community because they just literally just need to exist for five years to make sure that they're not going to go under, that will take time. But I mean, honestly, I did everything myself, which I overextended myself, but syncing was not near my top complaint. The CRDT stuff there was amazing. And I'm not taking credit for that myself. I just use hyper electrical clocks. It was really cool how it worked. And the research was there and the syncing worked great. None of my complaints are about it was hard to sync. It's just like, man, when you start syncing, all these other things come up that are weird. Not to say that I even nearly solved it, but it was cool that I was able to take some existing research and just get this thing that worked actually reasonably well for for my use case. So I'm excited to see all these other things coming out.

But I think it now just takes like new generations of actual like experiences that are like always getting a level further than the ones before. And I think step by step, we can actually systematically solve and address some of those problems through off the shelf community packages or just by sharing sort of like best practices and building that tribe knowledge. And I think that will already take things very far. And what is so nice about syncing is I think it will really be like a step function in simplifying our app stacks in the same way as like declarative you programming such as react, view, solid, et cetera. This has made stuff that been like super gnarly and imperative before where you needed to use jQuery or manipulate the DOM manually to making everything just beautiful declarative. And there's like entire category of stuff you didn't need to deal with anymore. Now, if you get that for data across your different clients and servers, et cetera, that's what syncing gives you. And this can liberate stuff so much. And

that's amazing. James, you mentioned before we called a show, you did want to give some thoughts on what you think maybe a future for mostly local community might look like.

That's a, I threw Adam a bone there. Open floor for you, James, just to share your thoughts on what you think might be compromised or whatever your ideas are there.

Yeah. So my current, I'm kind of like kicking off my own research phase, which I wanted to do this start a couple of weeks ago and then kids in life and holidays now. So hopefully over the holidays, I'll get some time to really dig in here. I'm excited about something. And this, again, this is not mutually exclusive. It's not a zero sum. I fully support the local first community. I think it is a really, really cool idea and cool tech. And I love, I'm surprised at how it's not mainstream, but I'm surprised at how popular it's become. I was, at some point was like, there's no way people are going to actually really invest in this because this is so much work to build a whole new platform. So really cool to see it. But what I am thinking now is that a lot of the benefits, at least that I was after, I might be able to get them with doing things just more on the edge. And so the way that my thoughts have been sort of evolving is that basically the way actual worked was it ran your whole SQLite database and it did the entire back end of the app, back end, it was all local, was in a web worker, right? So it was a different process, but locally on your machine. And you could, so once you're in the web worker, the SQL queries were literally synchronous. They weren't even async because it's actually faster. It's so fast that the async overhead of doing multiple promise calls is actually slowing it down. And just architecturally, it was just like having to, you introduce an async call somewhere and then all the call stack has to be async. It's just super annoying. So going back to Johanna's development experience there, it's amazing. Once you're in that web worker, you async call into it, but then once you're in there, it's great. But with all of the problems that I've been saying, it's hard to integrate services. It's just kind of this hybrid approach can be mentally taxing. I just kind of want things to work the way everybody else works, which is that you hit a server and you get something back. What if we do this? This multi-tenant approach is really interesting to me. And there's a company, Terso, terso.tech, which is building out a scalable infrastructure for this where every single person, every single request even could possibly get their own SQLite database. And so what if basically I took this web worker back in that is local, but it's not actually local and it's at the closest data center point that could possibly be closest to you. And so in that way, I'm still accepting the fact that there is a network call, that there is this boundary there, but it's very close. So I'm hosting currently my website jlongster.com on the Northern Virginia OZ data center or whatever. And I'm in Richmond, so I'm a couple hours drive and it's about 20 milliseconds overhead. So I think we can assume 20 to 30 milliseconds overhead for a moderately non-fine-tuned network infrastructure. I think that could even be faster. That to me feels acceptable. And once I accept that single round trip cost, then I can move everything to my server, still have the local SQLite database and have my development experience there. And possibly there's the SQLite syncing going on in the backend. So I'm not ditching syncing. You're probably going to have to sync these changes across a backend distributed network. But it's just nice to now own that because now I can do analytics. I can flip something on in just a minute without having to get everybody to refresh their clients. I can do a multitude of clients. If I wanted a terminal app for my finances, I could curl something really fast and get a buttload of charts. I could do a quick... I just get that API instantly. It crosses that network boundary, which lets me do everything the way that everybody else is doing it. So it's like the same stuff might be going on, even the syncing, because you're probably going to have to be syncing that SQLite database because you're just mutating it locally on that edge instance. It's going to have to replicate that somehow elsewhere. But it's like, if you draw the line of the app and local first is like, at least for the most part, we're kind of having this hybrid thing where it sort of depends on a server. But for the most part, a local first app in principle is you draw the line of the entire app and all of the data, and it's all on your computer. And then there's another circle, which is the server. And then it's syncing to the server. This is like, if you draw the line all around your app, but then it reaches over into the server for one little bit, which is that edge node. And then the edge node is talking to all of the complex server. And the more I go down this, the more it's like, well, I really just want to make a single request to the server. I don't want to have to go back and forth. Maybe I'm evolving to be a use the platform person, and I'm just leaning into very, very light client apps. And now I'm starting to lean into this whole React model where it streams live updates. It's kind of fitting that it's taken years to get here, but it seems like React server components are actually a thing now. And it is a compelling model. A long time, I was like, this is the weirdest idea ever, especially when I was local first. I was like, this doesn't benefit me at all. Now, suddenly, if I'm flipping my position a little bit, it's like React server components are amazing because I can run the entire app on the back end, get all of this stuff that I want, stream in just a couple of lightweight client components that I want to. I do full navigations, maybe even possibly. And the thing that also gets me is the ability to flip open new tabs instantly. That's one of the things that I'm a little bit like, because things are all local, it's just slow to boot up the app. And normally I was like, well, you boot up the app once and you're digging in your finances for like an hour. Like, I don't really care. But the thing that does feel nice is just to like command click a link and open up a new window, use my local macOS windowing system to split the screen, have different tabs, and just like very quickly in a very lightweight way, just like spawn tons of tabs. And those tabs load in just like 30 milliseconds, right? That can be hard to do local first because you're buying into the thing where the entire thing must run locally. And so it has to boot up. It has to boot up the thing. And Johannes, I mean, maybe I'm wrong that you can get a 25 millisecond boot up time on a complex app. I'm curious how overcast feels if you've optimized for that. But that is where I'm going to be researching and kind of diving into. So not to say that this is the

solution either, but it's something that I'm very excited about. I applaud you for going down this path in the pursuit of simplicity. And I think this is why you went down the local first path in the first place and you've gotten really far. I think you saw like some glimpses of reward and where you can see like working with SQLite locally, et cetera, affords you a lot of simplicity, but you also revealed a whole bunch of problems that need to be addressed and you didn't have the time for that. And I think there will probably be a similar situation there given that a lot of the things are server-side, the constraints are not as severe as on a client that could potentially be like an outer space or something. So I think this is where our traditional knowledge as a web dev community, et cetera, more broadly applies. However, I would say this works well for still like very connected applications. So I think it takes server-side applications to the next level. But if you want to use that, for example, to build like your next notion that should work on crappy plane Wi-Fi, then this won't get you far since you'll now get even further removed from the next edge worker. I think it's going to be a little while until you have like edge workers natively in an airplane. But I think if connectivity is the slightest concern, and then I think there might still be challenges or otherwise you kind of need to still solve the local first problems since then you need to, it's all a matter of like you get, if you're connected, you get better latency, but there's actually no difference between being offline and high latency. Being offline is just very, very high latency until you get online again. And fundamentally, you still need to solve the same problems. And if your app can't deal with high latency, if it like loses everything, then you still, either you don't support that and you can't write down your note or something, or you still need to address it. And I think this is where you still need to address some of the underlying local first problems. But overall, it certainly seems like a huge step on the server side. And I think this is where we'll make progress from both ends, like from the, all the server side stuff is getting better. All the local stuff is getting better. And hopefully like it, in some cases is already meeting in the middle. I think Torso is doing some really, really cool stuff there, but yeah, it's going to take a little

while. Certainly. Yeah. And I agree. Like it's not, it sucks. It's accepting the trade-off that on very slow connections or on the plane, you will have that problem. And so that to me is the thing that I'm kind of kicking down the road a little bit where it's like, if I can specialize a very small critical part of the app to be local first, then there might be specific things that I would end up building and support there. But totally accept that maybe that is like very hard and actually doing that later is like, can be hard too. And it's a viable position to say that you do need to embrace it fully from the front end. I'm sort of balancing that and I'm kind of curious to see if I could get to that point. I will say that people cared that my app was fast and I don't know, I think we are a very well connected world. And not to say that it's not meaningful at all, but I think I'm kind of just falling back into the, I'm ditching some of that complexity just in acceptance that it might not work as well sometimes. Yeah. Two thoughts on that. Actually,

kind of tragic just today. Today is Tuesday. They're just in the Baltic sea between Germany and Finland. There was like the sub ocean fiber connection was cut probably by like a state actor. So that shows like how brittle or like everything is always connected assumption can be. And it's one thing if like, you're like, whatever your access to X or blue sky or whatever is taking a hit, but it's another thing of like more critical systems are being taken down. And the other way, like you don't even need to step into a plane or something, just go to like a coffee shop and use the public wifi there and try to like, just do work for like half an hour. And you'll notice like how all of your apps are just like, are rendered completely useless. And I think having sort of that constant assumption, everything is like fiber grade, 5g grade connected, I think can bite back at some point in Europe. For example, we, people use actually trains quite a bit and trains has like similar wifi compared to like your public coffee shop or your plane. And so it's more

ubiquitous than you think. Well, that leads us back to trade-offs because while I completely agree with you, Johannes on that, all that sometimes the best app is the one that you can actually build. And I think that's some of what James is hitting up with is like, what trade-offs

is he willing to take as a solo dev, trying to build whatever it is that you're currently building James, you're still working on actual as an open source, right? Are you moving on to

another product now as well? I have pretty much the community is fully maintaining it. I'm not

really part of the community anymore, which is great. So cool. So onto greener pastures, but whatever it is that you're trying to build, I applaud both of you. Johannes for pushing the

industry forward in this direction and James for tinkering and experimenting while you build and like willing to try new things that most of us wouldn't even try to try and exploring that way and helping us discover what might be good compromises where it fails, et cetera. So y'all had me excited about the future, regardless of where it is. I feel like I'm warming up Johannes to the waters as the waters themselves warm up, keep us updated, keep us in the loop as this tooling and this ecosystem flushes out and matures. So we can keep our listeners in the know as well, because at a certain point, I hope you're right. And that pendulum flips or that switch flips pendulums don't flip. They swing that flip switches to where it becomes actually easier to do it this way, because I do think the virtues are better than the drawbacks. But I think, like you said, for certain people at certain places with certain apps, it's still probably too hard. So definitely as it matures, I'm interested in hearing about that. Adam, anything else from you before we call it a show notion, figure it out. I think they're on it to your point, Johannes. Yeah. They've, they've known very well about this problem. I've been working on it for many years. It's really hard to bolt it on. So yeah,

it's hard. Yeah. A little plug on my behalf. If this is interesting to any listener to dig more into Local First, I want to plug the Local First podcast, Local First FM. It goes a lot more in depth on all things, distributed systems and all things like various trade-offs. We had the CTO of linear on there. We had James on there. We have Martin Kleppmann, who's the author of AutoMerge and the Local First essay on there. So if you're curious to learn more, this might be a fun place, very niche, all about Local First, but in case you're curious about this worthwhile

checking out. Awesome. We will link to that. We will link to all the things. James, anything to plug or shout out on our way out? Yeah. Just say if you're listening and interested in Local First, please do not let me dissuade you. I think it's super interesting and I am choosing slightly different trade-offs every now and then, but you get excited and you go and build and I am fueled by proving people wrong. And so if I say something that you disagree with, prove me wrong and go build the tooling and support the community. Johannes, I'm very, very impressed and supportive with all of the things that you all did with Riffle too. Also, I was following that for a long time. So fully love what you're doing with LiveStore. I don't have anything top of mind for me to shout out specifically. So that's all I'll say. I'm very certain that all paths will meet

again. Might be a couple of years realistically, but I'm pretty sure that we'll get a best of both

worlds. Awesome. Well, that's all this time. So we'll just say goodbye friends. Bye friends. Bye friends. Thank you so much. Fun conversation today with good friends on Local First. Is it the future? Only time will tell, but I think if applications like Notion can pull it off, that will be a big win for Local First and all it's offering. And hey, if you're at Notion or you know someone at Notion, let them know. We want to talk to them about this upcoming feature, how they're tackling it and all the good stuff. And I guess on that note, if you want to request an episode, the easiest way to do that is to go to changelog.com slash request. We love hearing from our listeners about what episodes they want to hear and we're happy to do it. Again, changelog.com slash request. A big thank you to our friends at fly.io, our friends at Timescale, timescale.com and our friends at Eight Sleep. I've never had better sleep. I love my Eight Sleep. Check them out, EightSleep.com. Their Black Friday sales are here. Use our code CHANGELOG and get a lot of money off. Check them out, EightSleep.com slash CHANGELOG. And to our friends at WorkOS. WorkOS.com. So awesome. Love the team there. Love Michael. All they're doing. Okay. BMC, those beats are banging. Thank you so much, BMC. But this week is done. This show is done. So I guess we'll see you next week.