Exploring Local-First Applications and Data Synchronization Challenges: Part 1 - JSJ 654

clear in my social media representation. So at that time I switched my Twitter handle from getifi to getifi at and then the name of that company. And then I worked there for ten months or something like that, and then I was not working there and I was going to switch back to just straight up Getify, but then we had already had the rename of Twitter to X and I was like, oh, well, let's go with this.

So I just went back to Getifi X. But again I still have that other Getifi account, so one or the other, but I mean the active one that I'm using is the getifi X account.

renaissance re imagining of JavaScript around that time. I had made an earlier bet, many years before that, that I was going to want to be an expert in JavaScript because people are going to want expertise, And that was

going to be a good career path. That turned out to be a good bet, But I made that early bet on JavaScript started focusing on that, and so by that time that JavaScript started to take over in the more public sense, and we started to have you know, JS comp I remember in two thousand and nine the first JAS comf in DC. We started to have conferences around JavaScript, and there started to be job descriptions around JavaScript,

and I had some pretty strong thoughts. Having already spent quite a bit of time with the language, I had some pretty strong thoughts about it, so I started trying to participate. The first thing I was known for was a dynamic scriptloader called lab jas that came out in early two thousand and nine and got pretty big. Was used on quite a few big sites like Twitter and Vimeo and Zappos and a few others, and so that's

kind of the first way that people knew me. You fast forward another couple of years and all the fame of a tiny two kilobyte library had faded. I'm saying that tongue in cheek, but that had faded. I had started to do some conference talks around various JavaScript and performance aspects, but I really felt like, I had some things I wanted to say about the language itself, and I started writing the you Don't Know JS books, and

that is how most people have heard of me. Is the sixth volume set, the sixth volume of the first edition. Second edition is a little more complicated in its status and length. But I came back, So the first edition was released in twenty fourteen and twenty fifteen. Then I came back in twenty twenty and started the second edition, and those are kind of on the shelf now, not really actively being developed. But that's yeah, two editions of

a six book series. Basically, okay, cool, all right, Yeah, and say I should say specifically just so that people are aware if you haven't heard me say this before the title of the book series obviously has several different layers of meeting. There's obviously a bit of a tongue in cheek kind of joke about the old you Don't Know Jack trivia game and some other things like that, But it was never intended to be an insulting name

the way many people took it. It was actually intended to be a challenge to approach JavaScript with a more open mind and a more active I'm going to always be learning kind of a thing, which is why the second edition added the word yet to it, you don't know JS yet, because I wanted to make it even more clear that the point of this was actually to kind of be hopeful and to spur people to learn the language more deeply.

do it for them. It sounds a lot like today, actually, But what we had at the time was the JavaScript the Good Parts book, and that book essentially said, hey, I Doug Crockford have surveyed the whole JavaScript language and I've figured out that most of it sucks, but here's this tiny little subset that's really good, and you should

learn that. And I really wrote my book series and then the subsequent courses and everything else I've done since as a response to that book set to say I don't think you should learn only a small subset that one I opinionatedly, you know, put a linter for I think you should learn all of the parts of javas.

And it seems it seems really timely. I think when I first saw the tweet, between the time I saw the tweet and we got you scheduled, like it was, it was something that was you know, in the nicheness of its hype cycle, and now with all these with DHH making a stir, I think that some of this is actually maybe Local first itself is not on the rise yet, but I think that it's going to lead

to being on the rises. People are talking about performance and five dollars a month BPSS and whatnot, So yeah, it is.

I'm not going to go through all of those. You can read them yourself if you're interested, but I will kind of summarize the one big point of local first, and we'll try to distinguish that because there's a lot of other things that people think it is or isn't. But the main point of local first was to kind of tackle head on this very clear trend that has moved nearly the entire web and in fact most of

software around it, towards a cloud centric model. And the tackling trying to go out this head first is to say that one of the big problems with a cloud centric model for architecture is that you make that cloud required, and the cloud in this very big amorphos sense, is not nearly as ubiquitously guaranteed for every user as we might like to believe. There are a variety of reasons why my version of an app that's on my device and the thing that it needs to talk to up

in the cloud might not be able to talk. One, I might have spotty or no internet. Two, there could be some sort of large Internet wide or you know, service wide outage in a cloud. Routers, dns. We see those things. Yeah, we see these things happen, and I think I personally resonate with There's actually probably almost half of the Internet's users, at least a third to a half of the Internet's users, live in parts of the world where both power and internet are not guaranteed unlimited assets.

These are resources that are quite constrained, they're metered, they cost a lot, and they basically can't afford in one way or another to be constantly cloud connected and constantly sending all of the data back and forth. So what Local First did was it came along and said, the way to start tackling this one one peg of this is to put data. The source of authority for data should be on a user's device. And by data, we were specifically talking about the data that is relevant to

or matters to that user. We're not saying that, you know, all trillion gigabytes of Amazon's database needs to be on everybody's phone, but the parts of that that they need should be on their device. And most importantly, I would extend that to say, the stuff that I create, or the stuff that is created about me, that's the stuff that's relevant to me, and that stuff, the source of authority for that data should be on the user's device.

That does not foreclose having cloud servers and having synchronization and all of that, but it shifts the whole mindset to we start with the user's device and we build up, we progressively enhance from there, rather than starting with the assumption that everything is cloud based and if you don't have connection to the cloud, you're dead in the water.

a server and sync up. And the example that Travis gave was a scuba diving company who would be out, you know, they'd be out on a boat out in the water obviously where you scuba dive, unless you're in a pool, and you know, you want to be able to collect all your customers information and so on and get it in there, and then when you get back to shore or back within Wi Fi reach or sell reach or whatever your technology is, then you can sync up with your server and get everything simpty sync up

that way. So just another scenario where local firsts would definitely come into play.

part of the Internet. And it's been said before that spotty or intermittent Internet is actually a much more challenging problem, both for developers and users than no Internet at all. And so I think we definitely we need to embrace the idea that for the Web to truly reach all eight billion people in the world, we have to think about the residency of data being much closer to them.

We did have, you know, a brief few years where we said, well, if we just put more servers in more places, and if we hang giant balloons up in the air, and if we have satellite internet like, we'll just we'll blanket the world with Internet and that'll be the fix. That's the you know, techno billionaire's perspective on things. But I think builders of the web need to embrace this local first principle of making the server, making the

cloud optional as opposed to required. And it does bring in a whole It solves a bunch of things, but it brings in a different set of problems, and you mentioned those, the synchronization questions and the whole concept of synchronization data structures like CRDT. You know that that's now a big thing of discussion where that used to just be a niche academic topic, but we have got dozens of companies that are trying to build commercial solutions around

sophisticated synchronization mechanisms. When you have data on a device that needs to synchronize with other devices and with cloud servers.

minimal as possible. So that for your third world countries, for your places where there's a poor connection, maybe only three G instead of five G, et cetera, you've got less to download.

So it seems, as I ramble on here, I guess you could say it's sort of minimizing that and making it less of an issue because you don't have all the data flowing back and forth as much as you do with JavaScript. Or is that a join issue?

the application itself. Because that's another thing, like if I have the app, I really should have a continuing to work app even if I have no internet, right That's that's the offline first part of this, which is only part of the umbrella. But I should have an app that continues to function even if the internet connection to the web server is down or you know, non existent because they went out of business. You know, I should

be able to keep using that. So there very well might be a trade off here where the initial experience is a little bit more like an app install experience

that is not instant on. And I personally think that would be better for the web to go back to not trying to fake the instant on experience and instead embrace the idea that I'm not websites, but if I'm choosing to install an app, it really should be a thing that I'm willing to wait three, five, ten, twenty seconds whatever it takes to get the whole app and

whatever data I need synchronized onto my device. You know, you could take a page out of Google's book, Google Crumb's book and put little you know, dinosaur jumping games in there while you're waiting. I mean, we can go back to the days where we had you know, better that better experiences than just those dumb spinners that can engage people and let them do things. But another point to this is that a local first experience should work even if if you don't have even if you don't

yet have your data. So honestly, maybe having an instant on experience as soon as you get the code, you should be able to start creating data, even if all of the data that it's going to merge with has not yet downloaded. So I think there's a lot of complexity in terms of those trade offs, but it is being intentional about saying that users should be able once they have a piece of data and they have an app to work on that data, they should be able to continue to do what that code and data enabled

no matter what from here on forward. My best use case to describe this, it's just one personally, but when we think about bank account apps, generally people think about bank accounts. Is the only use case is I want to know right now, instantaneously what is my current available balance in my bank account. But there's a tremendous amount of information in my bank account that has nothing to do with what the latest thing that I bought at the grocery stores. And that data is on my device.

I can see it, I can interact with it, I can search it. Except when my internet goes away, Now all of that's completely gone. I can't go back and look at what I bought at the grocery store last week. Because they make the assumption when they build the banking app that the only way that I want to use this app is to see current incident. If they can't give me that, they don't give me anything, well, that's bonkers.

I think that's my data, very clearly my data, and I have an app that's able to render and work with that data. So a local first app would say you can continue to look at all of your previous bank account transactions and read them and search them and categorize them and do whatever you want even if you don't have an Internet connection to look at your live

account balance. That's I think what we're missing is that we just assume that live everything is the only use case that matters, when actually there's a ton of use cases that don't require that live connection.

The way that people make money is that for the first ten years or so, they just hand off the business from one investor to another as they go through seed round this A B C, D E, F G H I J K lemono, you know, and then and then after thirteen billion dollars, maybe maybe they become profitable, but most likely they just they just flyn So why why, like what what's why would anybody care about, you know, the people in these spotty internet areas because you know,

they have no money to pay for the product. So in terms of growth users, like, yeah, I guess you could. You could make an argument for say, yeah, there's a lot of people out there with spotty internet. You could get them onboarded as users if you're the only one that's actually trying to onboard these users, But then you can never count them in a metric as like potential customers.

There's use cases around uh, construction and survey companies that are out in the field and they're nowhere near where Internet is. They're collecting tons of really useful and very expensive data that they need to sell to other people or synchronize with their company. But you know, we don't

even have to get into the big companies. There are tons, literally millions and millions of people in the world, tens of millions of people of the world who are a one man, one woman business, a one person business, uh. The fish farmer in somewhere rural. They may be collecting hundreds of thousands of dollars worth of product that they're going to take to market. They are very much somebody

that you can monetize and treat as a customer. But when they're out there collecting all of those fish and they're not yet at the market with it, they're not somebody who has Internet, but they still absolutely have tons of potential and should be treated as a valuable customer.

And that's not to even get into the larger moral question of we ought to treat everybody's access to the Internet as an important human right I believe, as opposed to only a right that comes if you're willing to pay for it.

I get frustrated all the time. I mean, living here in Utah, things have gotten a lot better in the past ten years. But it used to be sometimes when I was going between cities because there's these little cities like Mapleton or Pleasant Grove is kind of booming, but they were really small, you know, and so I'd be going going between cities and not having phone, like really

good phone reception back when I was in college. Now now it's you know, because of all the tech booms that have happened, like all the past years, are being brought up and turned into business parks. A lot them are just sitting there empty, but they're there nonetheless, and and yeah, so it's it's a it's a bit better.

to be customers, not users. But you know they're the one percenters, or it's the one time they're out there, you know they don't have another option anywhere. They're really going to be that upset that, Okay, while they're skydiving, they can't use your app. I mean, maybe it's not safe to use the Apple skydiving.

One of the biggest reasons is that if you long term reduce the amount of churn of data going back and forth across the wire. In fact, potentially you might even completely eliminate the need for these big centralized stores of your data. You drastically reduce the footprint that you need in the cloud, perhaps even to zero, but certainly significantly less. Are there things that you'll still always do in the cloud. Yeah, you'll host giant video files and

other CDN things. You'll do really complex compute out in the cloud with AI training. But there's a ton of the generalized CRUD stuff that we do out in the cloud right now because it seems easiest to do it there, and we pay tons of money to those cloud providers to do that. There's a lot of that that can actually be shifted to the user's devices. We see potential growth in peer to peer device communications through various different protocols, both web and native that can reduce the stress and

the footprint that you need in the cloud. And like we were mentioning in the in the pre show, people like DHH you know, and the thirty seven signals folks, and the things that they're doing, they're not they're not bastions of those, you know, they're not leaders in the local first community per se. But what they are saying is, hey, is the cloud really required? Or can the cloud actually

be optional? Are there other architectures there where we can move back down to You have an app, you own the app, you host the app, and you host your data. And I think that's going to lead to companies starting to ask those questions, Wait a minute, do I really need to pay hundreds or thousands or tens of thousands of dollars to a cloud provider when I could offload a lot, if not all, at least a lot of what I was doing and reduce the cost. I think

there's a huge business benefit to embracing local first. And just like with any other movement, you said, true, it's early, it's nascent, there's not a lot of standard, but that offers huge upside potential for the companies that decide to be early movers in that space, and it's always been the case that early movers have had huge upside potential. Yes, huge risk, but huge upside potential. It comes with the.

front end is a nightmare. And React came in and promised, like, you don't have to worry about state management anymore because we're just gonna re render the whole page. And we've seen how that's gone. You know, it's not been like this shining star of Oh, state Management's not a problem anymore. It's been another game of hot potato where well, actually we do need state management, but it's going to live in this this component now, Actually it's gonna live in

this library. Actually we're gonna put it back on the server.

Actually we're gonna stream it down to the client. And you know, it seems like every six months to year and a half sixty eighteen months, React completely gets like a whole fundamental redesign, and then instead of calling it some other framework, they just call it React seventeen or eighteen years ye, right, which is just like one of the most that's like the best brand thing that has ever happened in the universe in terms of front end frameworks.

Release a completely different framework that shares almost none of the principles of the previous one other than the syntax, and call it the same thing.

so here's what I would say. First of all, a tremendous amount, not all, but a tremendous amount of the current complexity in modern front ends is directly related to the choice that we made to centralize architecture on a cloud first model and then also try to tell everybody, even though all of that data and all of that code lives not on your device but out in the you know, in the ether somewhere, we're going to make it look as if it's as close to instant on

as possible. Those two things have conspired together to create an entire, multi billion dollar industry of web performance optimization and literally dozens and dozens of these complexities that you're talking about, most recently the shift back to server side components and server side blah blah blah whatever. Most of that I think is chosen complexity, not necessary complexity, but it's been a choice that we've been continuing down that route.

And Local First says, actually much of that, not all of it, but much of that is not actually necessary. If the code is resident on somebody's device, If we build an experience where it's very durable and very stable instead of it's constantly changing every five minutes on every page, load a durable and stable experience, and we put the data where somebody needs it to reduce the amount of

the need of all of that back and forth. What what you're basically doing is you're saying all of the complexity that we have around eventual consistency, which is I think one of the worst terms we ever invented as technologists because there's absolutely no consistency anywhere. It's a total farce. It's a never consistency model.

to their business logic and their cloud back ends. They're already having to deal with massive amounts of complexity of all of that state management. And I think I think

that's the hidden complexity that you weren't talking about. We have all this front end complexity, but the balance of that is all of that hidden complexity in our back ends, and we have tons of giant frameworks and messaging systems and all that that try to manage all that stuff of database architecture complexity with replication and all of that, and basically local firstus saying we could eliminate most of that if we stopped trying to pretend that the only

way for this experience to happen is to require a round trip. We can have round trips when we need them, but we don't have to require that to gate the

user's experience. We can install an experience for them. We can put data there that they need most frequently, and we can put the logic there that makes that data do what that user expects and stores whatever they've changed, and then in the background synchronizes that to wherever it needs, whether that's peer to peer to another device, or whether it's through a traditional sending some synchronized data back up to a cloud server, which is what many of them

are doing. But we're just simply saying that user does not have any anywhere near that amount of complexity. So this is a very different way of building applications. Does it have its own complexity, of course it does. Nobody's saying this is the silver bullet and it's just two lines of code and it's all done. But I actually think if we were if we went forward five years and then we're to take a really good local first app and there are several out there, linear and some

of those others. If we were to take their code bases and compare them to the equivalent cloud centric code bases, I really do, genuinely believe that the overall complexity, the overall number of moving parts goes down when you embrace these principles.

rendering processes. And they're expected to also be a programmer in JavaScript, where they need to have developed the acumen for writing programs. And these three things are literally they're all opposed to each other. CSS has nothing to do with programming being Honing your skills at CSS means that you have to give up honing your skills somewhere else,

like in programming JavaScript. Honing your skills and your understanding of browser mechanics and eventful paints and uh, the dom APIs you know all that C plus plus context switching. You know that that's that's systems level programming and and and that's very different from application level programming. And so, you know, like front end developers are just being asked to do too much, and I think that's why they're failing. And asking them to then also be good at data

transformations and etl. I just I think it's too much

because they're already burdened. Either we need to split up and say you're a front end programmer and you're a front end designer, or your front end programmer and you're a front end uh layout manager or you know whatever, so that they can actually focus and become good at those areas of skill and really be excellent, or or we have to somehow provide something to reduce the complexity, which again I think is the allure of React, because it's kind of saying, Okay, we're going to take care

of the CSS, and we're going to take care of the the the DOM life cycle, and we're going to take care of obscuring away that you know, the JavaScript for this this new the the r S R R S X now what jas X language, you know, So there's it just seems like there's a lot there, and I'm very I want it to happen. I'm just very skeptical. Show me the path. How do we how do we add more data manipulation on someone's plate and make their life simpler.

trade offs that are being made. And so the people that are designing those engines are starting, at least from what I can see, I'm talking about things like replicash and a few others that are out there. So there's

some things that you can google. There's a number of solutions out there in the local first space and what they what many of them that I've talked to or heard from are saying is we do actually have quite a bit of industry experience around building the back end logic that knows how to talk to rms that are

backed by relational databases. So if we can build the replication logic and the the merging logic into those types of abstractions, we don't have to get people to learn an entirely new way of programming that type of what we would call back end logic. And I'm actually I'm using the air quotes around back end because I'm going to self service myself here for a minute and call back to a term that I invented back in two

thousand and nine and twenty ten called middle end. What sits between the front end and the back end is the middle end. The way I originally conceived of the middle end was it was all the plumbing in the bottom ten percent of your front end application and all of the plumbing that was in the top ten percent

on your server. And what makes those two things work together and talk together, whether that be templating or casing, or headers or session management or any of the data formatting, validation, all that stuff. That's what I call the middle end. But what I think is going to happen with local first is that there will in fact be a specialty.

Whether we call it middle end and I get any credit for it remains to be seen, but I think there will be a specialty for the back of the front developer or the middle end developer who builds a significant portion of the back end of that application. They move it out of what they would traditionally host in a cloud server and they put it into the app, and they build it around these abstractions like being able

to make relational database queries in an app. And even if that, you know, like you have a SEQL light in the in the client, because we can now do that, we can with the advent of WLASM, we can do all kinds of things, so we can literally have a

seql light client in the app. And that's what a lot of these companies are doing is basically saying, let's layer an o RM on top of an actual database so that I'm writing data into a sequel light on the device, and I'm also replicating those those right changes in the data off to a relational, you know, database that may or may not be seqal light up in a cloud server, but they're using that ORM layer to do this. I think a lot of that complexity that

you're worried about will be built around that. That's my prediction, and I think that there will be people who will really like that because they feel really comfortable in that, and now they'll be able to move a lot of those same skills into the back of the front or the middle end development in local first. I think there will be some people who will hate that and say SQL sucks and relational databases suck and we shouldn't use that.

But that's why we're going to have lots of different options, right, So you may have a you know, a group of providers that choose to build that around relational databases, and others that are going to make something that's going to look a little bit more like graph ql, a little bit more free form. I think we'll see that and a half dozen others that I haven't conceived of yet. But I don't think you will ask app developers to start becoming experts on the deep academic theory around CRDT.

I think that's what these providers are going to solve. They're getting close to solving, and they're working on hard trying to solve.

as Mango dB. If somebody were to use that on the back end, I could see how that could be very difficult to convert between a sequl light structure on the local and then a Mango database on the back end.

index dB and json objects and things like that. We don't need a Mango dbo RM on top of Jason objects if that, if you don't need the relational so I think the reason why we get big powerful engines like a sequel Light or post Grace Light being compiled to the browser is for all that relational stuff that's pretty hard for people to go and invent themselves. But if you're really talking about uh kind of document level storage stuff, there's already actually a pretty good and solid

way of storing data. We have not only the index dB, but a lot of people don't realize we actually have fully cross browser the Origin Private File System, where you can create files and store arbitrary data and both. In truth, it is absolutely true. I've written a library around it, so it's absolutely true. I'm act check this, Okay, please do if you If you get both index dB and OPFs the Origin Private Final System, both of those have essentially up to about two thirds of the device's disc

space that the browser makes available to them. So in the old days when we had like local storage and it was limited to five megabytes, and nobody could even imagine doing anything like, you know, like a real apps

back end on those things. Now that we have index dB and OPFs, and both of them have very solid access to disk space, and I just we're going to see a big explosion of people building real data storage in the client as opposed to kind of stuffing some stuff in local storage the way it used to be. And I think a lot of people are not didn't realize that that happened. But OPFs is absolutely already happened.

There's there are complexities around it, but you can work around those with libraries, which again that's that's what I've worked.

in the client model. Index dB has a whole bunch of complexity around it, and web sql was like this higher level, you know, SQL light type of interface, and a lot of people said, I don't I don't really like the indexdb. So there was this favoring of web sql in the early days, but there were some browsers that basically said, we're absolutely not going to ever do a web sql like Firefox, We're not doing web sql,

We're only doing index dB. And so whether it was the better of the two options is kind of irrelevant because Browser's just sort of decided for us that the thing that we got was index dB, and everybody then agreed and just did it. Now. Indexdb again pretty low level API, a lot of complexity around, you know, transactions and other things like that. I don't even use index dB in that sense. There's a library called index dB keyval, IDB DASH keyval that creates a literal key value storage

abstraction on top of Indexdbuh. It's got millions of downloads, it's it's hugely popular. Earlier, I've never dealt with indexdb other than to use that library, so I look at indexdb as a really powerful key value store.

as its native API is. A lot of people use index DV for that, and I would I would make the case that index dB should be the default client data storage over local storage, not only because it has larger disk space access, but also because nxdb can actually be accessed from workers and done asynchronously, where local storage and session storage cannot be accessed from worker thronts, So that makes it a more flexible data storage.

there's still a lot of security considerations around it. But there's the Virtual Private file System of OPFs, which is a reserved area of disk space that you can read and write files into and its origin locked. That actually got much more widespread consensus among the browser vendors, but

there was performance concerns around it. So people wanted an OPFs interface where they could do easy kind of synchronous reads and writes from it, and there were performance concerns about you can't do synchronous reads and writes on the main thread because that could block things and whatever, and so what we got was this bifurcation where there was an asynchronous API that you could use from the main thread, and that one also has not yet achieved this sort

of baseline parody because notably Safari does not support that main thread asynchronous API. However, all of the browsers did implement the synchronous read and write from workers, willing to take on the complexity of burying your storage logic inside of a worker. You actually can do OPFs with synchronous reads and rites across all the major browsers. I would argue that is actually baseline in that subset.

There's index dB, and there's OPFs, and that library supports both the OPFs in the main thread, but then you know, it doesn't support all browsers, or there's also the worker version of that which does work in more browsers. You just have to be willing to do the you know, some of the reasons why people don't like worker based logic is because it can it can make more complex your security headers, like your CSP policy on a site or things like that. You have to be a little

more careful. But if you're willing to go down that route, you can use OPFs in all of the major the stable versions of all the major browsers and devices today. And so I'll drop a link to the storage library that I wrote that tries to just give you a very easy, consistent key value abstraction across all of those. So my understanding is the way that that works in practice is that you create a main thread API that

resembles closely the worker thread API. It transforms data into a buffer and then sends it as a shared buffer object across the worker thread, and then the worker thread sends it back as a shared buffer object, and then it gets re encoded. That is that the basic cycle of that. So sharing data between workers is actually a bit of a complex thing, and it's unfortunate that it

is so complex. But sharing data between workers can either be serializing to a string and sending that string of data across the inner process channel, or this newer standard

of these transferable objects transferable objects. It's a more complex programming paradigm, but it is effectively that you use stuff some data in a type deray, and then you tell the browser I'm relinquishing control of this type deray to a thread and I can no longer read from it while that thread has control of the type deray, and then the thread now instantly has access with zero copy to that same shared memory, can read from that type deray the literal binary data from it, can read the

bits from that, do whatever it wants right back to it, and then relinquish control back to the main thread. That's what transferable like, being able to transfer things. Most people don't go that route unless they have massive amounts of data that they're trying to send, and by massive I mean like one hundred megabytes for more. Most people, Yeah, I think when they're sending data back and forth are just serializing to Jason and sending it across.

like a couple dozen lines of code. You could look at the code of how I'm managing those workers, and you could very easily write an adaptation of that that instead of sending the data across in Jason did so with a more sophisticated, you know, transferable or you know, bury it in a binary array and a typed array and do a transferred object kind of thing. You could do that. It wouldn't be that hard, all.

You're not really doing a lot of that manually, although you could, you know, you know, AWS as a dashboard, you could go in and take down a server or put up a new one if you want it. But you're basically creating these these policies so that it's managing your your scale and your growth for you. I don't have any more understanding of cloud than what I just said that is the sum total knowledge, because I never

got into that space. There's probably listeners here who would have a very different and much more detailed view of the cloud. But what I understand the cloud because I have a VM online line ode right, and I don't call that the cloud. I'm paying for a virtual machine, but I do all of my own management, and there's no built in scalability where I get a new VM just because I get you know, slash dot it or at the homepage of Reddit or something. I have to

manage all of that stuff. So I don't call that the cloud because they're not really doing anything for me. I'm just renting a bit of memory and CPU cycles from them.

And that was confusing to me because, like I said, I while I've heard the term cloud, it's gone from meaning I don't host the server in the closet at the office, I co locate it, or I use just a portion vert via VM, to now it means like it basically, it seems like it means anything that marketers wanted to mean at the moment.

I need out of that stuff. Those are very different system that men thought processes, and they take very different skill sets. So I think there's a distinction there to be made, and I would call the ladder of those cloud versus you use the term co locate. I mean I was doing that back in ninety seven in college.

I was running a server in my apartment in college, and then I remember the day that I was like, yeah, I can't do this anymore, and I went and bought a one U server and stuck my hardware in a data center somewhere that certainly was not the cloud, because I was still completely responsible for that server. They just gave me a power plug and an Ethernet plug, all right.

And then, so what is the alternative to the cloud in terms of how the data is going to work? It doesn't seem like web RTC is really there yet, But what's the alternative? And then what are the places? How do we distinguish between the places where local first makes sense and local first doesn't make sense because it sounds like to me, Amazon or Walmart search would never make sense. Bank access and email access seems like that would always make sense, and Twitter would be somewhere in between.

So you give me your take, and that you know, given that context, these are.

justification for local first. That's part of the equation. That's not what brought me to local first. What brought me to local first was actually a personal convection around the importance of the autonomy of users owning their own identity, taking that with them wherever they go, and owning their data. I make the assertion in a couple of different meetups and conference talks recently that data that you don't physically control is data that you don't own. In other words,

custody of data is the whole game. If I have data that theoretically is mine, but it's actually physically in the custody of a cloud server that's behind some business model of a company that I don't own and control, then that's no longer my day. I'm renting that data back, and I believe that's the ransom.

billion dollar businesses don't win. I think we have to concede that we've had a whole other sphere, which we're not even talking about here. We've had this Web three crypto movement that for fifteen years has been saying we're the answer to that. I actually worked at a Web three company for a while, and they've said we're the answer to all of that centralization and give everybody their stuff.

I worked for a Web three company and for that six months was like continually confronted by how easy it was for people in that space to just grin and blink away. The big gap between the way the web is currently built and the way users currently experience that and what Web three is. And so I left there thinking, I don't know if we're ever going to get to Web three, but if we're ever going to get anywhere forward,

we need to evolve the web. And I started calling it web two point five, where the web goes to more of a users own their data, users own their identity, the experiences are more installed rather than accessed on every round, Like you know, every time you go to a web page,

you're effectively reinstalling that web app. And that's bonkers because we wouldn't treat native AP apps that way, where every single time we opened up or clicked a button in an app, we re downloaded the whole app or even part of the app.

I'm just saying that that's the allure, and there is something to that, Like I think I've taken a look at swift UI and I think Android jetpack is the same and swift U. I when I hear if I close my eyes and I listen to the conference talk, I hear react react, react, react, But when I open my eyes, I see something that it's like this looks like this looks like it actually solves the problem, which is like really surprising because I was, like, I abhorred

reacts so much. But swift Ui is something that's really intriguing to me. How can these two things be And I don't know. There's like there's the promise, there's what's on the conference side, and then there's the implementation. And I think when you look at something like swift Ui, it's the same promise. But I think they might have the implementation right. I don't have enough experience with it to say, but I think they might.

and people have just sold as a reality that isn't. They're trying to get closer and closer to pretending as if the app can reside in both places at the exact same time and there's no cost over the wire. If you didn't ever start with that as your goal, which I never did, then you wouldn't have ever gone down the road of trying to do server side component

rendering and all of that stuff. That wouldn't have been the way you tried to fix it, and local first fixes it in different ways that I think are much less complex. And so that's really the only thing that's happened in the last few years of development that you might have to abandon. If you really wanted to embrace local first, you would have to kind of get away from that server side component way of thinking that people are starting to get excited about and enjoy. But all

of the other things that you could bring. You could bring a straight up React fifteen virtual dom application straight to local first. You can do what I do, which I didn't even use the front end frameworks. I use templating and I'm super old school, but I use mustache templates and you can do that. You can use reactive things like view you know, and their signals in spell. You can do any of those things for local first development.

The only thing you can't do is offload significant amounts of your front end logic to a back end, because you really need to stick that back end on the client to embrace what local first is about.

the core API, the JSON where things kiss. That's the middle end and that and that's where that's the problem the graph Ql was kind of trying to solve. If you if you move graph QL's complexity to the middle end and you give people that are purely on the front end the the autocomplete of graph ql with local storage. I think I think maybe it wins.

that graph ql gives you. That I think could have been a winning strategy, and that that's really I think that's compelling because I look at graph l, I look at the promise of it, I look at those autocomplete tools and think, man, I love it. I absolutely love it. I just yeah, how do we? How do we? Maybe maybe that could be the the poisoned apple or you know, uh wrong term, but you know that the hook the addicts.

In fact, it's saying the opposite. Bring whatever uh application building techniques you have, but but build more of those things into the client experience. The thicker client, to borrow a term from the nineties, Build thicker clients that have more of that stuff built in, and stop assuming that the only place for data is up in a cloud server.

There's lots of other ways. And you asked you asked earlier about like how do we you know is webs is is web RTC or web sockets or whatever, like how are we how are we gonna have apps?

It's zero server after the signaling, but it still requires servers that can be quite expensive and quite uh single point of failure for the signaling aspects because of all the complexities of not traversial and stuff like that.

have that backwards. It's stun in turn. But whichever one of those is the media relay servers, there are not free ones. There are companies that you can pay for, but it's you know, hundreds of dollars a month to pay for a scaled out media relay server. Anyway, So weber TC if we thought about it as one standard, I think it's actually a really good API. But this signaling problem is kind of the fly and the oightment or the poisoned apple to borrow the term from you

from just a minute ago. But there are wrong There are options for fixing the signaling issue. One of those options is if you move from purely web into hybrid apps, if you use those native wrappers with web views, things like towry, things like electron, things like socket supply. These these hybrid the old days it was like phone gap and ionic and stuff. There's there's dozens of them, but those native apps have the potential to kind of break outside of the current restraints of the web and give

you true peer to peer communications through networking protocols. And so there are multiple options there for a web app to be given a slightly extra superpower, which is let you communicate. There's also potentially, I really hope this happens, there's a there's a working group working on a standard for peer to peer local peer to peer communications which would be able to tunnel between my two devices using things like Bluetooth or local wife, which is a standard

that Android and iOS put together. So there are web standards that maybe hopefully land someday that are going to let us let our web apps talk directly peer to peer, even without those native wrappers around them. But I do think that that will for people that decide to go that route. That's not local first, that's kind of beyond

local first. But when you go beyond local first to trying to get closer to a peer to peer architecture of an app, that's where you see the true benefit of potentially shutting down your cloud server entirely and for closing on your entire cloud bill, because most of what you need to communicate with can actually tunnel over these peer to peer networks, and so I think that's a little bit further out from local first, but I think

it's a step along the way. I think local first, and then that will come after that.

ransom fee. You have to be willing to think about your business model potentially the way that we used to think about business models, which is not how do I capture as much possible value from every single user as humanly you know you can imagine versus how do I capture enough value that my business is viable and growing. You have to somewhat restrain the greed when you design business models that way.

So you have to make it a subscription. I mean, even when you look at the companies, the profitable companies Microsoft, Apple, they're actually profitable and they're turning into subscription models because it's the only way to grow. There's no growth opportunity left. Word to capture the planet.

the pro tier, but actually now there's the ultratier. We told you was the ultratier, but four K is actually moving to the Ultra plus tier.

Let's imagine that I've built a calendar app, kind of like what you know, thirty seven signals did they build a calendaring app. I build a calendar app, and I sell it for ten bucks and I let you run all your own data. You can host it wherever you want on a three dollars VM or whatever, and I don't charge any subscription fee. But then let's imagine that I come up with some really compelling cool thing, like an AI summary of a calendar or something. I'm just

making something up. Well, I can deploy services out there on the peer to peer web that, say, you can choose on a per calendar event basis to opt into this, and it's going to cost the equivalent of a dollar of cryptocurrency transaction for you to have that data that you send from your calendar send into this black box, and then this smart contract sends you back your AI summarized data or whatever. I'm just like, I'm literally making something up on the fly. But I can monetize that way.

I could create services out there that people can choose to use on an OLI cart basis. And if I make those services is compelling enough and I make it easy enough for people to pay for I think you can grow without locking people into subscriptions. But I do concede that the vast majority of the world, and basically every investor in the world, is only interested right now in the subscription based business models.

it's kind of like rust right, like Russ. They want an alternate universe in which programming is perfect without trade offs other than the trade off of learning rust right, but it and the Web three people they want this perfect universe that literally can't exist because like first principles and incompleteness theorem and but and so there. Instead of saying, Okay,

we're gonna we're gonna evolve the web. We're gonna take what we have and we're gonna make it one step towards our ideal, they're saying we're starting over from scratch, but not just from scratch, like really from scratch, Like we would get rid of TCP if we could, but somehow we haven't figured out how to do that yet. Like if the Web three people had their way, you

would have to buy a proprietary network card. And by proprietary I mean not in accordance with any existing standard and not useful to any other standard it would.

that world, having spent a brief six months there. I'm certainly not a spokesman for Web three, and I'm not here to shill for some Web three coin or something, but the underlying culture that I was exposed to in that world when I was trying to learn it and trying to figure out they hired me because they wanted me to help bridge the gap from Web two to Web three, and so I was trying to look at it from that perspective, what's missing, what are they assuming

that's not true? And all of that. And one of the things that I got from the culture that the cyberpunk genre of writing seems to be an extremely important part of the culture in Web three. And if you read people like Neil Stevenson or whatever. I'm not a big reader, but I did read a couple of his books trying to get this mindset a little bit more injected into mind. And if you read that, I think they're actually saying something a bit opposite of what you're saying.

I think what they're saying is not we want an idealistic, perfect world, but they assume that the world is inevitably going to fall in on itself in its current track, and the only way to avoid the certain doom. I'm using really big words like I was a you know, a writer. There's something there, but the only way to

avoid that is to jump to their view. So from where from where we sit in a mostly functioning but certainly not zero problem world, we look at them and say, oh, well, those folks are just you know, they're pie in the sky and they just they want things that are never going to happen. It's completely naive and idealistic. But I think their perspective is, man, you just don't even realize that the track that you're on is already going to fail.

It's inevitable, and we're just trying to get as many people to jump off that track before the train goes off the rails.

will actually build real viable solutions around. I'm trying to put together those local pieces. So that they can be used. The other thing that I wanted to say, which is related butt separate, which is a recent initiative that I have around what's called what I call bring your Own JavaScript. There has been a decidedly like anti framework tone to our conversation, and I just want to state clearly for the record, I am not anti framework. I am not

down with React and view sucks. The people who created those things are far smarter than I am, and I look up to them. I wish I was as good an engineer as many of the people that design these systems, and I'm glad they exist and they are solving things in ways that many of our engineers in the industry really appreciate their I am not the great spoke when I say, I think there is a tremendous amount of value there. But what we have lost is what I lament.

What we have lost is the appreciation of the importance of understanding how the systems work under and how sometimes

those aren't the right answer. We've lost that appreciation, and so BYOJS, bring your Own JavaScript is really designed to not say down with frameworks and down with Typescript and down with tools, but rather, let's carve out a separate space where we can champion those who still believe that those skills and techniques are important, and we can mutually sit alongside the much bigger behemoth of the framework first

crowd the stuff. So I just wanted to plug the stuff I'm trying to do around local vaults and using past keys to create our identities and protect our data locally. And then this Bring your Own JavaScript is trying to champion JavaScript without the requirement to go very heavy on framework and tooling. Those are things that I think will be very important keys I hope in the local first movement. But I don't own the local first movement in any way, right.

I'm one guy. I don't have a company in local first. There are many many other people out there, so don't I hope that people won't take my little slice of thinking about local first as gospel. There's a tremendously big community couple thousand people in the Discord community for the Local First web dev which we'll have a link to. I invite anybody that's curious about local first, even if you totally disagree with how I've presented it, but you're

still curious, please come and join that community. Because there is a big tent, there's a lot of room for a lot of different ways of doing it. I just have my own little tiny slice of how I'm trying to go about it.

And I'm gonna Utah JS COMF twenty twenty four. I thought it was a great conference because I think this is the second year in a row that I'm seeing the glaze coming off of people's eyes or no, that's not the right expression. People are starting to.

functional server side events will fit in a tweet. Well, okay, I put it in an image in a tweet, but anyway, Yeah, and I'll give that too. And I would look up the name, but I don't want to take up too much time what what the actual talk was called. But let's see sc in a tweet. Where did my tweet go? Oh, I don't have it, but there's that. Okay, that's not

that's oops that that RL went nasty but oops? Okay, anyway, so yeah, those those are those are two things that I'm going to pick right now, I've got I've got a couple other picks. Maybe I'll pick in the next segment. But that's utah JAS conference. Go take a look on YouTube. I just put the link in here, but if you look up utah js on on YouTube. The conference, I

really really thought there were some great talks. There was one that was the one hundred year web app how to choose technology that will survive that you know, if you if you if somehow it's still hosted in one hundred years, it would still work in one hundred years.

I thought that was talking was actually so many excellent talks is here because it was it was getting away from I mean, there was still some framework hype there, but it was getting away from framework hype and it was getting back to not necessarily back to basics, like

service side events wouldn't necessarily say basics. But it was mind blowing to find out how simple they are in comparison to web sockets, how performant they are, and see that that demo that was done, and there was there was three or four talks I went to where I was just blown away with I learned stuff and stuff that I feel is valuable that I'm going to use, and I don't often feel that way about the hype stuff,

but I mean a lot of that's my attitude. But anyway, so I got that, Kyle, what are your picks?

we were taken over by those things. I'm very excited about that, and I hope more people will kind of give it a look and kick the tires on this. They're going, we're a lot of resources that we're going to try to create for it. So it's not about creating code or libraries, but about creating resources that help educate around that.

ask the next question. So, Okay, I don't want to be abrasive, but like when people defend the position, then that gives me the ability to dig deeper. Sure, so thank you for that.