A Tale of Two Webs [eng]

Hello, hello. We're making sure that all of the audio and everything's working. Hello. Thank you so much for joining us, JSFW Days. I am thrilled to be back here in 2027. You know, it was four years ago, back in 2023, that I gave a talk called A Tale of Two Webs.

You see there, I am just now starting to give that talk back in 2023. But back then, I only had these boring two-dimensional slides, and now my slides are fully 3D world scenes that you can dive into and explore, assuming, of course, you are using the latest technical preview of Reality OS 3.2. Unfortunately, for the rest of you, I think the slides will still mostly appear two-dimensional. You know, it's that time-honored tradition of the web, best viewed in. Sorry. Anyway, so much has happened for the web over the last four years since 2023, and I mean, some really huge changes have come about. So I thought that it would be good for us to go back and revisit that talk from 2023, but I needed to update it for here in 2027. I wanted to present an update on how the web has progressed and where we might be headed next. So this talk is creatively named A Tale of Two Webs Continued.

You know, in some ways, the web is kind of the same today as it was back in 2023. We're still arguing about how to do state management and data binding, you know, hooks and signals. In fact, from signals, do you remember a couple of years ago when we took that term from C programming way back in the 1970s, we took that term pointers, and we repurposed it to mean variables that automatically update each other? You know, that's always fun. We're also still arguing about newer syntaxes for CSS styling. I mean, there was way back in the day, there was bootstrap, and then there was OOCS and BAM and foundation and atomic CS, styled components and even tailwind.

And then right after that came fluff CSS, but that was only around for a little while before it was replaced by no fluff CSS, and that took over. You see, if I had one big regret still, it's that our industry still keeps arguing and spending so much of its time focused on improving DX, the developer experience. But why are we just assuming that an improved DX will lead ultimately to an improved UX, a user experience? I think we need to shift away, and even still in 2027, we still need to keep our mindset focused on the user and not on the developer.

But you know, so much has changed, too. I was only hinting at those possibilities in my talk back in 2023, but I could not have even imagined how profoundly the web would evolve. I think the word that most comes to my mind is acceleration. Everything is coming faster and faster these days. And no, I'm not just talking about new JavaScript frameworks or the next version of React or Next.js. You see, as both builders of the web and users of the web, we here are making and benefiting from a completely different relationship between users, who are humans, and our devices. To the joy or maybe horror of many, the web today is its veritable digital cornucopia, a swirling maelstrom of AI-generated content, smart contracts on blockchains, 3D worlds filled with, well, somehow still selfie viral dancing videos.

But frankly, all that seamlessly dancing across every screen in our lives, from phones to tablets to watches to reality glasses to TVs, well, you already know all of that. But what is it that makes all this work so well? I think most of us can agree now that the biggest pivot point for the web was when we pushed and pulled apps and content kicking and screaming out of the cloud, way over and beyond the edge, all the way across the wires and the waves, directly and locally onto users' devices. It's when we finally realized or admitted that our best chance to weave the web everywhere into our lives was for all our devices to communicate directly with each other, peer to peer, to go fully zero server, as it were, the power of zero. But I'm getting ahead of myself. Let's jump back into the past, 2023, and let me remind you of some of the troubles I felt the web most needed to start talking about and trying to solve. So what makes the current web so broken? Let's ask ChatGPT to see if it has any ideas. Number one, poor performance of delivering large apps from cloud or edge servers to users' devices on each visit. Number two, loss of access to your data when offline or when internet connectivity is unstable. And number three, loss of information privacy. Well, thanks very much, ChatGPT. That's a great outline for the rest of this talk. Amazing.

That was four years ago, and yet it feels like only yesterday. Time really flies. So we have a poor re-download experience. We have a loss of access to our data when offline or with spotty internet, and we basically know data privacy. Certainly not the only issues that the web has ever faced, but I think we can admit they're big ones. And we've come a long way since then. For those three worst sins of the web, we've seen a huge turnaround. Sure, there were many doubters and naysayers, but a lot of us pushed the web forward anyway. So what does ChatGPT have to say about why these web apps have to be re-downloaded so often? Well, number one, browser caches are volatile. The larger an app is, the more likely the browser will be to purge some or all of those cache resources between visits. That means any one of those is going to have to get re-downloaded potentially multiple, multiple times. Number two, applications typically bundle most or all their resources and code into a single file. So even a single character change in one of those requires re-downloading the entire bundle, which can often be huge, multiple megabytes in size.

You see, your apps don't run here. They don't run in the cloud servers and edge servers. They live here; they're stored here, but they run many thousands and thousands of miles away across the wires and across all of the Wi-Fi and cell signals on users' devices, their cell phones, their tablets, and their laptops. And that distance matters because all of those resources transferring even once takes a long time, let alone being re-downloaded over and over and over again. Think how much waste of both the global bandwidth as well as users' time and the resources on those devices. The greatest lie that we ever told ourselves is that the web is a zero-install experience.

I mean, when you think about it, this is absurd given how unreliable the cache is. Actually, web applications are being re-installed on almost every single visit. So it really matters. And I think we really should be asking ourselves, how often are we making our users re-install their applications? I think most people think that the edge servers were how we fixed this, but there's still like a thousand miles or more from that server down to a phone. And that's just too far away to be completely honest. There are just far too many timeouts. This was probably the hardest to admit back then, honestly.

I mean, there were a lot of huge and popular companies who fully bought into the idea that the web was inherently needing to deliver on each visit type of experience. You have AWS and GCP and Azure, trillions of 2023 dollars invested, hundreds of thousands of businesses all over the world, building their whole web presence right in the middle of the cloud. You had hugely successful companies like Vercel going all in on web infrastructure as a service. For decades, the web had just entrenched itself in the client-server model.

It was really hard back in 2023 for most people to even imagine a web that didn't involve servers. Understandably, a lot of people didn't like hearing that maybe the web needed to move away from servers and directly onto people's devices. A lot of businesses stood to suffer the competitive advantage degrading if the web could figure out a way to truly decentralize itself. And obviously, that wasn't going to happen overnight. And those companies would not give up quietly. So most people just dismissed this idea as idealistic, maybe a pipe dream. But they were partly right, the web wouldn't go through that pivot right away.

It took quite a while. But eventually, pivot, the web did. The tipping point seemed to rise up maybe later in 2024, several years after LocalFirst first began chipping away at the foundations of the entrenched server-full web. I'm just glad we finally reduced much of the stress and arguing about how to optimize our apps and delivery from server to browser. All that noise about server components and versus static and server-side rendering, all this stuff about core web vitals, do you remember those?

Those web performance metrics like LCP, CLS, FID, it was all so confusing and distracting. I still don't know what any of those meant. But when we eliminated the repeat trip that bytes have to take to get rendered on a device, when we just installed those devices directly on the device once, most of the complication just went away. The smart folks who used to spend all of their time on those problems, they largely repurposed that skill and intelligence on, frankly, more important problems. And that whole serverless thing from like 2018 back to 2023, do you remember that?

I think everyone finally has admitted that it was bogus. I mean, everyone knew there were still servers in serverless. And that meant that most of the core problems of the web still existed, even if we had shifted the blame for those problems to someone else. You see, it was so much better for users as this shift started to happen. When businesses started moving their web experiences from browser server to locally installed, users didn't even realize that much of things were changing. But over time, the improvements for users started to become so much clearer.

Some of the early companies to make that shift were the pioneers and the bleeding-edge adopters. But by the end of 2024, it wasn't even seen as weird or risky anymore. Businesses everywhere, large and small, saw the announcements and the case studies of earlier businesses making the leap, and they got excited. The dominoes really started to fall. So how great was it that apps now launch in instant start mode? I mean, the same way all our other apps have always been, 500-millisecond cold start used to be the standard, and now it's like zero milliseconds.

But you know, that wasn't the only big problem the web needed to solve back then. So why does a lack of a reliable internet connection cause me to lose access to my data in a web app? Well, even if a web app successfully preserves its code and resources on your device, your data is usually only stored in the cloud. This is typically touted as a convenience for you to keep your data backed up and to keep it available on all your devices synchronized. However, if you have no connection or it's an unreliable connection to the cloud, you cannot access your data. How many of you have seen this icon? I see it all the time, especially when traveling. You see, when you are not connected, you are effectively data-less. Even if you are connected, the cloud can sometimes crash. And when it goes red, your connection just completely evaporates. You have no access to your data. Luckily, all those hero DevOps rush to the rescue, and they fix it usually pretty quickly.

But I just think we should be asking this question. Why don't we store it in both places, both on the device and potentially also out in the cloud? So what does ChatGPT have to say? Why don't we just store them in both places? Unfortunately, even though we've had many, many years of trying to evangelize this offline-first methodology, it seems that most apps, businesses, and developers, they just don't care enough. There has recently been some progress. Thankfully, a local first web development group has started up more on that in a second. But we need way, way more. If there's only a few hundred people that care about this, we need thousands, tens of thousands, millions of people to start caring about this. So this local first web development group is one of the things I'm most excited about here in 2023. All of the movers and shakers in this space coming together in one community group. And I invite you to come and join us in the Discord group and hear the talks and listen to the discussions and hear how we are trying to make this future web a better place. So local first might have sounded like this niche idea back in 2023, but here in 2027, we all know that local first is one of the most pivotal inflection points for us. One of the most important inflection points in the history of the web. So let's revisit a few pivotal tweets from back in 2023 that really signaled and summed up the mission of local first web development. We've come to think of the cloud as a convenient way to store information. But what happens when there is a problem with the server or the internet connection? Suddenly, we're unable to access our data. We've become so reliant on the cloud; this loss can become debilitating. This is especially true for businesses or systems that rely on it.

Local first data storage, on the other hand, solves this problem. With local first data, users can access and work with their data, even when they are offline, without relying on an internet connection. This allows for greater flexibility and productivity, especially for users who work in remote areas with limited connectivity. Since data is stored and processed locally, applications that use local first data can be faster and more responsive than those that rely on remote servers. Users also have more control over their data rather than entrusting it to remote servers that may be vulnerable to hacking or other security threats.

And it's important to point out that local first apps are just web apps. You can build them with whatever web framework and technology that you prefer. In fact, many progressive web apps already out there, you can use all of those and put them directly into this local first model. Well, mostly. I think I'll be a bit concerned about using React to build local first apps if React sees React server components as the default React. I've got to be honest, this is a bit of a disturbing trend. It's not just a front-end library anymore, React.

It's not even a framework. It's becoming a platform entrenched in the server with all of the inherent complexity that that comes with. I really think that was the opposite of what we should be doing. So local first has been advocating as a primary foundational principle that we need to be storing users' data that they should own and control first and foremost on their devices. But web apps storing data on devices has always been troublesome, up to that point, with all sorts of issues from a five-megabyte limit to purging data randomly.

Here's how I summarized those issues back in 2023. So unfortunately, storage on devices is rather limited to things like local storage or IndexedDB. And as I mentioned before, they are very unreliable. They can evict information at any given time, whether the user asks for that to happen or not. They're also limited to like five megabytes in most cases. So this is good for storing small amounts of information like a shopping cart, something like that, but not for large documents, things that users consider really important. And they absolutely would not tolerate it just going away accidentally. There has been some progress on a full file system API.

A specification has been in progress for many, many years. It's gone through a lot of different iterations, but it's recently started to stabilize. And it's landed in browsers like Firefox and the Chromium browsers. Unfortunately, it's not in WebKit Safari yet. So, you know, we may be waiting a while for it. Progressive web apps, PWAs, were the primary way that the web tried to expand its own capabilities. Like, for example, the file system API to have more parity with fully native apps. PWAs are literally just normal web apps that, along with being built on top of a service worker, can actually be installed to a device and act mostly like a real app. It's kind of just like a half step forward from a web app is when it becomes this installable experience. So speaking of PWAs, progressive web apps, what about service workers that are the foundation of these applications? Don't they give us more control over caching and the reloading behavior?

Well, yes, they do. That's one of their main advantages in helping the web application control this in a much more fine-grained way. Of course, we're still limited by local storage or IndexedDB limitations. Unfortunately, web app authors seem to be mostly neglecting these service workers because really we could be taking advantage of these for every single website, not just your traditional web applications. In fact, there are other APIs that we ought to be taking advantage of, like, for example, periodic background sync, which unfortunately is only in Chrome. But this is a critical API for allowing web apps to update themselves in the background so that when a user reloads an app, it doesn't need to re-download the latest updates. It already has those ready to go, and it instant starts. The service worker really reorients this whole front-end stack and it kind of puts the server directly in the client. I think even the most non-technical of users understood back then how ephemeral and unreliable web experiences were. You would open up a website, start reading or clicking around things, and then you'd get on a bus or board a train or a plane and look back down at your phone and the content and the experience that you had before was now gone. It was just dead.

You couldn't even scroll through the content that you had already loaded because the browser had discarded that information and backgrounded the tab and forced a reload when you switched back. I think users really deeply hated this. They never understood why real apps kept working, but the web could just stop working. Maybe more than any other sin of the web, this was the thing that kept the web as a second-class citizen in users' minds. It's so much more beautiful and graceful of an experience now, isn't it? The web doesn't go away now when our internet connections falter.

Most of the web applications we see that are popular and in widespread use these days, they've all embraced that offline-first and local-first mindset. They're all more or less preserving our data locally on our devices so that we always have access to our own data regardless of our internet connection. This was a huge difference. Turns out users really do care about having our data immediately at hand. You know, of the top 50 apps that are downloaded on the major mobile platforms, now almost half of them are local-first web apps.

That's huge. Before 2023, there had just been a handful of experiments into making local-first applications that could scale up to huge user bases. These were led by some forward-thinking companies like Ink and Switch. But today, there are hundreds of thousands of businesses and content creators who are delivering local-first installed web experiences. The latest market research suggests that these experiences are now reaching more than 500 million users every day. Let that sink in. That's a huge chunk of the world that has embraced what the web could be.

I'm super proud to have been a really tiny part of this big movement that has reshaped the whole web. Let's revisit what I said about my employer, Socket Supply, back then and how they would champion this effort. Earlier this year, I joined Socket Supply as a principal software engineer and part of the senior technical management, and I've never been more excited to start and work at a company. I want to talk to you a little bit about how Socket Supply is going to be a vital part of remaking the web in this vision of local-first. Socket Supply builds a free open-source hybrid framework that targets all the major platforms.

We target desktop, Windows, Linux, and macOS, as well as mobile, iOS, Android, and even Chrome OS. Our application runtime is pretty tiny. It's only 1.5 megabytes on desktop and only about 8 to 10 megabytes on mobile. That compares with, for example, Electron, which does something similar, but it's about 150 megabytes. You can see the difference. Now, our runtime provides three very specific capabilities to your native web application, your PWA even. We provide full file system access, full networking access, and full Bluetooth access.

Unlike the web API versions of those, these are full and unrestricted access with full security protocols in place. And so you actually have the same capabilities as if you built a native app. We think businesses are going to be really excited by this idea that they can target, with web technology and web technology experience teams, full applications with full fidelity capabilities. So it's kind of like taking the P from progressive web app and just changing it a half step and making it a packaged web app. Now, we're not just an option to something like Electron or Towery or React Native. Yeah, those are definitely in the similar boat. But what we provide is also this full peer-to-peer protocol, meaning that your applications can speak to each other encrypted without any server as a middleman. And that's something that puts Socket Supply in a class of its own.

We think this is going to really appeal to businesses who are wanting to cut costs. You see, businesses spend a lot of money on the cloud today. They often get started with free or very cheap services in the cloud, but then that ramps up. And by the time they've scaled up, they're locked into these vendor proprietary protocols, and there's no way for them to get away from the cloud. We think this is wasteful. It's like ransom level, holding you hostage, being stuck to these proprietary technologies. And what our peer-to-peer protocol namely allows you to do is build apps that just talk to each other. They don't need hardly any server middleman or any servers whatsoever. So you can drastically reduce or even completely eliminate the cloud and still have all the same capabilities in your apps. So we think businesses are going to really get excited about the cost-cutting savings, the ability to target.

We said that the peer-to-peer protocol is encrypted, so you can trust this is industry-standard kind of technologies. You can trust that your data is safe as it transfers from app to app. So you're really just taking full advantage of the collective power of all of your users' devices, thousands, millions, billions of devices using their storage and compute capabilities to distribute rather than trying to have all of that stuck in the cloud.

You know, by the way, that the cloud actually doesn't scale that well. I know that's one of the big selling points, but every time you get an influx of users, you have to scale out with more servers. The cool part about peer-to-peer networks is that they scale invertedly in that they perform better the more people join rather than worse and having to scale out. So we think this is a huge opportunity for businesses. So when you go local first, and especially when you go peer-to-peer, it means that there's just drastically less data to send up to the cloud and then bring it back.

That's going to drive your costs way, way down. The less data that you send to the cloud, the less you have to pay. And again, coming soon, those peer-to-peer apps without any cloud whatsoever, you literally could potentially shut off your entire cloud costs. We think this is better and exciting for businesses. It's certainly going to be better for users. And maybe the only people it's not better for is the cloud.

2023 was when Socket Supply emerged to embrace the promises of that local first movement. The idea that apps should be built by default, storing user data locally on the device rather than defaulting to storing data out in the cloud. Along with many other great projects in the local first space, Socket bolstered these efforts to bring local first capabilities to the masses and to web applications to break free from the ransom tyranny of the cloud. It's without servers, it means that we can go peer-to-peer.

Now, I want to make a clear distinction between local first, which is about putting data on your device first and possibly also elsewhere, and then augmenting that with peer-to-peer. That's where Socket really takes the next step forward. Because we're saying you don't even need the server at all. You store it first on someone's device, and then you send it to other users' devices when those users need it. And vice versa, they send data to you when you need it. There's no reason for the server to be the middleman.

In 2023, Socket launched this stable peer-to-peer protocol that handles the incredibly hard problems of NAT traversal between peers, and we don't even need any centralized stun or turn servers to do that signaling. It's a protocol where if two peers are online at the same time and they've discovered each other, they can talk directly to each other. Nobody has to pay for a server to transmit that data between them.

But this protocol is unlike something like WebRTC that you've heard of because it also works asynchronously and asymmetrically, meaning that two peers can communicate even if they're never online at the same time. This works because Socket's peer-to-peer protocol is a relay-based protocol, meaning that your data, while encrypted, is by default relayed through other peers, through other devices, until it reaches its destination. Through a variety of techniques, like conflict-free replicated data types and apps communicating peer-to-peer, they can negotiate and collaborate with each other at an arbitrarily large scale. None of that costs anything extra. You add 1,000, 1,000,000, 10,000,000 more users, and none of it costs anything extra to your business. And Socket Supply launched all of that way back in early 2023. You can imagine it didn't take long before businesses got excited and they started using Socket to build the same or even better app experiences for their users, keeping all the necessary data and computation out on the peer-to-peer network.

To date, tens of thousands of Socket-powered apps have launched since those early days back in 2023. Most of these companies significantly reduced their cloud reliance. Some of them closed their cloud accounts entirely. Others left only the heaviest compute and data activities out in the cloud, meaning their cloud bills were slashed by 75% or more. They report profits are skyrocketing, along with their buildings, it seems. And users of these apps have been happier, too. Apps start instantly since they're already installed on devices. Data is local first in these apps, so regardless of the internet, users can access their own data. Users easily keep all of their devices synchronized, either via the P2P internet or even more proximately locally through Bluetooth. And when communicating or collaborating with others, data communication is usually almost instantaneous, since there's no costly round trips out to the cloud to worry about. There's a lot of amazing things going on in local first now. From its humble beginnings a bit before 2023 to just four short years later, it's really taken over the web.

Arguably, it's now the default of the web to build local first rather than the old way of building cloud first. I don't think it will be much longer before we grow from reaching just 500 million users with local first experiences to billions of users. The cloud's days really are numbered. Local first and peer-to-peer are where the future of the web is going to be built and experienced. There's plenty to still keep fixing, though, including the fight to keep our data private and the fight to keep centralized authorities from trying to wedge themselves back in between us and our data.

Back in 2023, the problems were many, and some solutions were only just emerging. But the hope for what the web would become was great. The bets that we started making back then in local first, they really have paid off. In the now, a bit more than 30 years since the web was first commercialized and mainstreamed back in the mid-90s, it really feels like we're finally seeing the web realize its fullest potential. So as I wrap this up, most everyone has heard or read at least these famous opening lines from Charles Dickens' timeless classic, A Tale of Two Cities: 'It was the best of times, it was the worst of times. It was the age of wisdom, it was the age of foolishness. It was the epoch of belief, it was the epoch of incredulity. It was the season of light, it was the season of darkness.'

'It was the spring of hope, it was the winter of despair. We had everything before us, we had nothing before. In short, the period was so far like the present period that some of its noisiest authorities insisted on it being received for good or for evil in the superlative decree of comparison only.' Dickens wrote those words in 1859, a time of huge political turmoil in the world. But he wrote it about historical events that were set 70 plus years earlier than that, in another time of political and social upheaval. Most literary critics agree that the point that he was making is that back then, the 1700s, just as the now, the 1800s, everyone likes to make these bold assertions about how they're in the worst of times that there have ever been. But more importantly, in those same times, there are those with the vision and the hope for a brighter tomorrow.

The whole story of the web has been this same narrative. We've built these amazing things before and then we've become frustrated with the downsides of what we built. We became disillusioned with it all. We threw it all out the window and then some began to lay plans to rethink and work towards something better. So just like Dickens, we can choose to accept the way the current web is or we can choose to use it as a basis for what we hope for next. There are two webs, the web that we see now with all its good and bad and the web that we will have in the future. Back in 2023, I asked those of you in attendance to envision that future. What kind of web did we want to have when we got here to 2027? Should we, four years later, still be arguing about signals versus hooks, about SSR versus SSC? Are we going to keep arguing about the ergonomics of framework code or where our CSS sits? Or are we going to rethink the deeper assumptions about the structure of how the web connects and communicates? That was a much more important topic to dig into, wasn't it?

I'm so glad that we started to have the more profound conversations back then. Then, as now, whatever we choose to argue about and work on, we cannot merely complain about it being the worst of times. We also have the responsibility to start planning and building for that coming web's best of times. It truly is both the worst of times and the best of times for the web right now. What an exciting time to be part of the web's current and its future.

I thank you so much for listening to my thoughts. Thank you very much, JSFW Days 2023. I mean, 2027.