Building Bridges to a Post-SPA Future

I wanted to say hello, everyone. I know we were just post-break, and I do want to be inclusive, so I realize this probably is leaving a few folks out. It is a bit of a surprise to me to be here today, because I spoke at JS Nation last year, and I did the thing you're never supposed to do. Which is what I said out loud, which is I wrote on my blog things I actually meant. And so this blog post is the sort of thing that I think requires extraordinary patience from the perspective of the organizers to then read it, and then not throw me into the sea, but instead invite me to speak at the React conference that I wrote about instead. So thank you again for your forbearance, and hopefully you all will follow me through the same journey today.

But what I wrote about in this post specifically was kind of who it is that we think we're building things for. What is it that we want to do? Who do we want to have been when our future selves look back? And I used the frame of Louis Brandeis, the famous antitrust and jurist advocate in the United States from the previous century, regarding his definition of what it means to be professional, which is someone whose work is not simply mechanical but is slightly intellectual, and whose work takes on the cast of serving others, and whose primary in-domain sort of acknowledgement of competency is not about how much money you make. It's the recognition of your peers in some deeper way. It's a service to society. Do we want to be, by that definition, professional? And if so, how is it going?

But all these big collaborations happen because we want to improve something somewhat. We first have to see it for what it is, see its deficiencies and failures, and then work to address them. That is the urgent call, I think, of a technologist who is working in the public interest at every moment. OK. So what I'm going to do is a bit of the kind of normal thing that you get told to do when you're putting together a slide deck, which is to tell people what you're going to tell them and then tell them the thing and then tell them what you told them. But I want to do this very intentionally because what I'm going to try to attempt here is to convince you that I'm not your enemy. Even though I just put those things on the stage, which is a bit surprising, right? So to do that, I'm going to talk about who we are, and then I'm going to talk about who our users are, because I think that when we conceptualize ourselves as being people who are building in service of something greater than our own personal interest, and specifically the money that we make for doing a service, then we can conceptualize a different way of looking at our work, which is in the lens of what it is we aspire to. And then hopefully we can see something about the choices that we're making on a daily basis somewhat differently. And I hope that you will feel in the way that I have felt accepted here, accepted by those of us who see a different path forward. OK, let's get to it. First, I want to tell you that it's going to also probably come as a surprise that if you were just judging by hours spent on a daily, or weekly, or monthly, or at this point decade-long basis, I probably count as part of the React community, which is to say all of my day is spent these days consulting on React applications.

That is the urgent call, I think, of a technologist who is working in the public interest at every moment.

OK. So what I'm going to do is a bit of the kind of normal thing that you get told to do when you're putting together a slide deck, which is to tell people what you're going to tell them and then tell them the thing and then tell them what you told them. But I want to do this very intentionally because what I'm going to try to attempt here is to convince you that I'm not your enemy. Even though I just put those things on the stage, which is a bit surprising, right? So to do that, I'm going to talk about who we are, and then I'm going to talk about who our users are, because I think that when we conceptualize ourselves as being people who are building in service of something greater than our own personal interest, and specifically the money that we make for doing a service, then we can conceptualize a different way of looking at our work, which is in the lens of what it is we aspire to. And then hopefully we can see something about the choices that we're making on a daily basis somewhat differently. And I hope that you will feel in the way that I have felt accepted here, accepted by those of us who see a different path forward.

First, I want to tell you that it's going to also probably come as a surprise that if you were just judging by hours spent on a daily, or weekly, or monthly, or at this point decade-long basis, I probably count as part of the React community, which is to say all of my day is spent these days consulting on React applications. And that has been true for the better part of a decade. Previously there were a bunch of Angular apps that needed help, and we help them too. But today, almost the entire industry that sort of shows up needing a bit of repair, from the perspective of performance analysis and trying to do a better job for users, almost all tend to be React applications. So this is kind of the leading edge and has been sort of, I think, propagated into the middle tier of what major web applications do today. They carry a copy of React around with them. By hook or by crook.

By hook or by crook. And so one of the applications I consulted on over the past year is represented by this chart. The names are not provided to protect the guilty and the innocent, but what you're seeing here is a distributional change. This is Crux scores, overall Crux Chrome User Experience report scores, good versus bad, for desktop and mobile. On the left-hand side of that chart is a system that was very high-profile, adding about 100 kilobytes of compressed JavaScript monotonically to its build every month. This shift represents a move away from mobile users towards a larger density of users on desktops, illustrating the impact of bouncing users.

One of the things that I think we should, as a community, understand is the total addressable market of the web, encompassing various devices from toasters to televisions. Despite the broad potential audience, the failure of a product through shrinkage is evident in cases where slow performance leads to user bounce-offs. This prompts reflection on encountering frustrating services daily and the cultural impact of technology choices like React. The speaker emphasizes that web experiences are complex and involve sending code to devices and systems beyond our direct control and understanding.

The speaker delves into the significance of the choice to use React and its broader cultural implications on web development. They highlight the interconnected nature of web experiences, emphasizing the challenges of transmitting code across diverse devices and systems with varying latencies and configurations. The complexity extends to factors like antivirus software and other unknown variables affecting user experiences. This discussion underscores the intricate web development landscape beyond individual coding choices and emphasizes the broader impact of technology decisions on user interactions.

What this looks like is a failure for the product through shrinkage. In theory, the total addressable market of the service, this web-based service, was most users on the planet, and they definitely had plans to expand into as many hands and as many phones and as many computers as possible, but there was a hysteresis effect. The system was so slow that users who they would like to reach were simply bouncing off of it. So if you're honest with yourself, think about the services that you encounter on a daily basis. How often are you frustrated by them in that same way?

OK. So what this gets to is not a question about React. React is just one tiny, tiny, tiny filament in the thread that gets spun, that gets woven into the greater fabric of the applications that we build. React is but one choice, but it is a faded choice, right? It is a choice about the intent that we are going to take at every moment when we choose it beyond that. And so what I want to talk about today and what I hope you will understand me to be saying is not about your choice to write your angle brackets with capital letters and no closing tags, right? That's not what I'm talking about, right?

What I'm talking about is the cultural effect of choosing React. Because web experiences are aggregates. We are programming the devil's computer. I talk about this all the time. I'm sure you've heard it before. I'm a little boring about this. But we're sending code through a pipe that we don't own, can't provision, don't understand, with latencies that we have no ability, generally speaking, to characterize before we start sending things across the wire to devices that we didn't provision, running operating systems that we don't control, running browsers that we didn't provision or control, which may have extensions and all kinds of other things that we are ignorant of, right?

Antivirus, whatever else is happening on the machine that is inclusive in the user's experience, but it may not be what you're developing too. So because these are wicked complex systems, and we only have a little bit of time here to get through them, what I'd like to show you here is a bit of evidence about who our users are and what they're experiencing. So Core Vitals is a great lens for understanding the ecosystem level, the population level effects of our choices. And what we're seeing is that in recent years, Core Vitals pass rates have started to plateau. It's a little bit worse than that, but we'll get to it. And what we're seeing is on the top one million mobile websites, this is a new visualization that the HP archive has put out recently. We're seeing that the best performing sites by framework are only getting into the 70% pass rates, and the worst performing sites, not the absolute worst, but certainly from the popular frameworks today, are sitting well below 50% on mobile, and that is dominated by React and React friends.

This is what it looks like to fail at scale. If we zoom in to the top 100,000 websites, which is to say the sites that are probably having some sort of commercial intent about their content, right? They've built an audience, they're trying to reach users, they're serving ads, there's all sorts of confounding factors along with them. What we saw over the past couple of years was this massive cliff when the interaction and XPaint metric hit in Core Vitals. And this means is that the pool drained, right? INP measures, you know, FID was a sort of imprecise metric and it was very easily gamable and React did a lot to game it. But INP is much harder to game, because it's about all the interactions that you take in the session just after it loads. And so what we saw with a more sensitive and predictive instrument was that users were having a worse time, or they were having a bad time all the time, but now we can see it. And this hit React-based sites particularly hard.

I would say that whatever progress was being made in the old, easily gamed metric set, the truth outed eventually. So I want us to understand React not as React, but React the epiphenomenon, the set of things that come along as part of the package when you choose cultural React, when you decide to walk into the ring and say, I'm here, we're doing React, what are we doing next? And that used to be create React app and maybe it's, I don't know what the data management system of the week is these days. Anyone still using Apollo? Okay. There's a whole series of things that keep circling in and out of that ring, but you're there, and you're sort of in conversation with all of your peers who are also in that ring. But you are also subject in the applications that you build to a whole series of external factors including, for instance, networks.

But you are also subject in the applications that you build to a whole series of external factors including, for instance, networks. The bottom line is the one that I would look at here, which is to say that this is the 25th percentile in this distribution, think of it as being P75, flip it around in your estimation, the 25 per cent of network connections are worse than this, and Cloudflare's pretty good analytics system here reckons that that's getting you between seven and nine megabits per second down. Seven to nine megabits per second down is worse than most satellite internet connections. This doesn't count RTT, I think RTT is in P75, sitting about 100 milliseconds. I don't know if you've done this lately, but you can get most of the way around the world with ping with a couple of packets in 100 milliseconds. So into that network condition, what are we doing? What has our community chosen to do? Well, we're sending a lot of stuff down the wire.

Ten years ago, that was 1.2 megabytes total, compressed, potentially, if you're compressing, but total transfer for most websites at the 50th percentile to mobile, and today, it's 2.7 megabytes. So we've more than doubled the size of the average website payload at the 50th percentile, and JavaScript is doing numbers too. So today, sorry, in 2016, that would have been 310 kilobytes of that 1.2 megabyte payload would have been JavaScript, which uncompressed is a whole honking load of JavaScript. I just want to be very clear. You can do a ton of stuff in 300K of JavaScript, and we were sending that at the 50th percentile. Right? At P75. And today, we're sending three-quarters of a megabyte of JavaScript to mobile users, and half of users get at least that or more.

What does it look like at the tail? Well, it used to be 850K, but we have really lost all control. It's now more than 2.1 megabytes. Unzipped, we would expect 2.1 megabytes. If it's gzip, it would be 5 to 7 megabytes. It's more than that. What are you doing with 7 megabytes of JavaScript? Do we know? Do we understand what we're doing with 7 megabytes of JavaScript? Do we have an understanding of what's actually in there? I think we don't. And I think to understand what this means for us, we have to understand how we got here. I think everyone in this room is here because we are all dedicated to the exact same thing. We want better user experiences. Right? Yes? Yes? Okay. Good. I'm not speaking to the wrong audience. Great. That's good. And to get that, we decided that we were going to make a trade. We were going to buy into a lot of complexity, because browsers weren't very good, and the trend line was in 2008, 9, 10, 11, that CPUs were getting much faster and networks were getting much more predictable and faster, and that we were going to have more headroom on the JavaScript side, even though the browser engines weren't necessarily keeping up. So we put JavaScript in the critical path, because it was the thing that could give us what we couldn't get any other way, which was to say, better browsers.

So that turned into a set of self-sustaining investment loops. The thing that I wind up being crosswise with folks about is that maybe we didn't check to see if that still made sense. Right? Does that still pan out? Because as engineers, our responsibility is not to the paycheck, it is to the evidence. That's just what it means to do a good job as an engineer. You could be something else. You could be a marketer, you could be a salesperson, in which case the dollar is the denominator. But for us, that's not what it means to do a good job. A good job is something about the user experience. We can see that we have huge amounts of investment going into React, and that has become quite self-sustaining. And at the limit, that has started to push other folks who understood simpler ways of doing things out of the ecosystem.

I've witnessed this personally many times. We don't have enough time today to get into that, but it's generally a catastrophe for the organization. Because what happens is that you lose the ability to think laterally about problems and solve them in simpler ways. Okay. So, I've worked on a browser for something like... Eight? Gosh, it's a long time. More than 15 years. Let's say more than 15 years, so I don't feel too old. But before that, I built JavaScript frameworks, and I came to work on a browser because I wanted the web platform to improve. But what I want you to understand from the browser engineer's perspective is that when you send something down the wire and do anything in JavaScript, you are saying I'm taking the reins, dear browser, but out. It is literally the most expensive way to do anything in a browser. Because browsers are machines that are highly optimized because of the web's history for turning declarative forms of HTML and CSS into pixels. That's what we do all day every day. And if you plug something into the side in JavaScript, you're just plugging it into that same system. You're just driving that system without the benefit of an internal understanding of the state of the system, or how it works, or what it can do for you.

Let's understand that in terms of our own users and their sessions. If we think about a session as being all the things that you click on, right? That can be multi-page, that can be single-page. This is the, I think, the most useful equation for understanding this sort of at a really, really, really rough conceptual level. N is the number of navigations in the session, or clicks, taps, interactions. The first thing is baked in, that first interaction's latency.

We just have to have that. And then we have all of the follow-on ones, and those can be full-page navigations, or they could be in-app navigations, they could be single-page, right? But they are all their own latency, and they go from when I do the action to when the system becomes quiescent again. Going through all the phases of starting to do work, updating the user about the work, updating them as it goes, retiring the work, updating the UI, and then becoming quiescent again. That's the flow that happens all the time.

An open question for us, as a community, has been, well, how often is N large? Because the whole idea of an SPA is that you're going to have a long session, and you could amortize those costs, the upfront costs and the initial latency, based on having a lot of clicks later. So do we? This data sort of hit me like a ton of bricks last year, from the RUM archive that Akamai publishes, showing that users on mobile and desktop, with specifically instrumented pages for in-app navigations, are only seeing two navigations of any type, total. Can this possibly be true? This is a crisis for us, the idea of building a web page based on SPA technology for long sessions when sessions might only be two clicks deep.

This implies that we need to look at our data and logs. We should challenge ourselves to think differently, to embrace discomfort while examining problems from new angles together. It's not about invalidating oneself or being viewed negatively but about seeking a better understanding. Looking at smartphone volume by operating system over the past decade, it's revealed that Apple never sold over 20% of all smartphones globally in a year. The market segmentation by price and income levels influences the distribution heavily, showcasing the need for a fresh perspective on web design and user behavior.

If I understand this world and its implications, that it somehow invalidates who I am, or that I'm a bad person, right? That's not true. There are people who have been warned about this and then sold you maybe a pile of goods that weren't going to work and then didn't work, but that's a different question. Everyone here, that's not you. You're just trying to do a really good job for the user, right?

Okay, so come with us. Let's look at things in a different way. This is the smartphone volume by operating system over the last ten years. At no point in the last decade has Apple sold more than 20% of all smartphones in the world. Sometimes it bounces up to 25% per quarter if there's a new device released, but it's never more than 20% per year. And you may be thinking to yourself, okay, fine, fine, fine. Goods are everywhere. Maybe, maybe.

But everyone has a desktop, right? Well, I'm here to tell you that 4.6 mobile browser running smartphones are sold for every desktop computer that's sold every year. That's $1.2 billion to something like $270 million. So hands up if you carry an iPhone. Oh, holy cow. Well, this makes sense. World historically speaking, we're all quite wealthy, and the probability of you joining that 20% goes to one as your income goes up, right?

World historically speaking, we're all quite wealthy, and the probability of you joining that 20% goes to one as your income goes up, right? Because the market is heavily segmented by price. What this means is unfortunate, as our experience is delaminating from the average user. Those two bottom lines account for more than 60% of sales yearly globally, not reflecting the premium segment. Apple invests significantly in A series chips, leading to unmatched performance, but this results in a disparity in user experience, especially for Android users.

The global average selling price for phones hovers around $350 to $375 annually, emphasizing the price discrepancy between top-end iOS and Android devices. Android devices suffer from lack of updates, resulting in slow and outdated experiences. SPAs cater predominantly to affluent users, indicating a bias towards richer individuals. Our perception is skewed by our circumstances, influencing how we perceive the tech landscape and user experiences.

But what that means for us as an ecosystem, rather than us as end users, is that our users, if they're on Android, are getting a slow experience. And this is because the prices have also delaminated. The top-end Android device is now the fastest part you can get is somewhat cheaper than the top-end iOS device. And the global average selling price for a phone is hovering somewhere between $350 and $375 per year, not inflation adjusted.

The low end is actually falling. The same phone keeps getting produced with different badges on it every year. But the price keeps going down. It doesn't get any faster, but it does get cheaper. That's what the volume is, because the volume is below that global line. It's in the Android area. The average selling price of an iPhone today broke $1,000 a couple of years ago. That is a luxury device for the 20%, right?

Android is a disaster. This is Android versions. I grabbed this out of the Android Studio. This is not great. If you're a native developer, good luck. What this is downstream of is lots of users who don't get updates. Those devices are old. They're slow. And so when we talk about SPAs enabling rich experiences, we mean experiences for rich people mostly. So it's helpful for us to then acknowledge that we don't see things as they are. Our experience of who we are filters our experience. It causes us to see things differently. It may feel real, but it isn't necessarily true.

It may feel real, but it isn't necessarily true. So I looked into the mobile operating system share in the Netherlands to bring it home and be local about this. Something like 50 to 60 per cent of users are on Android, right? Even here. Even one of the wealthiest nations on earth. And what that means for the device sales is that only 25 to 26 per cent of users are buying high-end devices if you segment it by price. The other 75 per cent are in the mid and lower end tiers.

50 per cent are in the mid-tier. And most devices last between two and four years. So they're older and they're slower than probably what's in your pocket. And compared to the rest of the world, the networks here are significantly faster. This is a good thing. But that's not a get out of jail free card. So how do we get out of this? What do we do next? We're not all going to have the same luck that Alistair Davidson had where he was able to re-litigate a React application and make it HTML-firsty and use a small web component and dramatically expand the total accessible market of the application because it was no longer bouncing users.

But there are paths out. If you want sort of a React-flavored way to do this sort of thing, there are tools like Astra that can give you an MPA entry road for your React skills, and they work quite well. We saw that in the evidence earlier. But what I would encourage you to do, aside from plugging your ears, is to check your browser stats. We did this at Microsoft, and it's been tremendous. You'll see new blog posts every time there's a new browser released, but what you won't see is a new blog post when it falls out of your minimum usage data. You won't see that unless you go look. So go look. Just go look. See what you can reset.

And once you've reset your expectations based on your user base, you can maybe think about which technologies you can adopt now that maybe weren't available to you just a few years ago. Things are moving really fast in browser land. And you know what? There's no IE and no Edge in your user base. I promise. Unless it's like a regulated medical profession that's been installed in the last, you know, 15 years ago and no one's touching it, I promise you that's not your problem because we won't sell you a copy of IE. We won't sell you a copy of Legacy Edge. So that's not your problem. Microsoft won't support it. So just point at us.

And I want to tell you not just about sort of the things that you could, in theory, do. I want to tell you about what we did on the Edge team. So we had a big React SPA predicated stack, and it was being used in a bunch of surfaces inside the browser. And browsers, by the way, are mostly made up of HTML, JavaScript, and CSS these days. I don't just mean your stuff. I mean our UIs. The settings pages, the drop downs, all that kind of stuff, it's all made out of browser stuff.

And we have been on a multiyear journey now to make that HTML-first too. And to move that to something that's based on a multi-page application architecture in many of the cases where we have big and complex interfaces. And across the board we saw that because something like 30% of our users in Edge are on what we think of as our low-end cohort, which is to say less than four cores and less than eight gigabytes of memory, or having a spinning disk, those users are getting a significantly better experience to the tune of something like 40% faster every time they interact with one of those services as a result of this work.

The other thing I would encourage you to do is to go do bake-offs for yourself. The world has changed, right? We don't have to live in our assumptions as they were previously. And it can feel a little bit unwiring to know that that's true, but not necessarily have your hands around it, right? To be across the brief requires you to update your idea of what's possible in the new world.

And the fastest way to do this is to go get your team together and try rewriting stuff in a couple of different styles. It's incredibly cathartic. It helps you not feel bad about what you could do, but feel hopeful about the opportunity that's still in front of you. The thing that we have had great experience with on the Edge team, what sort of predates the new MCP servers that Google just released, which we've been collaborating on, is to use agents to translate a lot of that old React code into HTML-first stuff with tight performance guardrails and web components where we needed interactivity.

And that's been tremendous, including a new framework for doing SSR for this stuff called the Web UI framework, creatively named, I know. But it's like a Rust-based server that gives you declarative Shadow DOM streaming down. And for us inside of the browser, we sort of treat the browser process as a server. And so we get to send ourselves HTML-first content. This is dramatically improving, again, on top of that 40% improvement that we already had. Because when you go HTML-first, again, browsers are machines that are tightly tuned from turning markup into pixels.

And if you hold that pipeline right, even in the face of very slow machines, we can do an excellent job for our users today. And what I want to let you know is that you get to the end of this, you're not alone. There's a community out here. And so when you see something like this, understand that it's not anti-JavaScript more than it is a JavaScript club. We all just want to make something together that's great for users. And of course, I would be remiss if I didn't point out that this slide deck is a multi-page application. So, if you liked what you saw here today, you can have some for yourself. It costs me all of 4K of JavaScript uncompressed and something like 500 lines of CSS. That's what the browser can do today. Thanks.

Could the cause of user experiences getting worse be that it's not that important to... It's not the most important thing for being profitable? It's admirable to build great user experiences, but ultimately, profit is what enables us to be paid. Yeah. So, if that's your perspective, then what you should take away from this is that every time we have made a significant web application significantly faster, we made a shit ton more money. Right? Like, go to WPOstats.com. This is a... Shopify just published a blog post... I apologize, I didn't include the slide that showed a clear correlation between making a faster experience and making a lot more money. When you make something faster, you lose fewer users. You don't bounce them, which means you don't have a hysteresis effect of people avoiding your service or your thing for a better alternative. So what that means is you make more money. So these things are not intention, they're directly aligned. If you think those things are not directly aligned, then I would like to talk to you and we should look at your data. Because again, using evidence to make decisions about technical matters is what engineers do. Absolutely.

So positioning is key for getting the buy-in. Alex, what is your opinion on micro front-end architecture? So there was a JS Nation talk yesterday. And do you view collections of them as MPAs? I don't want to get into the semantic conversation around what is or is not an MPA. What I will say is that the test is whether or not it works well for the user. So situate yourself in the shoes of your 75th or 90th percentile user. Build yourself a test bench. Get yourself a cheap phone. Get yourself a cheap device. Try it out on a throttle network connection and see if it feels good. That's the test. The proof of the pudding is in the eating. It is not in the contents that you lined up on the counter before you started baking.

Thank you. And somebody said that mobile devices to desktop devices ratios are high because the lifespan of a desktop is much longer than phones. Do you have an estimate about how many people today don't actually have a desktop? Have you been to India or Indonesia? It has been the case in most wealthy geographies that we have been at saturation for smartphones for something like 12 years, 15 years. That only hit in other parts of the world in 2017, 2018. But now we are into the replacement-dominated curve almost everywhere in the world. There are access-based hurdles to getting more users online in large parts of Africa, for instance. But in general, everyone has a phone and if you think you're making a service that no one is using on a phone, you're delusional. Someone is using your website on a phone and if you're doing a bad job for them, I promise you, you're doing a bad job for your business.

Some advice for starting a new highly interactive web project today. What is the top architectural anti-pattern to avoid in order to prevent building another slow SPA dinosaur? Frameworkism. The idea that the framework and the community that the framework gathers will teach you what is good and bad is fundamentally broken. Your value system about doing a good job for your user has nothing to do with your framework. It is literally incidental. Your framework is promising you something about the value system that you already hold, the thing that we share, the thing that we together all agreed on at the front of this talk that we want to do a great job for users. So keep that as your north star. Build tests that let you see whether or not that's true and avoid frameworkism.

So keep that as your north star. Build tests that let you see whether or not that's true and avoid frameworkism. The idea that the framework are the things that are only available inside of NPM or inside of the React ecosystem are the way that you're going to solve a problem. The cool CSS thing that someone showed you that you could use that doesn't include any JavaScript is somehow verboten because it's not React-ish. That is the smell of failure organizationally. The smell of success is saying, aha, we removed some code, right? Because I promise you, every line of code you send on the wire is led in. It is costing you more than it pays you unless you are very, very, very lucky.

Thank you. Can I give you one final one before we finish? Super quick answer. The question is, what is your prediction for the future now that contacts like LLMs.txt and markdown headers for AI agents makes it much smoother. Should we focus more on optimizing for agents? My take is quite spicy, which is to say that Google made the web so bad to use by allowing websites to get into a bad state of disrepair and having ads that are quite invasive that they made the low quality JPEG of the web feel good. So if you make a good website, people will still come. Try it. Awesome. Some optimism. Thank you very much, Alex. Thank you. Thank you. Thank you.