Frontend’s Lost Decade & The Market for Lemons

I will say that, I did spend time on TC39 in part as penance for my prior sins, making a whole generation of JavaScript toolkits, which powered things like AOL mail and like business intelligence dashboards and, big multi, megabyte data processing things for, infinite scroll lists, for very big companies.

And, at the time that we were building these frameworks in the early 2000s, we thought of JavaScript as special occasion food, right?

My friends went on to build things like Gmail and I was stuck in the code mines and other places, but we were all, thinking that the point of building these JavaScript libraries, toolkits, and frameworks what was that eventually they would evaporate, right?

The platform would rise to meet us and then we would put down our weapons and go do something, better with our later years.

But here we are.

And, as you said, I am, apparently a product manager, which is still weird for me to say, two years after I joined Microsoft, because I did spend, a dozen years as an engineer on the Chrome team, doing standards work and that sort of thing.

And this sort of continuous partnership and consulting with folks, after we launched PWAs, working with folks like Alex Danilo and others to, to try to, both spread the word, but helped people improve the quality of the experiences they were building on the web.

The point of this whole effort was in service of the idea that we would have a quality ecosystem that could compete with native.

The point of the whole exercise wasn't just to make PWAs because it was fun technology.

Designing service workers wasn't a wild romp for me.

It was necessary, the next step, in order to make it possible for us to get to a point where web applications could actually compete with mobile.

And in that long arc of eight plus years now of consulting with teams, more than a hundred teams, what has come into focus has been that the internal narratives of organizations do not support their success.

I'm reminded of George Akerlof's 1970 paper, this is George Akhilev, The Market for Lemons, which, goes into markets in which things that should be priced lower because they're low quality, have a premium associated with them.

They use the idea of a used car market, and I think we all have a mental image of used car salesmen.

And this is the jumping off the conversation, in this paper which says " there are many markets in which buyers use some market statistic to judge the quality of prospective purchases.

In this case, there is an incentive for sellers to market poor quality merchandise, since the returns for good quality accrue mainly to the entire group whose statistic is affected rather than the individual seller".

Which is to say, in a lot of these cases someone who's pitching something that you can get one over because you don't have enough information to find out whether or not that thing they're going to sell you is any good.

This has a lot of deep consequences, and I recommend you read the entire paper because it is a foundational piece of what we think of as market economics today, in which the idea of an information asymmetry, which was introduced in this paper, as a way for explaining market discontinuities, has entered our lexicon and has helped explain a lot of things about why markets, for instance, aren't actually rational or perfect.

Okay.

So let's step back and think about how it's going in frontend today in 2023.

And I think to do this effectively, we need to take a bunch of the things that we all share in our mind as stories that we carry along with us, and take them from subtext and make them text.

So I'm going to offer a few, that I see frequently in my conversations with teams.

The first, of course, is the idea that CPUs are fast now.

Now, we've been told this by the JavaScript intelligentsia, the JavaScript industrial complex has been telling us that everyone has a fast CPU, for something like a decade now.

And it's worth interrogating the question, is this true?

Query whether or not that was true.

In the mostly desktop world, it was the case that what Intel gaveth, Microsoft taketh away at some point.

But then it was browsers, right?

Then it was us.

And in the mostly desktop world that predated 2007, yeah, sure.

Stuff got a lot faster every year.

Moore's law was still effective.

We didn't have dark silicon, most everywhere we looked on a chip, most of the time, and as a result, more Watts meant more CPU compute power and people replaced their computers at a relatively quick clip.

But by 2016, most browsing was mobile.

And it has remained that way, if not increased in that sense.

When we talk about making things on the web, we talk about making things for people on phones.

First and foremost, you can make desktop websites too, but you're probably not doing that as your first approach.

Okay, I'm an American, so we're going to do an uncomfortable hands up here.

Hands up if you carry an iPhone.

All right, now keep them up if your iPhone is less than two years, 18 months old, a year and a half.

Okay, I don't mean to impute anything about you, but statistically speaking, this is weird.

This is very odd.

This room is filled with people who are outside of the norm because most sales of most phones for the last decade have been sales of Android phones.

And they are not expensive Android phones, they are Android phones.

That's true in Australia too.

Most sales of most devices are Android devices.

Even here, you're not normal, right?

In the sense of we are world historically wealthy people who service, folks who generally have less access to means and money than we do.

Engineers are well paid and you're well paid and here we are.

Okay, we have to acknowledge that in order to make progress about understanding the world as it is.

The average selling price of most, mobile phones has hovered persistently between 280 and 320 for the last decade.

It has not moved.

Sorry, US dollars.

It has not moved.

It has gone slightly up a little bit.

Now, the high end has escalated dramatically, but that's not where the volume is.

The high end escalating in price, you have gone from paying 600 for an iPhone to paying 1, 200 for an iPhone US.

Probably, personally.

And that may have reduced the rate at which you're willing to do it.

Okay, that's, an interesting effect.

But that's not the dominant effect, because you're in this very narrow band of people who can afford to do that.

Most of the world does not do that.

The volume is below 300.

New US unlocked.

Have you ever used a phone that costs less than 300 new unlocked?

Do you carry one?

Do you have one?

Okay.

And this has profound effects.

Deep, profound effects for what the actual ecosystem means.

These are four charts that I keep producing every year, or four lines in a chart that I keep producing every year, comparing top end of both the Android and iOS ecosystem, iOS at the top, top end Android at the one just below, and then the 300 price point and then the 150 price point below that.

What you can see here is that every, this is the multi core score, every Android at any price point is many years behind the, launched phone from the same year for the top end in the iOS ecosystem.

The same thing plays out for single core, which is actually what dominates most web application performance, not multicore performance.

Single core performance is even worse.

It's even more stagnant.

The top end, highest end device you can get in the Android ecosystem is between three and four years behind the same date launch iPhone.

And if you have been buying a new phone in the 300 category for the last five years, nothing got faster.

This is the performance inequality gap.

There are no fast Androids.

There are no slow iPhones and the world is mostly Androids.

Okay.

Hands up if you carry a Mac.

All right.

Keep them up.

If you bought it less than three years ago, I'm not going to call you all weirdos again, I'm sorry for the doing that.

But you need to understand that you are extremely unusual.

Apple has not pierced more than 10 percent of global desktop sales in more than a decade.

Your experience is out of the norm.

Let me introduce you to the $US250 laptop.

This is a Surface SE, and if you work in education, you may have run across one of these devices.

The $250 version of this is a Celeron based on the N4020 chip, which is a 14 nanometer part.

You haven't run probably a 14 nanometer chip in your laptop in something like five or six years.

It has two cores and four gigabytes of RAM, and it has a very slow SSD.

But the real problem with this device is not that it runs Windows, although we can talk about that.

The real problem with this device is that it has no fans, and so at almost every moment, it is 100 percent thermally throttled.

It's encased in plastic, so imagine, it's not encased in metal.

There is a $330 version.

For an extra $50, or $80, you can double the number of cores, you can double the amount of RAM, and you can double the amount of storage.

I gotta tell you, it still feels like trying to run through waste time molasses.

And that is because this whole thing is thermally throttled.

This is a new device!

This is not what is in the middle of the ecosystem.

These are brand new devices at a price point that is not unusual.

So let's put it together.

The average selling price for phones has been about $300 to $350 US for more than a decade.

The average selling price for PCs around the world for more than a decade has been in the $620 to $700 band.

These are barely budged.

And what that means is that if we take what it costs at the median, this is the median, this is the middle of the market.

If we take the median price at the middle of the market, and then we figure out how long these devices live, we can figure out what the middle device is by how long the median device today sold will live.

That will be the median device at the middle of its lifespan.

Or put another way, the median device today is the thing that was sold at this price, that number of months or years ago, right?

So if the phone lifespan is three to four years, if you have a phone that was sold for $300, 18 months ago, that's the median device, not the $300 phone today, the median PC will be the PC that was sold something like four years ago at $600.

That is what we are programming to.

So does everyone have a fast CPU now?

We have some data, more than 40 percent of edges fleet, this is to say the number of devices that we get pings from still have hard drives.

When was the last time you had a PC that had a hard drive, a computer that had a hard drive, right?

They have less than or equal to four gigabytes of RAM and they're two to four core.

This is the world as it is.

So most of the computers that we talk to, mobile phone or laptop or desktop form factor are old.

They're mostly mobile phones and they're running windows or Android.

If that is not the profile that you build and test with, we need to think hard about that.

Now you may say to me, Alex.

Okay, I hear you, but we're selling Prada handbags on the internet and I'll say to you, okay, good luck.

You don't need my help.

But if you went to QC's talk in the last session, you'll know that folks who are in any other market don't have the benefit of living in the privilege bubble.

And time is money.

It has been the most constant report from e commerce and almost any other vertical that, slow experiences cost, businesses lots and lots of money.

And so going faster actually turns into doing a better job of doing a job about making a website.

So one of the things that I hear about product managers who find themselves in the stages of grief when we start to explain to them how their product is actually working with regards to the deployed user base is that they'll say something along these lines and this little vignette of their kind of coping mechanism is really just saying, we don't want to grow into other parts of the market.

We don't think that our total addressable market is the total set of people.

We only want to serve rich users.

Now, you can't actually say that out loud, but it's also an incredibly stupid thing to say as a product manager.

It's extremely stupid because it just means that you're deciding not to grow.

You don't want that money.

That's not part of the market that you want to serve.

Do you think that passes?

Do you think that there's a, I'll talk to tech leads who will say, yeah, we know that we're trading some performance for some, market share.

Is that an agreement that you have with your management chain?

Did you tell them?

Did they sign off on that?

Do they know how much they're losing?

Okay.

Text.

Everyone's on a fast network.

And in some parts of the world, that can be true.

That can be true.

But even in Europe today, as at the end, of last year, something like 15 percent of users were connecting on two and three G networks.

Okay, who are our users?

Who are our median user?

What is the next user that we're going to sell to?

But it's worth noting that 4G and 5G radios still have 2G and 3G radios built into them.

And there are lots of pieces of variability in the mobile network experience.

And if you go outside of a city with dense stuff, or if you go to a place that's too dense, you go to a sporting event, suddenly you'll find that the variability is not just the availability of some mass cell tower.

It's a whole series of complex interactions.

And browsers and networks were not designed for that high variability environment.

The fact of you being on a 4G or 5G network may not mean the same thing.

So we are, even for wealthy users, like if I'm on wifi, but I'm on an airplane wifi, that's different to in my house wifi, right?

Like the variability in these, across these experiences is intense.

And Until we're building for that variability and having it in mind, we may not actually be building for the market that we are trying to serve.

And that market, that latent market involves billions of people who do not currently enjoy access to the same sort of things that we assume that everyone has.

And that's not going to change dramatically.

In North Africa, the primary thing that's going to change in the next decade isn't going to be that everyone has 5G, it's that people finally get 4G.

And just, I don't mean to belabor this, okay, I do a little bit, but 5G is not going to overtake 2G until 2026 worldwide.

That's the situation.

So the 75th percentile user is still a 2G user.

And this variability has lots of texture to it.

There is a regrettable feature of American networks such that the historical underserving of users based on their geography, which was based on racist policies that underserved certain classes of folks and put them in certain neighborhoods means that people who historically have been disadvantaged are now s tructurally disadvantaged for a whole series of different reasons.

They can pay 10 times as much as their neighbors for much poorer service.

Red lining is a constant, in our society.

And other societies have similar scars and discontinuities.

The digital divide is real.

It just isn't the one we think it is.

Fiction number three.

We've got this.

I started building e commerce websites as an, a young pup, in 1999, working on rca dot com where we sold televisions on the internet to 4.

0 browsers, if we were lucky, cause we still had to serve web TV.

We made a website that served SSL, not TLS.

We didn't have TLS and we made a search box and a whole set of property configurations down the left hand pane on the search results page and product detail pages and a checkout cart and a checkout flow that took a credit card and we did the whole gosh darn thing.

In 1999.

And I gotta tell you that like some folks have kept it together, the 25 year years in between have not been a total loss.

EBay, has, their metrics look good.

These are, the new, core vitals metrics starting at the left with largest contentful paint, cumulative layout shift in the middle and interactionto next paint on the right.

This is real user data.

This is coming from the actual devices that people actually use feeding back to this dashboard.

So this is not a an idea of what it might be like in the real world.

This is instrumentation from users in the field.

And there's a little bit of yellow on this, they serve the same experience roughly to mobile and desktop, and because there's a great deal of discipline being applied here, it looks pretty good.

Gumtree, again, looks okay.

The layout shifts are the thing they should probably get someone to look at, but that's actually a pretty easy fix.

Interaction to Next Paint.

Yeah, it's a little bit yellow, but okay.

Amazon, they know that time is money.

They know that time is money.

They got it, but INP is coming for everyone else too.

And the thing that draws those three top experiences in Australian e commerce retailing together is that they have not bought into any of the nonsense about javaScript frameworks that's been sold over the last decade.

They have decided to skip our lost decade.

They are making money at the expense of their competitors by not adopting the stuff that's being sold.

It's worth asking why, but let's just look at the consequences.

What's the difference between those sites and this?

Crap ton of JavaScript, JB Hi Fi, same nonsense.

Kmart, good luck if you're on an Android.

Kmart's not selling Prada handbags.

Big W?

Note that their 73th percentile user waits more than half a second every time they tap on anything on that web page for anything to happen.

That's 30 frames.

That is an eternity in computing.

Coles, you better order someplace else because that two megabytes down the wire is not helping you.

It's just the JavaScript.

It's a lot more than that, but that's just the JavaScript.

Chemist Warehouse.

It's, okay.

But this addiction to JavaScript has had a real consequence.

And what we're seeing here is literally just the JavaScript.

There are lots of other things that go wrong with web performance and you can have an argument about the first party versus third party consequences of this stuff.

But we have to understand that what's happening now is the single most expensive type of content, which is JavaScript.

JavaScript is an order of magnitude more expensive to build UI with than HTML and CSS from a browser processing perspective.

Just because we have to wait for it.

We have to run it on the main thread and then we get to paint what you do.

Whereas if you hand us HTML and CSS, we just start, we treat it as a stream.

We just start building a DOM as it comes.

And we just start to lay it out as it comes in.

Like we build something that's interactive by default, just because we had to sip the web through a straw and we got real good at it.

Now we've been trying to make, we've been doing heroic things to make JavaScript less painful on the main thread in the browser, but we still have to run your JavaScript.

And your JavaScript is running on CPUs that again, I cannot stress enough are not fast.

So Query, have we just.

We're clearly not getting better at e commerce, right?

This is an old product category.

We keep having this experience of teams rebuilding things.

I've sat with e commerce teams, top three, worldwide e commerce retailers who will tell me with a straight face that, that each phase of that sort of search, search results page, product detail page, checkout flow is a single page app.

Bullshit!

It's not.

But it was used to justify the adoption of technologies that the engineers preferred, which lost the business money.

I get called in when these things are disasters.

And in that case, a manager took me aside afterward and they, the reason they called us was of course because it was on fire.

But I couldn't tell the team.

Because the team had just done the inevitable React rewrite, right?

And that was losing them person sized bales of Benjamins.

Just lit on fire every day.

Losing more money every month than I will make in my entire career.

Because of JavaScript.

It's a crisis, but we have been in a, sort of, high agreement, situation based on these false premises that we've got this, that the networks are fast, and the CPUs are, okay, send this kind of content on the wire.

It's gonna work out.

Is it?

I've seen so many teams get to the end of a launch and then not be able to actually get it out.

I've helped unblock several teams at Microsoft in the last couple of years.

The team that I work with, which we'll talk about in a second, where these scrubbed countdowns turn into, a really bad time for the folks involved.

The teams get hurt.

The managers who back this inevitable rewrite of an existing thing find themselves owning a steaming bag of something that doesn't smell very good.

The worst, much worse, is the immediate launch, which fails.

When then, so you, hopefully you can roll it back, but in a lot of cases you can't because there was the one thing and then you did it and now you're in real trouble.

This is a common occurrence.

Teams come to us and we see this frequently.

We see, things that actually get off the pad, but then, the metrics start coming in and they don't look great and things are a little bit off kilter and before you know it, the, business side of the business has noticed because they went to their aunt's cousin's brother's house and they didn't have the best connection.

And then the CEO is wait, why is the new website slow?

Is this losing us any money?

The worst case though, the one that we get a lot of today, are where you actually get out of the gravity well a little bit, but not enough to actually complete the mission.

Where you actually find yourself inserted into the wrong orbit because now you own a pile of complexity that you can't actually operate.

You were not aware at the moment that you left the pad that you didn't have the system under control, but you didn't.

And now, because you don't actually own the system, you don't have the management capacity to put it back into the right place.

Because all of your effort went into getting something off the pad in the first place with a mis design.

This brings us to what, I do for a living now.

Part of my job is, we have a little virtual team inside of the Edge team, we call it Project Sidecar.

We go around to other parts of the business at Microsoft and we say, Hey, do you need some help with your web stuff?

Would anything help?

And there are lots of parts of Microsoft that will take us up on the offer because an increasing amount of Microsoft's applications are web stuff.

This is the new teams.

That's that part.

That's all web stuff.

That's a bit around the top, that's a WebView too.

This is the new, oh sorry, that was the new Outlook.

This is the new Teams.

Same story.

These new versions of flagship applications are mostly web stuff.

They are websites inside of WebView containers.

And those same websites are actually deployed out on the web.

You can go to, Outlook And get it.

And the same thing is playing out inside of the browser.

We make an increasing fraction of the UI that we give you inside of the browser out of what we call web UI, which is just web pages.

And this is awesome because it means that we don't have to sit there and worry about memory safety or the, building stuff at the speed of recompiling Chromium or iterate, launching stuff, or doing accessibility, with the tools that you have to sling in C++ land, which are very powerful, but also, frustratingly slow to iterate with.

So when we rebuilt the new version of Edge, unfortunately, we took a bunch of the enthusiasms that have been circulating in our community, five years ago.

And those enthusiasms led us to rebuild surfaces like this in React.

And if you know anything about the browser wars or the, browser competition, having a browser that is slow or feels slow is a fast way to churn a user.

It's a fast way to lose a user.

We do not want to lose users.

That literally is us losing money.

That's a bad thing.

And it's so much web that you can actually just go to edge colon slash browser dash your stencils and see this exact same page.

It's just a website.

We are on a journey at Microsoft to get ourselves out of this same pit that the rest of the industry has found itself in.

And I can report that, by changing the way that we make decisions, we have changed some of the outcomes.

On the left is the old version of Browser Essentials and on the right is the new version.

I could tell you all day about how we like, we're rebuilding this and web components and we're actually using the platform to its fullest.

And that's a big reason why this is much faster.

And that's true, but that's not the deciding factor.

The deciding factor, the reason that this slow mo version is so much, so compelling, like more than three times faster, and it'll actually probably be faster again by the time we actually get this out of the stable.

This is, by the way, this is a test environment that is a hosted version of WebPageTest, that we use internally at Microsoft, that has been specifically tuned to emulate that Surface SE.

That student sitting in that classroom will experience this difference.

And so we're trying to get ourselves in touch with this experience.

And the reason that we're doing better here is that we're actually writing performance into the product requirements.

And that means that we make different choices.

Choices that are unpopular, choices that are not aligned with the current vogue.

Because this is what's best for our customers.

This is what it requires to do a good job, not a popular job.

So we need new lenses as an industry, I think.

We need to put on some new glasses.

We've been very short sighted.

We've been looking at our feet.

And that has taken us in a direction which we didn't intend to go in.

I don't think anyone means to do a bad job.

I've got a Tons of empathy for the teams that find themselves with a poorly inserted orbit or actually being, blocked from launching because the performance is too bad.

It's a bad time.

It's bad for the team.

And I want those teams to have a good time.

You talk about developer experience.

There, there is no worse developer experience than having your CEO rock up and say we paid a lot of money to redevelop this thing that worked in, the stuff that you said was going to be great.

You said it was going to be fast and is it working?

Or teams finding themselves in crisis where they can't do any new feature work.

They have to stop and try to remediate for months and months at a time.

This is such a common occurrence that I think we should be honest about it and try to start avoiding it.

So the first lens that you can give your organization is to just make rich people feel what everyone else feels.

This is straightforward.

The great news about giving people these new devices is that they're cheap.

You can afford them.

I promise you can afford them.

We're also experimenting inside of Microsoft with a version of DevTools that automatically throttles this for all of our developers across the company to re emulate that Surface SE experience.

You open DevTools, you get throttled.

Live like our customers.

And then we can start to think differently about what kinds of architectures are appropriate.

We've been, we were sold all of this JavaScript stuff, for all kinds of experiences on the idea that it was, initially, if you can remember this far back, that it was going to be a better user experience.

And we now have the data, like INP is starting to price the externalities of our excesses.

And it's telling us dramatically and emphatically that we didn't build better user experiences.

So we can start to rethink these architecture choices.

And I would suggest that leads us to a principle of minimum client complexity.

Everything you do on the client, in any language, is the most expensive way to do anything.

Just from a, we're programming the devil's computer through a straw.

You don't control the CPU.

You don't control the network.

You don't control anything about the client version.

You don't control the browser itself.

You don't control which extensions are involved.

You don't control what else is happening on the computer.

This is not the data center.

We are programming the devil's computer through a straw, and that means that we want to minimize client complexity, and that means that the ratio of stuff that we do in CSS and HTML should be maximized versus the ratio of stuff we do in the expensive way in JavaScript, and this augurs for us applying more HTML and JavaScript at lower complexity For more of the use cases where we have short sessions, right?

Because if we have long sessions and we're operating on a data model on the right hand side here, with a long set of interactions across something that we're optimistically committing to, that's one thing, but that's a, actually a small set of applications or use cases.

The majority of the sites that we build actually have very short sessions.

Our data can tell us this.

Our logs can tell us this already.

We can know this.

This is not fantasy.

Our, information can already give us this advantage.

And.

If you caught QC's talk in the last slot, what you'll, what you will have seen was a masterful evolution through beginning to learn how to manage the stack that you bought, like building management, maturity and capacity to meet the complexity of the stacks that we have.

This is the fundamental challenge for most of the teams that I work with.

They have lacked the ability to even understand how much complexity they bought when they bought, brought in the new JavaScript industrial complex consensus framework.

And that has left a lot of teams in the lurch because they don't even know which questions to ask.

They're not collecting the data.

They're not managing it.

It's managing them.

And so teams whose tools manage them are always on the back foot and can't succeed.

And the teams that can succeed are the ones that could see could succeed with anything, right?

Like I keep hearing from managers and PMs that like they need to use React orthey need to use Angular because Facebook or Google used React or Angular.

And it's yeah, but do you have a staff performance team and a whole infrastructure team for this?

Do you have performance ship gates so that there's never a regression?

Do you have end to end user metrics?

Do you have like per PR stats for whether or not a full flow through your application is going to regress?

And if the answer is yes, it doesn't matter what you use.

And if the answer is no, it matters a lot what you choose, because your capacity to manage has to be married with the complexity of what you ship.

There's a bunch of questions that you can put in front of managers and I wrote a whole blog post last year about performance management maturity, which you can pick up.

But I will say that the best trade today in engineering management is to stop hiring people to make problems in JavaScript and start hiring people to solve them with HTML and CSS.

And I mean that very directly, like you have a rec out for a react or a full stack developer, close it down.

Go open a rec for an HTML expert, a markup expert, a CSS expert.

Let them sit with your design team.

Let them sit with the people who are building your design system.

That is the best trade you can make right now.

And by the way, there's a fire sale on talent.

Lots of engineering managers will tell me that they can't hire for these roles and I'll ask them if they've actually tried.

And of course the answer is no.

But there are a lot of people who will crawl out of the woodwork to do work along this path because they have these skills.

They're latent.

They just haven't been popular.

Okay.

So I've got stickers.

You can find me afterwards if you'd like to join us in our cause.

But I will say that as someone who spent their formative years working on JavaScript, trying to make the language better, working on classes and async and await and promises and, extending the language to have those kinds of conveniences and then building a whole set of APIs to help your applications be more powerful.

I don't want to still be talking about this, right?

Like I love JavaScript.

I am a prototypical JavaScript person, but we are in a bad spot.

So come join me.

The best JavaScript is less JavaScript.

And we can get there because the platform has gotten richer.

Thank you for your time and attention.

We can get through this bad time.

We can reprice our expectations.

The bezel can end.

We don't need to continue to buy the next pile of complexity when the problem is the complexity in the first place.

We're going to build the web for everyone if we're going to succeed at all because our fates are linked.

A web that doesn't work for most people isn't a web that's going to continue to soak up investment.

We're not going to continue to have jobs being web developers.

Our fates work together because we live by the link and die by the link.

Thank you for your time and thank you for your attention.