In this RedMonk conversation, Alex Russell, Partner Product Architect at Microsoft, discusses the state of mobile development, focusing on JavaScript performance, the state of Progressive Web Apps (PWAs), and the impact of major players like Apple (iOS) and Google (Android). They explore the importance of management in addressing web performance issues, the role of web standards in shaping the future, and the implications of AI on web development. Alex emphasizes the need for restraint in JavaScript usage and the importance of creating user-friendly web experiences, particularly on mobile devices.

Microsoft is a RedMonk client, but this episode is unsponsored.

Links

• LinkedIn: Alex Russell
• infrequently.org
• Bluesky: @infrequently.org
• Roderick Gadellaa, “An Abridged History of Safari Showstoppers,” Webventures, 22 September 2024.

Transcript

Kate Holterhoff (00:12)
Hello and welcome to this RedMonk conversation. My name is Kate Holterhoff, Senior Analyst at RedMonk. And with me today is Alex Russell, Partner Product Architect on the Edge team and Blink API owner. You’re also alumni of Google’s Chrome team and a member of the W3C Technical Architecture group. And you’ve also been a representative of TC39 so Alex, thanks so much for joining me on the MonkCast. wonderful. Okay, so excited to talk about the web today. Let’s begin with JavaScript.

Alex Russell (00:35)
Anytime. Glad to be here.

Kate Holterhoff (00:43)
So you have written a fair bit on JavaScript excess and performance budgets. And you’re advocating more restraint amongst developers specifically. And you’re one of the earliest folks to have been banging on that drum. So at least 2016, I saw your posting about it. So talk to me about where that situation is. the argument that a lot of these frameworks are pulling down more JavaScript that they need.

doesn’t seem to have been going anywhere, but have we moved the needle in terms of where that stands?

Alex Russell (01:15)
So I think it’s an important topic, but I think it’s important because I approached most of this from a strategic lens, which is to say, what does it take to make the web a success? Today,

PC sales are basically flat, right? They have been for most of a decade, pandemic notwithstanding, had a big spike, a lot of that was low price, a lot of that was Chromebooks, which sort of made, you know, making things that were reasonably fast on low end devices much more relevant even in the desktop world. But the most impactful…

shift in computing over the last 15 years has been the overwhelming explosion of mobile, right? Mobile started to happen and then it happened for real for rich people. And then after that, rich people stopped kind of paying attention and everybody else got a phone too. So today for the last 10 years, Apple has never sold more than I want to say 20 % of devices sort of if you average year over year. So 80 % of the market, 85 % of the market, something like that are androids.

And those devices are for wealthy people, which is to say a very small fraction of people who actually buy an Android device. They’ve been sort of like half the speed, dollar for dollar, of an iPhone. Apple devices are brilliantly engineered from a CPU perspective.

If you’re buying a Samsung, if you’re buying a Google device, if you’re buying a high-end Xiaomi device, you’re getting basically half as much CPU per dollar. So that’s a performance problem if you would like to have applications compete, especially things that are mostly interpreted like web apps. And I care about that. I care about that because that’s where most of computing is now. So if the web is going to succeed, it has to succeed on the dominant form factor, which is to say mobile today. And that’s where…

we have had some room to run. So there have been sort of intersecting trends. The one trend, the mega trend has been that,

Everyone who had a flip phone on the subcontinent and in Indonesia and everywhere else in the world has gotten a smartphone in the last decade. And that smartphone has been a cheap Android. It’s, you know, it’s been one of these. These are devices that are $100, $200 new unlocked. They are not, you know, they’re not packing the latest and the greatest. And the CPU situation, if you just look at the silicon that’s been in them for the last decade has been extremely stagnant.

That’s just starting to change in the last couple of years. You might remember how Intel got itself into trouble with that kind of plateau at 14 nanometers, where, you know, year after year after year after year, there was like a refresh and then the refresh, refresh and the refresh of the refresh. The same thing was happening at the low end of mobile, except it was at 22 nanometers. And it was not paired with process that the process stoppage, the plateau was not paired with architectural improvement.

when you would get like the, you know, what was it like, Sapphire Rapids or whatever, refresh and time, it would be paired with maybe a larger cache or better branch prediction or something that was improved in the architecture, which would eke out more performance for that same dollar review. That did not happen.

Instead, happened was the same smartphone every year. I started talking about this one in 2016. This is the Moto G4. This has eight cores and I want to say four or eight gigabytes of memory. So was pretty well endowed at the time. Those cores were all A53s.

the first generation 64-bit architecture that made it big inside of the Android ecosystem. So 2015, 2016, the 64-bit architecture shift happens. And at that same moment, everyone starts making one and they put out their production lines and they all build these chips for sort of mid-tier, right? So this is like a four or $500 phone that was brand new and then like down to $300 when I sort of picked it up.

Versions of effectively exactly this device have been being recreated at ever lower price points every year since. So what does that do? It means that the marginal dollar does buy you more computer every year, but not for the same person. It means that the person who was previously excluded from buying a smartphone can suddenly buy a smartphone. there’s this been a Cambrian explosion of

device manufacturers and models, but they’ve all basically been this phone. And that is, like you can still buy a brand new phone with an A53 core in it today. And that core is a disaster. It’s from a computing, like it’s just a technological, like, what can I eke out of this thing perspective? Assuming that you’re stuck on that 22, 28 to 22 nanometer process node, this thing basically has no cache.

No cache. So you’re spending a lot of your time if you’re not relatively efficient in terms of retiring instructions, just waiting on memory. The memory is extremely slow. The bandwidth to disk is bad. It’s flash memory, right? It’s like flash storage, but it’s slow. It’s like EMMC slow in a lot of these devices. And that has been true as it sort of progressed down the price curve. So we got more compute every year. It’s just that the Wii exploded.

So we got more of the same compute every year rather than upgrading the compute that we had. So what’s happening now is that we’re finally bottoming out. In the last year or two, we’ve started to bottom out.

in most of the densest geographies where almost everyone who previously had a flip phone now has a smartphone. And that’s pushing the value of those devices up, both in terms of like to the person. Like your first smartphone is kind of a lark. It’s a very expensive, maybe nice to have your next one. You’re like, wait a minute, this is most of my life. I need I need this to be good. So you might save up a little bit more and get it. But also the process node has started to finally improve, right? Like the newest cheap devices like these. This is like a Samsung A

23 I think. This will be on an 11 nanometer node, right? Like the phone you probably just picked up is probably on a three or four. So it’s like still two or three generations behind, but it’s only two or three generations behind. So we’ve had sort of a precipitous improvement in the core technology there. I’m afraid to say that the ARM chips are still real bad. They’re just real, real bad, but we’re getting some in-process improvement. And at the very high end in the last year,

If you were to get a one of these very top-end Samsung or not Google, their devices are still not very good. Or Xiaomi devices, you’re getting a top-end MediaTek or Qualcomm part, and at the very high end, they finally started to put more cache into those parts, so they’re spending less time kind of just waiting around on main memory whenever they fall. they have gotten significantly faster. So we’re going to start to see that also trickle down the market in a few years when that sort of, that, you know, architecture improvement also hits the mid and low tier. So that’s the upside. But for at least a decade, we’ve basically

been frozen and the amount of JavaScript that we’re sending to these devices has been going up. Right? We have not been exercising any restraint. And so I sort of look back and think, okay, what does it mean for the web to succeed? I want the web to succeed. How did it succeed last time? Well, last time we had what I think it was like a reasonable amount of overhang, right? Moore’s law was in, you know, full flourish and we got

Intel giving us faster and faster and faster, more, more megahertz every year. And then was more gigahertz every year, through the late nineties and early two thousands. And that meant that there was kind of like extra CPU laying around. So we can start to throw that at interpreted languages and start to build more safely, but also move applications that previously were the domain of only compiled. Applications into the browser. And so we did that, we did that very aggressively and you know, that was the Ajax revolution and know, web 2.0 and all that stuff that was all fundamentally enabled by the physics underneath us.

enabling us to kind of have some some squish in the budget, some some headroom to play with. And that headroom turned into applications moving to abstracted, interoperable, open platforms away from the kind of hard scrabble life that you have to live in as a C++ engineer. So that’s the story. And we haven’t had that overhang on mobile. And so if we don’t, what do we what do we do to get there? Well, the good news is that browser engines have been, at least in the Android ecosystem, improving substantially over the

years. And that’s been paired with real progress in the amount of CPU that folks have had at the high end in the Apple ecosystem. But those are oil and water, right? The ecotone between the Android and iOS ecosystem is like, it’s at the $400, maybe $350 mark.

Below $350 for a device new unlocked, it’s all Androids. Above that, effectively, it’s all iOS, right? It’s like pure market segmentation. It’s a duopoly in the strongest possible sense. And what that has meant for web performance has been that if you don’t devise your website to work very well in that lower tier, it’s going to feel like junk for most people.

So the web is not going to succeed. And that’s where we’ve been. So that’s the long story of like kind of how I got to the place where sort of working on a browser team that was working on Android browsers, we sort of saw this, you know, front and center as we tried to make, make it possible for people to build PWAs. We saw them pulling in these huge piles of JavaScript that might have kind of worked on the desktop, kind of at the limit. But we’re just totally inappropriate and, and effectively unfunctional on the mobile devices that were most prevalent.

Kate Holterhoff (11:11)
I like that you have historically approached this in terms of, over-weighting developer experience at the expense of user experience, which it sounds like you’re kind of articulating here, right? The users of these devices are the ones who are suffering. And, you know, at RedMonk, we’re certainly very interested in how developers are interacting with dev tools. And so, we tend to think of developer experience as being an unmitigated good.

But when I hear folks like Miško Hevery talk about his framework Qwik, he said something similar where it’s that we have over-weighted developer experience, especially in the realm of mobile. And so am I right that that’s sort of how you’re approaching this, that developer experience is, there’s a way to approach this so that it doesn’t maybe sacrifice the UX?

Alex Russell (12:00)
One way think about this is that users get a vote, right? They don’t have to use your crappy website. They can go get a native app, right?

Like nobody wants to go to an app store and like spend like minutes downloading 90 megabytes of what is effectively a browser, but they’re going to do it if your website sucks. so as someone who’s invested in the web ecosystem, your choice of whether or not to make something that’s appropriate for your user base is, is I think of as kind of a vote for your own kind of future employment. But even if you don’t think of it that way, you can kind of view it as like, a market limited question, like how big is your total addressable market?

You can actually kind of chart out based on the device price curve, how much JavaScript is going to be the limiting factor in delivering a good experience for some fraction of the market as sold. So if you just sort of look back over the population of devices that were sold, the good news is that I put out these researchy kind of pieces every couple of years now. I guess that’s the cadence I’ve been doing it on.

Kind of looking at what are the price points? What are the volumes trying to understand the market from that kind of market analyst perspective to see like, okay, has something shifted in the kind of balance of device shipment volumes at various prices or the properties of the devices at the various price points? And the answer has been, we’ve been in a pretty stable situation, right? The median device has been about a 300 to $350 device for something. My camera’s never going to focus.

has been $300, $350 median for something like 10 years, right? And what that means is that like we got to saturation with rich people and they kept buying ever more expensive devices. And so as they did that and their devices got much more expensive to keep the median at $350, you kind of have to sell a lot more devices underneath you, right? And that’s been the trend. And that continues even through the pandemic and through…

inflation and all the rest, right? It’s just been a fantastically stable trend. so what that has meant has been that, know, Miško made a turn. Like he took that kind of desktop-centric thing with Angular and, you know, we’ve talked off and on over the years and I’ve seen him kind of make that same pivot that I made, you know, something of a delay, but like I can understand how you get there from here. I did it too, right? I thought, you know, it’s all fine. And then I tried running the websites that I was trying to build on the devices that we were shipping.

wasn’t fine. Everyone comes to it from their own perspective, so you kind of have to give people some grace. my goal with all of this has been to try to precipitate the conversation around what is it going to take for the web to really succeed on mobile. So I think Miško is on the same wavelength that I am now, and I’m happy to hear it. I think they’re doing great work over there.

Kate Holterhoff (14:51)
Yeah. Awesome. OK. And so one of the things that you are most well known for is co-naming, the PWAs, Progressive Web Apps. And that was in like a decade ago now.

Alex Russell (15:05)
It was a decade ago. I got email. Someone reminded me that it was a decade ago. Yeah.

Kate Holterhoff (15:10)
Wow. So pretty exciting. So we’re 10 years in. We’re kind of dancing around it, but what would you say is the state of PWAs? When I’ve written about them, people feel very firmly that native apps are the way to go. They’re more performant, whatever. You make very good arguments that that shouldn’t be the case and that these are really just small little browsers anyways. are things changing? Do you see PWAs as having

Alex Russell (15:24)
Mm-hmm.

Kate Holterhoff (15:39)
I don’t know, being in the Ascendant, are they going somewhere where folks are adopting it? Where do you stand on that?

Alex Russell (15:46)
So again, sort of putting a strategic lens on what would it take to make the web a success. I think we can both acknowledge that they are not the dominant mode, right? No one’s gonna say that PWAs are how people get their software today. And so I spent a lot of time thinking about what would it take to unlock the same kind of transition for mobile that we went through on desktop, where PWAs are actually quite successful, right? We see growth continuing year over year.

Kate Holterhoff (15:51)
Yeah.

Alex Russell (16:12)
largely on desktop, but also on mobile. You know, it’s been 30 to 50 % every year growth in installation and use. You know, back when I was at Google and now when I’m at Microsoft, the trend keeps going up. But again, remember that that’s inside of an ecosystem that has been exploding, right? Like the mobile ecosystem has continued to grow. On desktop, that’s a meaningful trend as a fraction of time spent. But it’s also part of the larger story of the web kind of eating most of computing on desktop, right? The web is

the dominant ecosystem on all desktop operating systems. Doesn’t matter what you would like it to be, it is. It’s the essential tool. If you didn’t have a browser, you couldn’t get things done on desktop computer today. And it doesn’t really matter which OS you’re talking about.

That’s been heartening to see, but it’s not the same thing as kind of matching the rate or the scale of what we’ve got on mobile today. So I think that’s maybe where the question’s coming from. Again, on desktop, you can go take your PWA to PWA builder, put it in the Microsoft Store. You can get it in the Play Store on your Chromebook. You can install it through Edge or Chrome or any number of other browsers on a Mac, and it works just great. And so we see lots of people doing that.

Being, again, being a relatively stagnant in terms of shipment volume ecosystem, I think that’s a form of success. But I think a lot of web developers have of reclined into that, right? Like maybe trying mobile for a bit and then thinking, well, it didn’t work. And so I’m going to go back to my priors. But coming back to the previous conversation around performance,

web developers were the only cohort that was told that they should bring effectively their same tools, like a static set of tools and technologies with them to mobile. A lot of the framework authors just sort of said, yeah, you can definitely use this on mobile. Should you? Absolutely not. didn’t write like the companies that they were working for would not ship that stuff to mobile because it didn’t work great. Like Facebook famously, you know, had to use Inferno instead of React for their mobile rewrite when it launched because React just wasn’t fast enough.

These are the kinds of things where when you look at what it takes to do the hard yards to really get there, the tools that we’ve had, again, present that of market limiting, that total addressable market contraction moment, because at a baseline, their cost out of the total budget of what you could afford to do a good job is just too high. You basically end up being pre-limited in your addressable market. Part of the reason I want people to make good…

good websites that are fast for most people is that like that’s part of the equation. The other part of the equation is you have to be able to discover them. So this is a long running problem. So getting PWAs launched in Chrome in 2015, long story, probably for some time when I’m retired, I don’t know. But it wasn’t straightforward, it wasn’t easy and it did involve overcoming a lot of internal opposition at Google.

You know, the Android team saw the web coming a mile away. They didn’t want the web as competition. You they saw what happened to desktop. And Apple had basically pulled back almost entirely in terms of team growth and ambition from the web, not long after the iPhone launched. So I would say about, you know, the iPhone 3GS was about the time when the WebKit team, their marching orders basically changed, right? You know, the original pitch was you can make all these great web apps.

job is up there saying you can do this and then iOS 2.0 comes out and then 3.0, 3.0 gives you push notifications and the App Store gives in 2.0 and then suddenly the web doesn’t get those things, right? So all the wealthy people, all the people who make decisions in technology organizations end up in the iOS ecosystem. They all carry iPhones and the web basically stops being a credible thing.

You can go to a place, can discover apps, those don’t include web apps. You can go to a browser, and in theory you can add something to the home screen, but iOS will never tell you that something is installable, it’ll never prompt you. That’s still true today. Now, it’ll give you what they invented, they called smart banners, and those smart banners are still a thing you can encounter. So if you go to a website that’s got this meta tag in it that pairs with the native app, it’ll go and it’ll prompt you to install the native app. That never arrived for the web.

So when we did PWAs on Android to start with in Chrome and Opera, those ended up being that sort of prompt moment, that sort of thing that sort of gave users a hint that they could go get the site. But again, because of that kind of oil and water relationship between the wealthy cohort and the rest of the world, the 80 % of the rest of us,

That just meant that if you were a decision maker, you couldn’t see progress in your pocket. And this compounded our problem, right? Because if you wanted to make a go of it, you would have to do it in the places where Android was dominant. Those are also the places where the phones are slowest, right? So the toxic combination of terrible sort of market positioning for the web, I mean, it should have been an easy sell, In India and Indonesia, folks were getting their first devices.

except that the websites all suck because they’re all built for the desktop or they’re built with tools which are

tuned or built to the limits of what the desktop computers of the day could take, turned into, I think, a series of problematic outcomes. again, we’re sort of rounding the corner on those sort of network and device characteristic questions. But we haven’t rounded the corner yet in terms of capabilities, of like browsers sort of generally being able to do all the kinds of stuff that a phone can do. And we haven’t rounded the corner in terms of prompts, right?

acquisition flows. And that’s specifically mostly a problem on iOS today. So there are big fights happening and I would encourage you to go reach out and talk to the folks at Open Web Advocacy to learn all about kind of how that’s going. I’ve written a lot about it and I can answer questions but they’re kind of the authoritative folks here. But I think we’re stuck at the moment, right? The web is not going to break out until such time as the conditions are… appropriate for that, and as long as Apple keeps its boot on the neck of the web, we’re not going to get to that place.

Kate Holterhoff (22:36)
Yeah, and I want to hear more about that. You have mentioned Apple and Google sort of denying, holding back this, and there’s huge competition, and a lot of this is happening behind the scenes. And I think a lot of folks just don’t even really understand the difference, right? Most day-to-day users, they can’t understand that distinction. But I would be interested to hear, what has Apple done lately that is making this so much worse?

Alex Russell (22:44)
Yeah. Yeah. They’ve been making a serial set of arguments in every capital around the world about how it’s super unsafe to have other browsers and browser engines on iOS. It seems like they are truly terrified of an idea where you might be able to get a browser from Mozilla that is not just a lick of paint on top of Safari, right? Like that scares them to their bones, apparently. And they’ve done kind of everything

you can imagine to prevent it in the same way that they did everything you can imagine to prevent right to repair or sort of USB-C for phones, right? you know. Apple will make a big show of app tracking transparency, but then they will allow Facebook to use in-app browsers to track you. They will allow that to undermine your choice of browser, where your browser could actually defend you and block some of that tracking. Apple provides Facebook with a latent advantage in that kind of tracking, simply because you don’t get the advantage of having your browser standing up for you when you tap on a link inside of one of Facebook’s apps.

Those are the kinds of places where Apple continues to self-preference its native app ecosystem in ways that are harmful to consumers and also raise their costs because they force developers into the native app store. And they don’t allow web apps into that store. And even if they did, they would try to take a cut.

the idea of having safe apps that come from the web, which are sandboxed by default in a much stronger sandbox than they provide for native apps, which have many fewer capabilities handed out by default. Like you have to actually go grant these things one by one. Like I was one of the tech leads for this project, project Fugu, where we added things like web Bluetooth and web serial and web hid and all these things that are thought of as like exotic capabilities in the web. But I gotta tell you, the use is extremely low because the grants are really in your face. Like you, you can’t go get

it easily. It’s not just like you you ask for an entitlement and you pinky swear to Apple that you’re not going to do something bad with it. And then it has to be like some press article that comes out later that tells you, my God, everyone’s like looking at like scanning all the IoT devices around you that suddenly causes them to turn it off slightly sometimes. Right. Like that’s the kind of of

ebb and flow that you see on the native side. And it was the fault of the native app ecosystems that sort of turned this into a privacy nightmare in the first place in many, in many ways. So the web has been much more conservative about that, much more secure and has put in place these sort of interposing layers where you could get a browser that has extensions, right? And those extensions could do things that you thought were meaningful for you about those concerns that you might’ve had.

And sort of instead of enabling those kind of pro user outcomes, Apple has sort of basically said, no, no, we’ve got it. beware of a dog sign really does work, nevermind all of the problems that we’ve documented over the years. pairing that with preventing other browsers and then dramatically underfunding the development of Safari relative both to the revenue that Apple makes, which is now I think reported to be something like $22 billion a year from the web and keeping staffing

effectively capped since the last decade has meant that there is no credible way for web developers to target and make great web apps on iOS. And this is just a downstream consequence of choices that Apple makes every year. Many of choices aren’t new, but you ask what’s new, and what’s new is that Apple keeps doing it, and it still sucks. They should stop doing it.

Kate Holterhoff (26:43)
the way that I have encountered that most recently is I wrote a piece on WASM and where we sit with WASM. And there were several folks online who were complaining that WASM just doesn’t work on Safari. And I was so confused because I went on Can I Use? and it said that it was supported. And then it turned out it was something about JSPI, so JavaScript Promise.

You really have to have that technical knowledge to understand exactly what it is that Apple is controlling when it comes to these app developers, because it’s not always clear. You can’t just look on the surface there. There’s levels to this, the pain that a lot of developers are encountering, and ergo users, right?

Alex Russell (27:26)
Yeah, yeah. There’s a chap, Roderick, I’m just going to mangle his last name, Dutch chap, Roderick Gadellaa, I think is how you pronounce it. And he’s got this blog post, is an abridged list of Safari showstoppers, which is basically like, if you were trying to make a web app at any point in the last decade,

You know, and remember that every bug in the WebKit engine that affects Safari affects every iOS browser. So it’s not Safari showstoppers, it’s iOS web showstoppers, because everything’s broken. There’s no alternative. You can’t get anything else.

Kate Holterhoff (28:00)
Yeah. Wow.

Alex Russell (28:04)
which is a choice that Apple makes every year. And they made it today again. So in addition to not having features, stuff keeps breaking in ways that are fundamental and there’s no alternative. And stuff like just being able to like scroll without everything scrolling underneath you, like you have a dialogue up and like the stuff underneath scrolls, which is not what you want. Like this is just basic app construction stuff. The most fundamental stuff that you need to make a UI that feels good on a mobile device.

Kate Holterhoff (28:09)
oh no.

Alex Russell (28:34)
totally broken half the time, even when it’s available. So there is this big pile of stuff which is missing capabilities.

which are much safer and easier to bring to the web, both in general and for Apple because they have a lower, they face lower costs to implement a lot of these things because they just lean on the fact that they’re only supporting a small number of operating systems. But when they do introduce stuff, like it’s often broken for many releases at a time. And the fact that they’ve got a very slow kind of iteration rate for deploying browsers up until very recently has meant that stuff can be broken for years. Push notifications still don’t work right.

Right? Like, they didn’t have push notifications for a decade. I know that multiple Fortune 5 companies went to Apple and said, hey, what’s going on? Where are the push notifications? On the one hand, Apple gaslit them and said, this is the first we’ve heard of it. And about the second or third time you hear that, that’s interesting. Maybe they just were talking to different people. Who knows?

But then, finally getting some pressure to implement this stuff because regulations coming. They implemented it only for home screen web apps, PWAs, which is a fine choice. I think it’s a fine choice that any browser vendor should be allowed to make. We would make a different choice in Edge, and we would have made a different choice in Chrome. And I think that’s a thing that browsers should be able to sort out for themselves based on their own engines. But neither here nor there. It just didn’t work right. It’s just like,

doesn’t work right in a bunch of cases. There’s whole APIs that are not just nice to have, but totally necessary for a lot of the UIs that you want to build. Where there would be an API there, there would be a property, there would be a method you could call. It just didn’t work. So it passed the test. It passed the public test. And so they got credit for it in CanIUse or even webpagetest.org. It just…

didn’t work. And this is so common with Apple’s approach to web browser development that web developers are rightly skeptical now that any corners have been turned. And I would encourage that skepticism where it’s going to take at least another decade of actually doing the job that they said they were going to do to kind of make up for the decade in which they didn’t.

Kate Holterhoff (30:47)
Yeah, that’s so heavy. Yeah. OK, so we’ve talked about a lot of the problems. I’m interested in maybe pivoting to talk about solutions and what developers can do, what folks in management can do. And you’ve written a little bit about this. So for instance, you say that poor web performance is not a technical problem per se, but a management issue. I want to hear more about that.

Alex Russell (31:11)
So I for my sins. I found myself working closely with a lot of teams who are trying to build, I would think of them as sort of ambitious experiences on the web. And they find themselves kind of reliably in the muck about performance. And so I have become a performance consultant by the by. It’s not, it’s a living, guess, is how I would put it. And the patterns that keep repeating are…

often very sad because people have been told a lot of things by the job, specifically by the JavaScript community. The web development community as a whole doesn’t necessarily believe the JavaScript community’s nonsense, but the JavaScript community intensely believes the JavaScript community’s nonsense. And that nonsense is, is extremely strong Kool-Aid these days. so a lot of tools are sold into this stuff like, you need Apollo. you need to react. And, and if you sit back and you ask, well, why do I need them? And you actually sort of walk back through the chain of logic. What you’ll, what you’ll get to is, well, you need these things.

because you have to do state management on the client. And starting from just a product management perspective, if you sit down and you look at an e-commerce website, the first question is, do I? Like, what state am I managing? I’m going from a landing page with a search box to a search results page that maybe has some filtering on the side. And then I’m going to a product detail page. And then I’m going to a cart.

and then they’re going to a checkout flow, there is nothing in common aside from the logo at the top and maybe some stuff on the left rail and the footer that’s got your copyright information that is common between those pages.

Like what state am I managing that is not effectively server state? Like what are we talking about here? And so you could have an architecture that pushes all of that logic onto the client. And then the question is, well, should you? And the answer is, just from first principles, obviously not. Like that doesn’t make any sense whatsoever. And so.

A lot of managers are told by their engineering teams now that they need to adopt these technologies because they will make their experiences fluid and fast, which may be true in a very narrow set of domains, right? Where you’ve got very long sessions operating effectively with small changes on the same data.

So think about a spreadsheet or dragging a map around or a Figma. These are sort of productivity tools, effectively. And those productivity tools are distinguished by very long sessions and lots of operations that are optimistically committed to the same local data set for responsiveness reasons.

But all the other kind of experiences that you might sort of build have very different flavors. And so if you’re not doing that thing where you’ve got a long session coupled to many updates to the same data.

the premise of these tools falls away. And even if the premise didn’t, we’re now in 2025. And so if you sort of then look at the tools individually and go, well, why is the tool shaped like that? In many cases, the answer is IE6, IE7, IE8. And I got to tell you, that’s not a thing now. It hasn’t been a thing ever on mobile. So if most of your users are on mobile, then you should be thinking about those as like a down-level thing to support to start with, unless you’re overwhelmingly a legacy product.

But even if you are, know, Microsoft doesn’t support anything other than the latest browsers on our top level productivity products. Google doesn’t support anything but the latest versions of those browsers in its productivity suite. I know because I made the argument to both sets of management and one both times. We are now in a place where I can tell you firsthand, that’s not a thing.

Right? Like you don’t have to think about IE and the fact that, you know, React is dragging a hundred K of JavaScript behind it versus Preact, which is like three or four K specifically because of the legacy that it has decided to support. The fact that it could still run an IE eight, nine, 10. If you just provide enough polyfills, that’s why it costs that much. And it doesn’t have to cost that much. So if you just like a leg up, you can just sort of reject the

the tools that come from legacy and think about your problem fresh. And that sets you on a better path. Because a lot of what’s happening in these organizations is people are thinking about technology and not the problems that their users have or the problems that the business has about the experiences they’re trying to deliver. And that is a management problem, right? That is foundationally a question about like, are you pairing choices about your product to choices about the experience you’re trying to deliver, right? So.

You know, managers are not idiots. They’re trying hard to do the right thing. And, um, you know, when we talk about kind of exploring these trade-offs and sort of using tools like small bake-offs to build confidence inside the team that they can go a different way, those are, those are repeatable tools that folks can use to try to understand the situation around them. That gives them, you know, something other than just cargo culting what everyone said to do. Um, and so that’s, you know, that’s, um, uh, an effective way to kind of help teams.

get there. And we just did the same thing in Edge. We just rebuilt almost all of our UI services, an increasing fraction of them, more than 50 now, the settings page, a lot of the dropdowns that you click on in the top level UI. A lot of stuff was built in React, and now it’s being built in Web Components because we did that same bake-off thing. We said, how fast can we go? And okay, we can go this fast because we don’t have to support the legacy. And so now we’re getting 40 to 50 percent wins across the board at P75.

And so that’s what we were hoping to see and that’s what we’re delivering and that kind of change is possible. But it’s enabled by finding that small screen, that one page, that one thing you can prototype on. Give the team a couple of days, a week, two, three to go rebuild it a couple of different times in a couple of different styles. Try something fully server side. Try something with a different client side framework.

Try wasm. don’t know. Just try everything. Like try all the things that could be reasonable and modern that fit, know, the user base you actually have. And then, you know, having, you know, when you set up the bake off, set up the criteria that you’re going to use and test things based on those criteria and then go with what works. Cause everything can work, but you just have to choose things that are going to put you in the mind of your product’s problems.

Kate Holterhoff (37:38)
so the management sounds like, is one avenue for trying to fix some of these, tremendous overwhelming issues, but another one might have something to do with, specifications and how we are, I don’t know, fostering the sort of web that we want to see in the future. And so I’m interested in what is happening, currently around web standards. So we got the… W3C and TC39, you’ve been involved with both. Is there some hope

Alex Russell (38:07)
So for full disclosure, I also used to be the tech lead for web standards on the Chrome team. So it was my responsibility, even if it wasn’t my fault in standards land for a long time. Someone better has a job now, thankfully for them, and someone that better has a job on the Edge team now for us, but I still have my hands in the till a little bit, in the dirt, not the till. Those are very different.

So, my mental model for this is that standards are downstream of implementer interest. So a lot of web developers kind of see standards as this event horizon.

Right? Sometimes the Hawking radiation escapes and you get a new spec in the world. Sometimes, you know, a bunch of enthusiasm pours into this thing. can’t see, you can’t peer over the edge, but then something happens. and, and you’re like, Hey, it happened. And it seems deeply inscrutable and no one really knows why. and I’ve been writing recently about kind of how those things actually happen in practice. and I think it, if you.

take the intent, maybe not the form, but the intent of the IETF’s motto of of rough consensus and running code, and you kind of play that forward.

That is how all new feature work on the web works. So standards are documents that are effectively dead by the time they become a standard. Because what is a standard? A standard is a group of companies who have a lot of intellectual property getting together and then saying, we disclaim any rights in the patents that are imputed to this document. That’s a standard. That’s what a standard is. That’s what standards development organizations do. They write.

IP clearinghouse checks, They receipts for IP to the ecosystem at large under specific licenses. And web standards have the property of those things being franned, not just ran. They’re free. They’re free to implement. Everyone can do it. You don’t have to pay anybody licensing costs for those patents. So.

That’s like the very legalistic version of like, is the standard and why does it matter? Well, because once something has that sort of imprimatur, it has no cost and it’s got a, you know, a big answer to you and what army. So if you go and you see the little guy, all the big guys who were in the room are going to go, excuse me, right? cause those are our patents and you should see our portfolio. And so that dynamic is what makes, standards an accelerant for adoption for designs.

But standards are not designs. So my mental model for all of this work is to try to separate the idea of what is a standard from how does design work happen. Because a lot of people are confused about this. A lot of people who spend a lot of time in standards work are confused about this, which turns into its own problem. Mostly in terms of disappointment for them. It’s actually quite sad when it happens. Because what you.

Want is an implementer, someone who has a big piece of software that can move, to be invested in changing their software such that they can solve a problem that someone who’s got the problem actually has.

And so how do we get there? Well, that’s usually through conversation. So the other important thing about standards bodies is that they enjoy protection from collusion, effectively charges of collusion in competition law. so standards bodies are one of the few places where competitors and customers can get together and be like, Hey, what should this thing look like next year? If I was designing a vacuum cleaner and I went to a vacuum cleaner,

conference and we talked about pieces of things and maybe interoperability and we didn’t do it inside of a standards body, we could be charged for colluding.

because maybe we would incrementally change the price of something, or we would maybe be pre-agreeing to change the quality properties of these things to remove competition from the market, right? That would be bad for the market. And standards are a specific carve-out in competition law that allows everyone to go, okay, we’re gonna give this away, more or less, and there is a societal benefit to that which overrides the concern about collusion. So.

a lot of folks take those properties together, like the, the accelerant property and the ability to have open discussion and say, well, we have to design things in standards bodies. And they’re right technically that you have to do the design work inside the, the IP umbrella of the standards body. But that doesn’t mean that the working group that sort of eventually writes the specification that gets the sign off and gets the receipt written for the IP is the right place to do the early design or any of the first 10 iterations of the early design. And so what you see are.

these kind of, we call them incubation processes, but they’re kind of like feeders, they’re farm teams, right? They’re like places where people can go and they can have conversations around what the problem actually is, because that’s often very fuzzy, and they can have conversations around what the potential scope of all the solutions looks like, and they can have conversations around, okay, how do I judge which one’s best? How do we try them out? How do we play with them? How do we iterate on them?

And those processes are things that have become much more explicit over the last 10 years in web standards land. We’ve worked hard to do that. The W3C probably has the best one outside of the IETF. It’s called the community group process. And we’ve got a big one called web incubation community group where you’ll see dozens of proposals and some of them fail. And that’s great. Sometimes people will like look at this and go, look at all those failures over there. And we’re like, that’s not a graveyard. That’s a set of ideas that we tried. And that’s how you make progress.

when you find out and if you found out that it wasn’t the thing to ship, you shouldn’t have shipped it in the first place. It’d be super expensive to take it back if you tried. So you don’t want to do that. You don’t get any mulligans on an old stable platforms. You just have extra barnacles on the hull. So you absolutely have to get it right. And that iterative process is necessary to do that. So one of the failure modes of standards bodies is that people will go into one of these big rooms.

They’ll go into like the CSS working group or TC39. They’d like, I’ve got a brilliant idea and you should do this tomorrow. And everyone will go, excuse me, that’s not how anything works. Worst case they’ll go, yes, we should. And then they’ll have a bunch of big fights because those rooms are also not designed for doing design. They’re designed for sort of dotting eyes, crossing T’s, doing integration work and making sure that things actually fit together rather than like that messy process of early iteration. So is there hope from standards? Yes, but it’s downstream of two things.

The first thing is developers believing that they can get their answers, get answers to problems. And so I would encourage developers who are interested in seeing the web be different, hopefully better, but at least different, to go and find these incubation groups. Go find the YCG, go find, you know, IETF, it’s the bar BoFs. WTBG doesn’t have one of these venues, but TC39 has the early stages process. And those are places where you can go and talk to other…

people who may have the same problem under the protection of that IP umbrella at low cost, low friction, low cost. You don’t, your company doesn’t have to start paying dues immediately. You can just sort of join as an individual and relative to, you know, your own employment agreements, you know, aside from that, you know, you, you should be able to, you know, participate in the design, especially if you’re an independent. And then you can find people who are interested in helping you solve those problems. We’re in an unfortunate position today with regards to the web ecosystem because

Overwhelmingly, just in terms of team size, most of those people tend to be Chromium contributors, right? Like there just are a lot more of us than there are Firefox engineer, Gecko engineers and web kittens. There’s just more blink people. So, you know, come find us. We’ll talk about it. And, you know, we have a pretty good process now for doing responsible iteration and evolution early on.

We got this whole system called origin trials where we can try things out early and then like test them out in the field and then find out whether or they actually work. You can try them on your real website and then we can still take them back. Right. We do. don’t get like burn in. Like we talk about like incidental standards where things get tried out and the early drafts sort of get burned in and no one really likes them and it’s hard to take them back. So we’ve got processes to even address those risks. And so that stuff is good and it works and we’ve gone a long, long way. The missing quantity now.

though, frankly, again, it’s iOS, right? Like, it’s no good if leaders can lead everywhere except the one operating system where it matters, right? Where you can’t take the thing that you built that uses the shiny new API and show it to your boss and be like, hey, it’s awesome. And then sort of spark a competition between browser vendors to go do that stuff. iOS is holding us back definitively because we don’t have any true browser competition on iOS. And so.

I would encourage web developers who are interested, and companies who want to make web products that are good to go discover OWA. And if you can, monetarily support them. They have been extraordinarily effective. I know that they need funds now for some of the hard work that they’re doing. So if you have time, enthusiasm, and or money to pitch in, they are fighting to make it possible for us to kind of have a web that is vibrant in the pockets of wealthy folks, not just everyone else. So, and that’ll change the game.

Kate Holterhoff (47:51)
OK, so I am going to start to wrap us up here, but I have one final question. I can’t, or you rather, can’t get out of this conversation with me without talking about AI, just the littlest bit. So I can imagine two questions to ask you about this. The first would be on the AI browser phenomena. mean, there’s a lot of them. There seems to be new ones all the time. Everyone’s acquiring them. So anyways, that just seems like.

Alex Russell (47:53)
Mm-hmm.

Okay.

Kate Holterhoff (48:16)
an interesting touch point that maybe you have thoughts on. The other one would be on vibe coding and how every time you vibe code something, it insists on using a JavaScript framework rather than just like vanilla JavaScript and like CSS. It forces you to use like Tailwind and very frustrating for me. Anyways, do either of those pique your interest? I’d be curious about your thoughts.

Alex Russell (48:38)
Sure, I mean, my mental model for this stuff is very similar to kind of, I don’t know if you know who Casey Muratori is but like I kind of take his perspective on a lot of these things specifically around the AI thing where there was a true technical achievement, a brilliant accomplishment at the bottom of this, which is that for many years, like search engines were just short word distance.

vector summarizers, right? You could sort of compute vector distance over a small number of words because you made the words much, the context much larger, you couldn’t do it, right? We just didn’t have the hardware to do it. And now with, you know, graded descent learning and transformers and the techniques that have come along, we can get very close to both understanding English and other languages, you know, without having to kind of special case all the stuff, which is incredible, right? This is just

This is a true revolution. And on the backside of that, you know, we get systems that can, can have those questions posed and do better than word, you know, small word distances. that’s wonderful. That’s, that’s new. It’s brilliant. those systems also are token predictors, right? Which, without more context than we can give them today and without,

you know, better guardrails than we have for them today are just tiny little liars. and that shows up everywhere, right? So the S can just sort of take the same model, take a smaller quantization of it, or take the same model and take like a smaller version of it and it’ll lie to you more often. Right. So that’s like, that’s just the thing. That’s just the thing that happens. and you can dress it up in, whatever terms you want, hallucination, you know, it’s got a lot of terms for it, but this is now the fundamental challenge of these systems is trying to get them to be.

A, more transparent. I’m looking for someone to kind of build a model that’s got zero temperature, right? Like that. I’m fascinated by someone, you know, spending the compute to do that. But also, you know, seeing these things put into places where we’re going to have to reckon with the idea that reading anything through this system now becomes that system considering it and then doing something about it, potentially.

autonomously. So the threat model for this, you my friend Simon Willison sort of has this, he calls it the lethal trifecta. And I was, I was fascinated to see it because it looks exactly like what we call the rule of two in Chromium. Like our idea is you shouldn’t have, there’s like three properties and you should never have more than two of them. Untrusted inputs, memory unsafe languages, and

Extent capabilities, right? So like you should never have more than two of those things in the same process. And so we put sandboxing around some of them so that we, you know, and it makes the communication channel very narrow. This is now a challenge for AI because the threat model is the copy equals execute. Copy means do. So anytime you hand anything to an LLM, you’re basically telling it, Hey, you could do anything you’re allowed to do. And this is a sort of a product level question that we don’t have an answer to. So that’s a big problem.

In terms of the ecosystem, I think we are only beginning to understand the way in which some, but not all of these firms have abused the kind of, you know, want to call it gentlemen’s agreement, whatever you want to call it, that kind of made the web work up till now. And that seems like a paired challenge. I don’t, I don’t have more thoughts about the AI browser thing other than that. Like they’re all kind of, you know, small products at the moment.

They’re not, I mean, they’re not like, they are not the primary way that people do anything yet. We can see it coming. And so there’s something to do there and it’ll stress all of those pieces. And so that will stress the ecosystem side. It will stress, you know, our questions around trustworthiness and truth. And, you know, I would like to see a lot of these companies just as a personal point, I would like to see companies stand up for truth.

and believe that it’s important that we be able to distinguish and differentiate the truth from the false. Edge is one browser. We’re not that large yet. But I’m concerned that we’re not focused enough on the question of truth.

Kate Holterhoff (53:13)
Well, that helped me tremendously. Okay, so before we do wrap up, how can folks continue to follow your thoughts on the web, your philosophical musings, your political thoughts, you know, what is your, yeah.

Alex Russell (53:26)
I don’t recommend it. but, but if you’re so inclined after the warning, my website is infrequently.org. I promise it’ll go back to being more infrequent than it’s been over the last month. It’s just been, it’s just been a lot of gaslighting from Apple, that needed some response. there was an RSS feed there. also, I’m on Mastodon and Bluesky and you can find me, from links there. So thanks.

Kate Holterhoff (53:48)
Fantastic.

All right. Well, I’ve really enjoyed speaking with you today, Alex.

Alex Russell (53:52)
And you. thank you.

Kate Holterhoff (53:53)
Again, my name is Kate Holterhoff, senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.