Charles_Wood:

All right, here we go.

 

Dan_Shappir:

Pause

 

Charles_Wood:

Hey,

 

Dan_Shappir:

me please.

 

Charles_Wood:

welcome back. Oh yeah, I gotta do that, huh? I always forget.

 

Dan_Shappir:

No problem.

 

Charles_Wood:

and the dance were quiet until I fix

 

Dan_Shappir:

I'm sorry.

 

Charles_Wood:

it.

 

Dan_Shappir:

I'm sorry. for a change. Ha ha. I'm paused, all

 

Charles_Wood:

All right,

 

Dan_Shappir:

good.

 

Charles_Wood:

here we go. Hey, welcome back to another episode of JavaScript Jabber. This week on our panel, we have Dan Shapir.

 

Dan_Shappir:

Hey from a cool and rainy Tel Aviv.

 

Charles_Wood:

We also have AJ O'Neill.

 

Aj:

Yo, yo, yo, coming at you live from a six foot six snowman.

 

Charles_Wood:

All right,

 

Aj:

and my

 

Charles_Wood:

we

 

Aj:

daughter

 

Charles_Wood:

also

 

Aj:

and

 

Charles_Wood:

have

 

Aj:

I built.

 

Charles_Wood:

Steve Edwards.

 

Steve:

Hello from... what do we got? Sonny Cool Portland.

 

Charles_Wood:

I'm Charles Max Wood from Top end Devs. Yeah, it's been snowing here this morning. We also have a special guest this week and that's Alex Russell. Alex, welcome back.

 

Alex_Russell:

Howdy, thanks for having me.

 

Charles_Wood:

Yeah, now, you know, we've had you on to talk about various things, but we were talking a little bit before we got on and recorded about, you know, tools and frameworks. And we've had people on to talk about various frameworks over the last little bit. We had the folks from this.com on to talk about Svelte. We had Mishko Hevry on a couple of times talk about Builder and Quick. You know, we often have topics that relate to React. And as we were talking, the topic also came up with performance and whether these things are kind of the right tool for the job, so to speak, on some of this stuff. And so I was wondering if you could kind of give us a 10,000 foot view on how to think about this stuff and whether or not, I don't know, if I have a framework, everything looks like a nail, is the right way to go, or if, you know, how do we evaluate whether or not these are the right things that we want to use? use when we start or continue to build the project.

 

Alex_Russell:

framing. Thanks for setting it up that way. Because I think you really hit on a really a core miscalculation, a fundamental error that a lot of teams make when they're sitting down to build a web property, which is that they imagine the most complicated version of that thing with the most engaged user that they could possibly have. And then they

 

Charles_Wood:

Guilty.

 

Alex_Russell:

spend a lot of time

 

Charles_Wood:

Guilty.

 

Alex_Russell:

attempting to really good for that user, right? Like attempting to say,

 

Charles_Wood:

Mm-hmm.

 

Alex_Russell:

ah, this user who spends all day in my thing is going to absolutely need this 50th interaction to feel really smooth, because otherwise they will have been very annoyed by the last 49, right? Like we need to drive

 

Charles_Wood:

Yep.

 

Alex_Russell:

down all of those latencies, and therefore we can justify to ourselves and eventually to others a very large pile of upfront cost and complexity. order to make the 50th interaction good. And I'd like teams and managers and tech leads to step back. And to the extent that they're building something that looks like something that already exists in the world, or is redeveloping an existing site, I think we're missing in the conversation a way to think about these in terms of session depth. So if you naively think about a blog, We probably all have one or we've had one at some point. A blog is for most of the consumers of the content, something that you go to once and or very infrequently, it's not part of your daily driver activity. And then you scroll, you click on a link or you go to the blog. So that's one interaction. And then you scroll. And remember, your code isn't handling scrolling. The browser is handling scrolling. We do threaded scrolling for you. It's magical. You're not doing that. So that's not actually calculus. So the only interaction that you've actually handled

 

Aj:

Except

 

Alex_Russell:

is

 

Aj:

the sites that do, and I hate them.

 

Alex_Russell:

Well, now they're on the hook. Now they're on the hook to do a good job, right? And so that actually adds to the responsibility that you take when you're doing this, because you then have to make sure that each of those interactions is as good as it could have been otherwise. OK, so let's look at the interaction depth. So you navigate to the page, you navigate to the post, and then you end up maybe handling another couple of clicks along the way. Maybe the user clicks to some related articles, or maybe they click on. or maybe they click on something in the footer to add a comment. Very few sessions are going to have, like think of it as a histogram, right? Cause like all of our performance work has done in histograms. So we don't think about one user or even a prototypical user, unless we're sort of like using them as a stand in for the worst experience, not the best. And so if you think about the histogram, the distribution of users, almost all of the users on a blog who come to a post are going to go to it. scroll and leaf. So you've got one, a single interaction across which to divide all the costs for loading that page. So then if you think about, I don't know, a Photoshop or a Figma, these are editors. These are things that are deep in the weeds. You spend many, many, many, many, many interactions per load. And this intuitive difference between them, why does it feel okay for a Photoshop or something to load up more stuff because there are no short sessions, right? They basically aren't. You may tap around, but you're probably gonna have 30, 40, 50 interactions in even the shortest session in a creative tool. And so at that side of it, you need a local data model that

 

Dan_Shappir:

Thank

 

Alex_Russell:

can

 

Dan_Shappir:

you.

 

Alex_Russell:

optimistically apply changes and synchronize them with the server. And otherwise the latency sucks because in all of these cases, you could imagine each interaction that you take as being a full server round trip and a re-render. So I think this takes us to Gmail or, I don't know, where you could, you can, in fact, there's a simple HTML version of Gmail.

 

Dan_Shappir:

Thank you.

 

Alex_Russell:

You can, in fact, feel this experience. You can go to Gmail and you can have the experience with a plain HTML version of every interaction doing a full server round trip. Just trying to read a single email. If you find a search result or a link in some other communication tool that you click on and it's just taking you to a single email, do you want to wait for the loading bar? No, you just want the email. You're just there

 

Charles_Wood:

Mm-hmm.

 

Alex_Russell:

to go to the thing and scroll. You're not doing a deep interaction. You're not composing. You're not sitting there doing chat. The primary Gmail interface will spend a lot of time getting its stuff together in order to surface to you. to do all those other things. Now, you may be setting up your primary daily mail compose and read experience, in which case, yes, you can't afford a lot of upfront stuff because the denominator is gonna be larger. If I'm gonna be using this as the thing where I triage all my email and I come back to it and I'm doing chat instead of all the rest, that is a different kind of an experience. It's because the session is different. The session depth is different. And so, for the blog example. WordPress is fascinating, because WordPress is actually bimodal. WordPress has both kinds of interaction in it. It has the

 

Dan_Shappir:

Thank you.

 

Alex_Russell:

reading experience,

 

Dan_Shappir:

Thank you.

 

Alex_Russell:

and it has

 

Dan_Shappir:

Thank you. 

Alex_Russell:

the editor experience. If you are an author on a blog, you can go to WordPress and log in, and now suddenly you're in an editor. And it's very rare that there will be short editor sessions, if that makes sense. So I encourage teams to step back and think amortizing costs across session depth, and then trying to sit back and look at other kinds of apps that are in the same area. And if they don't have their own local data about what kind of an app it is and what that will mean for session depth, to try to extrapolate from existing tools. Almost nobody, I say this with some caveats, of course, but almost nobody is building a brand new kind of thing on the web today. Like the web is vast. It's very large. stuff that you've done and almost every software project that I've worked with in the last 10 years or so, almost all of them are redevelopment. Like

 

Dan_Shappir:

Oh, for sure. We're

 

Alex_Russell:

the

 

Dan_Shappir:

all building

 

Alex_Russell:

first,

 

Dan_Shappir:

crowd applications. I mean,

 

Alex_Russell:

yeah, the first

 

Dan_Shappir:

the

 

Alex_Russell:

version

 

Dan_Shappir:

whole,

 

Alex_Russell:

of Gmail

 

Dan_Shappir:

yeah.

 

Alex_Russell:

was launched in 2001, two, right?

 

Dan_Shappir:

Mm-hmm.

 

Alex_Russell:

There has been no new, there's been no, you know, brand new Gmail in 20 years. Okay, so, okay. Let's step back then and say, I mean, there has been, they rebuilt it once, but that was the HX version. And now there's two. Well, they also built a mobile version. Anyway.

 

Aj:

I think they

 

Alex_Russell:

And

 

Aj:

rebuilt

 

Alex_Russell:

then,

 

Aj:

it again and then reverted as well. I think there's been three or four versions, but I think one

 

Alex_Russell:

I mean

 

Aj:

of

 

Dan_Shappir:

Yeah,

 

Aj:

them didn't stick around and the other one was wave.

 

Dan_Shappir:

but

 

Alex_Russell:

There was

 

Dan_Shappir:

it's

 

Alex_Russell:

the mobile

 

Dan_Shappir:

beside

 

Alex_Russell:

version.

 

Dan_Shappir:

the point. The key aspect isn't the technology or the fact that maybe they changed something. They were effectively rebuilding the same thing, only maybe slightly better. So

 

Aj:

Right, right, right.

 

Dan_Shappir:

it still goes to the point that, you know, all the web, like most of the web applications that we build are essentially the same. They are essentially mostly some form of a CRUD application. And frameworks exist because everybody's building the same thing.

 

Alex_Russell:

And we can know things about them as a result. We can say things about the population of users, about the kinds of interactions they're going to have, about the sessions they're going to traverse as they're using these things. They're not mysteries. We just aren't looking. OK, so we can step back and we can start to apply those archetypes to our work and say, OK, am I building something that's mostly a consumption or a reading experience? Right, my denominator is going to be pretty small, which means that the amount of cost that I can afford from the user's perspective to get that out the door. or get my interactions service is extremely low. If your denominator is one, I mean, it's unitary. You can't afford more than the minimum for that single interaction. So that is a, I think it's not an advanced model and I owe a blog post on this, but it's at least a first way to cut through some of the noise about frameworks because if we fixate on the idea who lives in our tool and can't live without it and has extremely long sessions, and that isn't our prototypical user or most of our users or even our P75 or P95 user, then we might be making bad choices.

 

Dan_Shappir:

Here's the thing from my perspective. The undoubted current king of the hill in framework land is React. And most other frameworks are either some sort of a take on React or a reaction to React. So they're all very much influenced by React. And React was created, as far as I understand, to support the meta slash Facebook use case, which is precisely scenario of somebody living within that site for a long time and that website effectively actually being a web app. And not only has React been created for that purpose, but because the core team, the React core team are mostly all, maybe all of them are meta employees and meta users react, then that's the guiding developing ever since.

 

Alex_Russell:

So I reordered a post last year about management maturity regarding performance. And I think it really speaks to what you're, sorry, sorry to post links to my own blog. That's kind of cheeky. But the way I understand the difference between what Meta is doing with React and what everyone else is doing with React is that Meta is, on the one hand, organization in terms of operating the technology that they've built. The React upgrades to various part or React rebuilding or use inside of Facebook was not the first time Facebook had put JavaScript on the web page, right? And it's only for a single product. And remember, the constraints of that product are a heavily engaged social network. They know who those users are, they know how engaged they are, they know how long their sessions are. with a staffed performance team. Some of the most senior engineers the company have worked on that performance team. With dedicated performance ship gates, which is to say, if you regress these metrics, you do not go to space. Your PR, your CL does not go to the product. And management, who will pay attention to those ship gates and say, no, you actually can't ship this because it's going to regress performance, because performance is engagement. If we regress performance on the site, then we regress engagement. perspective, the highest virtue. And lastly, they have, well, two more caveats, one, they can afford to build it three times, at least. They have, right? They operate Blue, the main webpage. They operate mobile.facebook.com and they operate, where's it, mbasics.facebook.com, the light version, which is, you know, extremely stripped down.

 

Dan_Shappir:

Actually

 

Alex_Russell:

All three of

 

Dan_Shappir:

built

 

Alex_Russell:

those are actively

 

Dan_Shappir:

it, by

 

Alex_Russell:

maintained.

 

Dan_Shappir:

the way, actually that light version is built in Israel, just so you know.

 

Alex_Russell:

Yeah, so there's at least two or three teams, right, who are building expressions of this service, and they segment their users. So if a user is on a device that's too slow or an app that's too slow, they can divert them to a more appropriate experience. And all the confidence behind the log in. So let's say that you need to upfront load a bundle. You have the time that it takes to do the log in for a user who hasn't been there before to start doing it. And there is a machine learning based per user bundling system. Okay, if your application has all of those guardrails and constraints and controls, then great, go for whatever Facebook recommends, go for React, it makes sense. If that's not you, if that's not your team, and if that's not your application, then, you know, we just need to step back and ask, is this for me? Because it's, you know, most apps aren't that, and for most users, that's an inappropriate choice. Or rather, you may not be applying. enough management discipline to ensure that it's an appropriate choice. And so this is where I kind of say, I don't really blame programmers for wanting to do something. But I have a lot less time for the managers who allowed this nonsense to continue. We have a real disaster in our management culture around front end. Managers keep buying Hopium. They keep buying the idea that the next framework thing is going to solve the problem of them not actually paying attention to the user experience. And it's not. just demonstrably hasn't and it's not going to.

 

Dan_Shappir:

And my experience is that very rarely do senior managers in most companies, putting aside what you said about meta, actually take into consideration which framework to use before they actually buy into it based

 

Alex_Russell:

That's

 

Dan_Shappir:

on

 

Alex_Russell:

right.

 

Dan_Shappir:

the consideration that you just mentioned. Basically,

 

Alex_Russell:

Thank you.

 

Dan_Shappir:

they

 

Alex_Russell:

Bye.

 

Dan_Shappir:

ask the developers more or less, which frameworks do you guys want to use? Well, what's considered? do it like best and then they

 

Alex_Russell:

They don't

 

Dan_Shappir:

go

 

Alex_Russell:

use their

 

Dan_Shappir:

with that.

 

Alex_Russell:

marks, right? They are the dumb money. They are the folks who should not be buying a framework. They can't afford a framework. Just from an organizational capacity perspective, whatever they think they're spending, they may be getting something entirely different, right? It's like hiring interpretive dance artists to do some like demolition on a house upgrade, right? Like the wall might come down, but the people doing the thing probably aren't doing what you think they're doing for the reasons that you think that you're doing it and you're going to have a lot of questions about why it's so slow but you're not going to get good answers. Right?

 

Aj:

So

 

Dan_Shappir:

Here.

 

Aj:

break that down a little bit more because I mean, the reason that If everybody's so inexperienced and everybody's so bad at everything, then the framework is at least a baseline and it has documentation,

 

Alex_Russell:

No, it's not. HTML

 

Aj:

which

 

Alex_Russell:

is the

 

Aj:

is...

 

Alex_Russell:

baseline.

 

Aj:

what?

 

Alex_Russell:

It's not. No, no, no. That's wrong. If you think about how a browser processes a web page, the baseline is HTML. We take HTML off the wire,

 

Aj:

Yes,

 

Alex_Russell:

we

 

Aj:

but

 

Alex_Russell:

turn it into DOM nodes.

 

Aj:

I mean in terms of a group of people working on a thing. If everybody's inexperienced and they don't have good management, all of these

 

Alex_Russell:

Yeah.

 

Aj:

problems that you're surfacing, which I agree, but then the problem that the framework solves from my perspective is not a technical problem, it's a communication problem because it provides the documentation and a figurehead who says, do it like this.

 

Alex_Russell:

Yeah, I um, it's hard for me to disagree more, but I'll try.

 

Charles_Wood:

Ha ha

 

Aj:

Great!

 

Charles_Wood:

ha ha ha ha

 

Aj:

Go on!

 

Alex_Russell:

So, so um... One way, I think you've perfectly encapsulated a framing of the narrative around frameworks, which is to say, I need the framework because rather than, what am I trying to do here? Because your alternatives are not, I'm doing something in JavaScript now, what? The alternatives are a vast world of existing technologies that have worked for more than two decades that generate HTML and CSS, right? Like the baseline assumption for how on screen if I'm building something for the web is I need HTML and then I maybe need to style it. Right? Like that's what the browser sees in order to generate pixels. JavaScript is the fuck it we're doing it live of web development. It takes control away from the browser and then says I'm going to rebuild everything that I'm going to do inside the JavaScript and I'm going to take that control away from the browser's ability to optimize those properties. Right? Like when people talk about like, oh yeah. about the current problem with JavaScript frameworks because we're going to rebuild it in Rust and Wasm. What I hear is, I don't understand how scrolling works. I don't understand how resource loading works, and I don't understand browsers. You're telling me that you actually cannot be trusted with these tools because you don't understand them. You don't understand what they do. You don't understand the thousands of engineer hours, hundreds of engineer years that go into making sure that scrolling doesn't feel like junk.

 

Aj:

with you

 

Dan_Shappir:

I need

 

Aj:

100%.

 

Dan_Shappir:

to interrupt for a second. I think we need to put it out there that for the past two decades, C++ engineers have done an incredible job of making the web faster while JavaScript engineers have done their utmost to make the web slower. So it's kind of an ongoing war between these two camps of developers. Who can win? And it looks like the JavaScript guys are winning because you know always bet on JavaScript.

 

Alex_Russell:

Are you familiar with the idea of induced demand?

 

Dan_Shappir:

Nope.

 

Alex_Russell:

Okay, so there's a theory, you know, it's disputed, but the idea that, you know, why is traffic so bad in California is a question that as a California resident, I have to unfortunately pay some attention to. And the answer isn't for lack of roads, right? We've got some of the most roads, some of the biggest roads, some of the widest roads, and adding a new lane to a highway. I mean, but yes, we've got a population, but it's not even particularly dense compared to like real cities. You know traffic is bad because we keep building roads like that. That's the way to think about it So when we make a road wider, we actually don't reduce demand for cars We don't actually make anything faster because people will then say oh well This is a fine way to get around I'm gonna buy a car because then I can get there right so Creating roads creates demand for cars which fills roads. So

 

Steve:

And that's what most businesses want to do, right?

 

Alex_Russell:

we have made JavaScript

 

Steve:

They want to create demand for their product. So, I'm going to go ahead and do a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of a little bit of

 

Alex_Russell:

So we've spent a lot of time, like, browser engineers have spent a lot of time creating a wider lane for you to write JavaScript in. And I would say to my friends on the V8 team, you know, it's worth actually investigating whether or not any gain that you make this quarter persists. Because if you make it faster, what we experience is JavaScript developers just filling the channel. They just fill that wider channel with more nonsense. And I mean that from the, users perspective.

 

Dan_Shappir:

Just as

 

Alex_Russell:

It's

 

Dan_Shappir:

a comment

 

Alex_Russell:

nonsense.

 

Dan_Shappir:

for our listeners, in case they may not know, V8 is the JavaScript engine within the Chrome browser and now also within Edge. So

 

Alex_Russell:

Yeah, yeah.

 

Dan_Shappir:

that's what your JavaScript programs are running on. And as Alex alluded, they've done an amazing job over the years of making JavaScript run ever faster. You know, the same JavaScript run ever faster, which, as you say, has driven us Java developers ever more JavaScript at the V8 engine. Yeah.

 

Alex_Russell:

So.

 

Steve:

To me, the phrase that

 

Aj:

Did

 

Steve:

comes

 

Aj:

you just

 

Steve:

to mind

 

Aj:

call

 

Steve:

is

 

Aj:

us

 

Steve:

that

 

Aj:

Java

 

Steve:

nature...

 

Aj:

developers?

 

Dan_Shappir:

Sorry.

 

Steve:

The

 

Aj:

Would

 

Steve:

phrase

 

Aj:

you just

 

Steve:

that

 

Aj:

call

 

Steve:

comes

 

Aj:

us?

 

Steve:

to mind is nature abhors a vacuum.

 

Alex_Russell:

So there's a little of that. I think there's also a problem of management. And I use this phrase broadly. But you could say that the culture of front end has degraded, that people who build front end websites don't share a cultural norm that our jobs do a good job for the marginal user. And that is to say, users who are not themselves. And I think some of this is natural. from a world where most people who were getting onto the internet were getting onto the internet in a way that was not too dissimilar from the way that the developer was getting onto the internet. They had a PC under their desk. It was you know within a couple of generations of age of the first thing and you know the network was what it was. It wasn't fast but everyone was sort of like in some you know at least one order of magnitude of difference of each other in terms of building and consuming those experiences. And today we've moved to a world where the high end and the low end have delaminated they have come apart from each other. They are now entirely independent trajectories and developers continue to live the life of luxury. They continue to live in a world of fast computers and fast networks because that's how you, you know, that's the best version of computing and developers wanna be good computer-ing people. So we have ended up in a place where there's very little attachment or even comprehension about how the choices making really play out in the real world and you have to go study the world in order to rebuild that understanding

 

Dan_Shappir:

So Alex,

 

Alex_Russell:

and that's a new muscle.

 

Dan_Shappir:

Alex, I know that you've written several articles on what you just described, this separation that exists between the high end and the low end on the web. Can you give some numbers to, you know, like some examples?

 

Alex_Russell:

Sure, sure. So I'll drop another link to this series of articles I've been writing since about 2017, trying to keep tabs on the evolving reality. And so the TLDR of the article is a work back from an estimate of where the 75th percentile user, which is to say the user who's on a device that is three quarters of the way through the distribution from fastest to slowest. So the slowest device is going to be way out in the tail. It's going to be north of P99. The P75 user is going to be someone who is experiencing the way a quarter of users experience it, and it'll be faster for everyone else. So maybe that's too conservative of an estimate. A lot of teams that I work with only report P95. And I think that's a good way to work if you're working in terms of a performance organization. If you're not that sophisticated, don't have that much discipline and P75 is better than P50, P50 is a lie. Don't think about medians. Medians are junk. So the P75 user is an attempt to characterize a target that we can try to learn something about and try to situate ourselves in their lives and say, what's computing like for them? How does it work? Like if I just tap on a link and go to a webpage, what's the situation they're in? And so this is a work back what we know about the market for devices and the network reality that folks are experiencing today. And the market for devices, the interesting part about it is that it's a market that is mostly about old devices. So the replacement rates for devices define what the current deployed fleet looks like. So devices age out at some amount, right? So you can think of them as like a So how big is the bucket is kind of like how many devices are there in the world. You're pouring some new devices in and you're draining some old ones out and they drain out usually at the rate at which they become too slow from the user's perspective to do the job or they break. And for mobile devices that they break pretty pretty fast because they're in a harsher environment right they're kicking around in our pockets and they're now users most

 

Aj:

Or because they're

 

Alex_Russell:

personal

 

Aj:

made

 

Alex_Russell:

devices.

 

Aj:

of glass on the front and the back. And nothing to do with

 

Alex_Russell:

Yeah.

 

Aj:

the environment, because they used to last just fine.

 

Dan_Shappir:

They fall into toilets.

 

Alex_Russell:

They befall all sorts of foul outcomes. Yeah, sure. So the device replacement rates in mobile are between three and five years. In most markets, it's different by market. The richer the market, the more wealthy the users in the market, the faster devices tend to get replaced. There are also effects about newness. So the first phone that you get is something that's probably lower end. And then you don't know. lot on it because you weren't sold on the value of it, especially in emerging markets. And then you tear up the next time you buy because suddenly you know that it's valuable and you'd like a better version of that. So there are a lot of these confounding effects that conflate different inputs and outputs with each other. But we can look at the broad aggregates to try to understand how it's going. So the P75 device today is not an iOS device. Apple sells between 15% and 20% of devices in a given year. They last longer because they're better made, they're better built, they're nicer devices, and they're much faster through their entire lives, but the market is entirely segmented. So the top end is all Android, sorry, is all iOS, and the bottom end is all Android. There are no slow iOS devices and there are no fast androids. That's like, that's a good way to think about it. Maybe Qualcomm will someday get off the, you know, get off their

 

Dan_Shappir:

That's pretty harsh what you just said. The fact that there are no fast

 

Alex_Russell:

Thank you. Thank you.

 

Dan_Shappir:

Android devices, that's, you know, that's...

 

Aj:

But it's

 

Alex_Russell:

Okay,

 

Aj:

from the process

 

Alex_Russell:

go

 

Aj:

of

 

Alex_Russell:

have

 

Aj:

perspective,

 

Alex_Russell:

a look at the...

 

Aj:

it's true because they don't they optimize for multi-core not for they do horizontal scale, not vertical scale and JavaScript is single threaded.

 

Alex_Russell:

Well, here's the multi-core chart. So I've been tracking this for a lot of years now. Here's the latest chart from my re-gathering last year. I guess they've just released the S23 Ultra, but a good way to think about the most expensive Android device you can buy today is that it is between 18 and 24 months, the latest iOS device.

 

Dan_Shappir:

So

 

Alex_Russell:

That's multi-core.

 

Dan_Shappir:

iOS

 

Alex_Russell:

That's multi-core.

 

Dan_Shappir:

is two years to a year and a half ahead of any Android device. It's basically what you're saying.

 

Alex_Russell:

their chips are.

 

Dan_Shappir:

Yeah.

 

Alex_Russell:

And this is single core, it's

 

Aj:

And

 

Alex_Russell:

worse.

 

Aj:

Apple forces you out. Even if the phone is fine, it's in pristine condition, it's working, you eventually get forced out of Apple because they release software updates that make the phone unusable and then stop releasing updates and you can't downgrade. And that's it. I hope you enjoyed this video. I'll see you in the next one. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye.

 

Steve:

And

 

Alex_Russell:

I

 

Steve:

that's

 

Alex_Russell:

mean,

 

Steve:

the same

 

Alex_Russell:

that's slightly

 

Steve:

for their

 

Alex_Russell:

preferable.

 

Steve:

laptops and other computers too. I've run into that a couple of times.

 

Alex_Russell:

It's slightly preferable to not getting any updates at all, which is kind of the average Android experience. But let's say we'll just offer a side of this for a second. And say, oh, sorry, put it to the side. And say that if we understand that the P75 user is a user on a median priced Android from three years ago, what was the median price three years ago, and what did it buy? The median price for smartphones, pricing has kind of also delaminated, like the low end is getting much more much more successful in terms of market penetration and the high end is just getting much much more expensive. The median price hasn't fluctuated that much. It's bounced around between you know $275 and $325. It's about 300 bucks. Three years ago it was about 300 bucks worldwide. So if you think about what did $300 of smartphone buy you three years ago, suddenly you have your understanding of what that device is. It doesn't have a 5G radio. It was three years ago. Like even if there is a 5G deployment in your local area, the median user does not have 5G. They can't. There's no 5G radio in there twice because 300 years ago you couldn't get a 5G radio for that price. You could actually probably couldn't get a 5G radio for that price. And they are on, you know, they're definitely like if you're looking worldwide, they're definitely not in the US or even in another geography with fast networks in general. Although the price for data has fallen precipitously outside these more expensive Western markets. So they have access to lots of data. It's just not that fast, but it's a lot better than it used to be. So networks are improving dramatically. So that's good. We can think about low speed 4G is now being kind of where we want to target. We don't have to think about 3G much anymore. This is huge progress. This is awesome. 5G is not going to happen for these users for a long time. That's a factor both of physical hardware deployment and capital requirements for operators, but also of their devices. And then from the performance of their devices, you should understand that the median device is a mid tier to low end Android, and their performance is basically stagnant. They are not getting faster. So in the charts that I showed there, I track a couple of lines. The top is the fastest iOS device you can get at the moment. The second is the fastest Android device you can get at the moment. These are all with deep bench scores, by the way. The third is median priced worldwide Android devices, and then the bottom is the low end, the true low end, like about a hundred bucks rather than two to 300. So performance at the median is stagnant. So if you are buying a high end Android or a high end or an iOS device, which is by definition high end, your reality for who your users probably are is not representative. you have to do work to recreate an understanding of who's actually going to experience your content and how it's gonna go. You know, it was always the joke, right? Like works on my Netscape. In early web development, I was like, oh, this seems broken, all works in my Netscape. But that kind of like insular privilege of it's working for me, it has come entirely from market reality. Market reality is not fast devices, it's not fast networks.

 

Aj:

So what this graph is showing, by the way, from my perspective is that the iPhone that I just upgraded from, which is the iPhone SE, is better than all except for the Galaxy line, the Galaxy S tier. Everything else. And that's it. I hope you enjoyed this video. I'll see you in

 

Alex_Russell:

Correct.

 

Aj:

the next one. Bye. Bye. Bye. Bye. Bye. Bye.

 

Alex_Russell:

In terms of single and multi-core CPU performance, that's correct.

 

Aj:

Yeah, yeah, so my, well, I guess what is it, 2016? So for seven year old iPhone SE is what the average person is experiencing on the web. And let me tell you, it's terrible.

 

Alex_Russell:

And so I didn't say average, I said P75.

 

Aj:

Oh, meet, meet, okay. Oh, this is right.

 

Alex_Russell:

Yeah, so

 

Aj:

So 20, the, the,

 

Alex_Russell:

we're thinking in histograms

 

Aj:

the

 

Alex_Russell:

now. It's a little bit harder. The average will be, again, think about the median price device sold two years ago. If the replacement rate is four years, you can sort of say, OK, what was the median device sold then? And then we do that. There could be confounding factors that cause that kind of a little model for how to construct that analysis to be totally wrong. But fortunately, looking a little bit more deeply into sales and the actual device performance, I don't think we need to think that much harder that right now, which is good, which makes it easier.

 

Dan_Shappir:

So to put it in practical terms, if I'm building a website using a framework, and it's an actual website, not a web app, that means that I predominantly care about the first two or three interactions, then at least 25% of my users are going to get really bad experience, is what you're saying.

 

Alex_Russell:

Well, that's partially up to you. I think this is where we come back to

 

Charles_Wood:

Ha

 

Alex_Russell:

the question

 

Charles_Wood:

ha ha

 

Alex_Russell:

of

 

Charles_Wood:

ha!

 

Alex_Russell:

frameworks, right? Like, you have agency. There's a bunch of stuff that's out of our control, right? We're programming the Devils computer over links we don't own, sipping it through a straw. And we can't count on not even the software version or the OS, right? Like, we're in a much harder world of uncontrolled variables than most other client-side programmers in the world. It's important that we respect that. Those differences don't go away just because we have I don't know iOS envy or like native app developer envy. Those differences don't disappear on us.

 

Dan_Shappir:

And here, I think, is a key aspect, because we've been talking about the developers and about the negligence of managers. So the ones that do actually have agency are the developers. And there is, I think, there's an interesting situation with web developers who, like, the way that they feel about it developers like to see themselves as if they're building web apps, where in fact they're building web pages. So they're building their web pages is using tools that are mostly appropriate for web apps, which is what you kind of touched on at the beginning of our conversation. But you know, because that's the way they like or envisions themselves as application developers. They prefer to use such tools, and like you said, it does work on their machine. I mean, they can demo an actual working version of whatever it is they were tasked to build, so that's what they built. And so, that's what they built. And so, that's what they built. And so, that's what they built. And so, that's what they built.

 

Alex_Russell:

Look, if you hire clowns to do bricklaying for you, you're going to be entertained the whole time. The End

 

Charles_Wood:

I love

 

Alex_Russell:

And you

 

Charles_Wood:

these

 

Alex_Russell:

might

 

Charles_Wood:

examples.

 

Alex_Russell:

even get a wall. You might even get a wall out the other side. But the job that's being done, and the one that you thought was being done, can be extremely different if you aren't focused on what the end product is, rather than anything else. If you're focused heavily on the end product, then maybe you hire clowns. Maybe clowns are the best way to lay bricks today. I don't know. It could be awesome. But it seems like if you do, you that a couple of times and it's not working out and you're still in the process of needing to put up some brick walls, you've got a problem, right, if you keep hiring clowns.

 

Dan_Shappir:

So what are you saying that

 

Charles_Wood:

So.

 

Dan_Shappir:

we should all be using WordPress rather than React?

 

Steve:

Please

 

Charles_Wood:

I'm going

 

Steve:

no,

 

Charles_Wood:

for

 

Steve:

please

 

Charles_Wood:

my face

 

Steve:

no.

 

Charles_Wood:

makeup.

 

Alex_Russell:

Um

 

Charles_Wood:

So I think the question that I would ask, and I think it's along the same vein as Dan, maybe a little more broad, is if the tools that we're instinctively reaching for, because they're nice, they make us happy, whatever, aren't the ones that are going to get us the outcome we want with our users or with the applications we wanna build or things like that, what do we do? Because it seems like you're making case against certain technologies as opposed to telling us, okay, so yeah, what is the right thing to reach for? What is the right choice on? I need to put something together that gives utility to people who are using phones, laptops, tablets to access my webpage so that they can get the thing that they need done, done, to get their job

 

Alex_Russell:

Yeah.

 

Charles_Wood:

done so that companies

 

Alex_Russell:

Yeah.

 

Charles_Wood:

will pay me or people will pay me so that I can keep

 

Alex_Russell:

That's

 

Charles_Wood:

the

 

Alex_Russell:

right.

 

Charles_Wood:

lights on and pay my employees. So what do I do?

 

Alex_Russell:

Right.

 

Charles_Wood:

Where do I go?

 

Alex_Russell:

Great, so let's create a choice architecture that you can play forward to try to help make these decisions. Because if we look at the complexities that we've just talked about, and we're really honest about them, the first thing that falls out of that calculus is to say there isn't a one-size-fits-all. We have to acknowledge that for the users who are in an editor experience, it's going to be better if I don't have to go to the server every single time I type a key, or every time I tap a button.

 

Charles_Wood:

Mm-hmm.

 

Dan_Shappir:

Thank you.

 

Alex_Russell:

Why was it

 

Dan_Shappir:

Thank you. 

 

Alex_Russell:

a sea change to go from map quest where you clicked North, South, East, West to Google Maps, Slippy Maps? Why was that a sea change? It was a

 

Aj:

What,

 

Alex_Russell:

sea change

 

Aj:

a

 

Alex_Russell:

because

 

Aj:

what, a

 

Alex_Russell:

on

 

Aj:

what

 

Alex_Russell:

a perp

 

Aj:

change?

 

Alex_Russell:

sea change, it was a huge difference in the quality of the user experience. It was a new epoch of how we could

 

Aj:

Okay,

 

Alex_Russell:

build interactive

 

Aj:

C

 

Alex_Russell:

experiences.

 

Aj:

as in ocean,

 

Steve:

S-E-A,

 

Aj:

got it.

 

Steve:

not the letter C

 

Dan_Shappir:

Yeah,

 

Steve:

or

 

Alex_Russell:

Sorry,

 

Steve:

the language

 

Alex_Russell:

sorry,

 

Dan_Shappir:

by

 

Steve:

area,

 

Dan_Shappir:

the

 

Alex_Russell:

sorry.

 

Dan_Shappir:

way,

 

Steve:

J.

 

Dan_Shappir:

if I can

 

Alex_Russell:

Uh.

 

Dan_Shappir:

give a concrete specific example of my own, back when I worked at Wix, we had totally distinct performance metrics that we would use for the Wix editor versus websites that were built using the Wix editor.

 

Aj:

ᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠ 

 

Dan_Shappir:

So for the Wix editor, the primary metric was about responsiveness of interaction once the editor was already loaded. Our users would literally tell us, like they would be blunt, they would say, I don't care how long it takes to load, as long that once it is loaded, it's

 

Alex_Russell:

Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.

 

Dan_Shappir:

super responsive to my interactions. I'll go and make myself a cup of coffee while it's loading and just make sure that once it's up and running,

 

Aj:

ლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლ 

 

Dan_Shappir:

that it's really responsive and all my interactions are fluid. Obviously, for the websites that were built, it where you needed to get them to load

 

Aj:

ស្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្្ 

 

Dan_Shappir:

as quickly as possible and most sessions were usually one or two pages deep and that would be it.

 

Alex_Russell:

Yeah, you've extremely adeptly captured that difference in type being related to session depth, being related to that user success is dominated by the depth of their sessions. And so what we can afford is what we can divide by the number of interactions. So we want to make each we want to make that that resulting number as low as possible. So we want the lowest latency possible for each interaction. And maybe that's a weighted sum or something with some variance. number associated with it so that we can account for the differences in latency. But that kind of little tiny mental model of, I've got really deep sessions, users doing tons of stuff here, it's gonna feel better if I have a local data store and I've loaded everything

 

Aj:

ლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლ 

 

Alex_Russell:

into memory and I'm making local commits as I sync things back to the server. Being very different to the idea of just going to a thing, doing a couple of interactions. Okay, so now we have this kind of like tunable decision framework where we can think about What are my users? Where are they? Because that matters. So who are they? What kind of environment are they on? If I'm looking at my 75th percentile user, what kind of device are they

 

Aj:

ლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლ 

 

Alex_Russell:

on? So for Microsoft, I like to think of, this is a device we sell. This is the Surface SE. You can buy these if you're a school. This is a

 

Aj:

ᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠ 

 

Alex_Russell:

four core. This is the higher end model. two core version. This is a four core Intel, what is it, N4020 and 4021, something like that. If it does two gigahertz on a good day, you're getting a lot of value out of it. It's got four gigabytes of memory or eight gigabytes. This is not a loaded spec machine. And you all on this call probably have phones that are faster than this device, right? So like that's the kind of target that we can set.

 

Aj:

ლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლ 

 

Alex_Russell:

We can say we want our applications good for these users. We can situate it very

 

Charles_Wood:

Mm-hmm

 

Alex_Russell:

specifically and say, this is a slow target. We can hit it where we can set it, and then we can see if we can hit it. And then we can break down, what are we building? We know who we're building for. We know what kind of networks they're on, what kind of devices they're on, and then we can start to characterize what we're building. Are we building something with long sessions or short sessions? Is it bibodal? Are there three humps in that distribution? How can we think about the kind of experiences through our app. And if it's brand new development, we can go look at the existing corpus of applications in the world and say, what are their kinds of sessions like? What kind of things do they do? Maybe you have to go have a conversation with some of your peers or go ask the Web Performance community or, I don't know, ask Dan to put up a Twitter poll and see what we can get back out of it. It's possible for us to try to come to a better understanding of that as we develop. And then we can start to understand what's an appropriate. choice in terms of the budget that falls out of that calculus. So in that blog post about the performance baseline for 2023, I put together a little thing yet about first page load. And that first page load is like

 

Aj:

ლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლლ 

 

Alex_Russell:

loading a page is an extremely complicated thing to do.

 

Charles_Wood:

Mm-hmm.

 

Alex_Russell:

We do lots of stuff when you load a page. And even saying when it's done is extremely challenging. The web performance community has spent years trying to iterate on different definitions that will be more and more accurate about what it means to be done loading a page. So let's not pretend it's simple. What we can say is for the P75 user on the P75 network, we can afford, if we can, if we're mostly made of JavaScript, we can afford this much JavaScript

 

Aj:

ᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠ 

 

Alex_Russell:

and this much HTML and CSS. If we're mostly made of HTML and CSS, we can afford a lot more because it's much simpler and faster for the browser to process HTML and CSS and we could transferring more of the work to the runtime rather than fuck it, we're gonna do it live. And so if you lean more heavily on the browser in those environments, sorry. If you lean more heavily on the

 

Aj:

ᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠᶠ 

 

Alex_Russell:

browser in those environments, then you end up in a situation where your budget expands. So there's a bunch of follow on questions around things like fonts and images and how can we think about delayed loading and deferred loading. Those are all really important. level, if you take those budgets and you think about them as a per interaction budget, you can start to set a per interaction budget for a latency. How long do I want in each interaction, my denominator, to take? And then you can start to think about how can I, over the length of a session that I know something about, get to a point where they mostly fit inside of that window.

 

Dan_Shappir:

So let me put it again in a very blunt and practical sort of a way. If you were tasked with building an e-commerce website today.

 

Alex_Russell:

Yeah, your e-commerce website is not an SPA.

 

Dan_Shappir:

What yeah, so that kind of brings into the question what which technology you know putting aside like you know

 

Alex_Russell:

Yeah,

 

Dan_Shappir:

Shop

 

Alex_Russell:

like

 

Dan_Shappir:

if fireworks

 

Alex_Russell:

SPA we should-

 

Dan_Shappir:

or something. Let's say you're building it from scratch from the ground up What technologies would you be using?

 

Alex_Russell:

Uh, something that outputs HTML. Um, I don't know. PHP Django, right? Um, Rails, whatever.

 

Aj:

I

 

Charles_Wood:

Ha ha ha ha ha ha ha

 

Alex_Russell:

Look,

 

Charles_Wood:

You can say

 

Alex_Russell:

your

 

Charles_Wood:

rails

 

Alex_Russell:

revulsion

 

Charles_Wood:

again.

 

Alex_Russell:

is

 

Charles_Wood:

That

 

Alex_Russell:

not

 

Charles_Wood:

makes

 

Alex_Russell:

user

 

Charles_Wood:

me feel

 

Alex_Russell:

success.

 

Charles_Wood:

good. Right.

 

Alex_Russell:

Your revulsion is not user success.

 

Charles_Wood:

So

 

Aj:

Uhh... but what

 

Charles_Wood:

one other

 

Aj:

about

 

Charles_Wood:

question

 

Aj:

maintainability?

 

Charles_Wood:

that I have. Use rails. Um, sorry, bias. Anyway,

 

Aj:

Agreed. No,

 

Charles_Wood:

um...

 

Aj:

no, Wales

 

Alex_Russell:

Yeah,

 

Aj:

is fine.

 

Alex_Russell:

Rails is great. I mean,

 

Charles_Wood:

Yeah.

 

Alex_Russell:

Rails has all

 

Aj:

It's

 

Alex_Russell:

the problems

 

Aj:

slow

 

Alex_Russell:

we all

 

Aj:

as

 

Alex_Russell:

know

 

Aj:

dog

 

Alex_Russell:

Rails has.

 

Aj:

poop, but it's great.

 

Dan_Shappir:

By the way, these days we seem to finally have an option of actually kind of using JavaScript on the back end and getting what you're describing in the form of Astro, I guess.

 

Alex_Russell:

I mean, we've

 

Dan_Shappir:

And...

 

Alex_Russell:

had it for 10 years, right? You could make an Express app. You could output HTML, you could template HTML on the server side. It's all worked the whole time.

 

Dan_Shappir:

Yeah, but

 

Charles_Wood:

Okay, so

 

Dan_Shappir:

yeah.

 

Charles_Wood:

the question that I'm trying to ask is, does something like server-side rendering in React or something like that, is that sufficient if you tone back what you're doing on the front end? So, I'm trying to ask, does something like server-side rendering in React or something like that, is that sufficient if you tone back what you're doing on the front end? So, I'm trying to ask, does something like server-side rendering in React or something like that,

 

Alex_Russell:

That's a really important question. I'm glad you asked it. Because one of the great things about getting more honest about the costs that we're paying and who we're paying them for and what we're getting out of it is that it allows us to start making much more informed trade-offs. So let's say you have a big React application and you know that it can sort of minimally service I've rendered today. I have in the past two teams in this recommended a tourniquet approach, right? Like no JavaScript goes to the client unless it's signed off by your most senior engineer and a small team of people who are actually deputized to write code for the client, which is in most organizations should be a minuscule bucket compared to the set of people who are building features. And then on the back end, yeah, I mean, you can service-side render it, but now you have an interesting conversation with your management about cost. You've started to move a lot of those costs from a negative externality. You're losing the business money to latency on the client side, but no one can really see it unless they look hard, so maybe you get away with it. It's just pollution. A lot of JavaScript these days is effectively performance pollution, but because it's a negative externality, you're putting it out into the world, but you're not paying for it, you don't have a really drilled in conversation But once it's on your server, you're paying to run it. So now the costs compared to building that same HTML some other way can be a more informed and I'd submit honest conversation, right? Is React a good replacement for PHP? I don't know, maybe. If you like that and you can afford it, like if the cost of goods sold doesn't go up so high that it's not economic, then cool. But you know, I have that anyone who can deal with the extreme complexity of a system like React can write server side templates too in any language, right? Like it's, these are... 

 

Dan_Shappir:

So we had an interesting conversation with Kent, Kent C. Dodds when he was on our show, speaking about a remix, but also about his view of the evolution of the web application. And the point that he put forward was that some interactions, even in let's call it lightweight type scenarios, do work better can at least begin handling them on the client side. Like, I don't know, like the example that he gave was liking a tweet. You don't want to do a re-render, a reload of the webpage containing a bunch of tweets just in order to like a tweet. And if you're going to do templating both on the client side and on the server side, it's much more convenient and more maintainable if you're using the same programming language and the same tooling on both sides. If you're doing the template, building the same templates on the server side and the client side, but on the server side using PHP and on the client side doing DOM manipulations, then it can become a challenge to ensure that they remain consistent.

 

Alex_Russell:

And this is now a really fruitful conversation because, you know, if you're in the Rails land, you can just do a partial. Right, just replace a partial. So you're right. You don't have to, like a full page refresh might in that case, if it's a deep session, that might be a bad experience. Right. So we can, we can characterize the cost of that experience. So a full page reload, maybe significantly more expensive, right, in terms of latency, perceived latency, or in terms of total network costs, because we have to like generate a lot more stuff maybe. And so doing a smaller delta might be a more expensive. more efficient. OK, great. And now there's another constraint of maybe we want the same programming model

 

Charles_Wood:

Thank you.

 

Alex_Russell:

through

 

Charles_Wood:

Thank you.

 

Alex_Russell:

time. OK, so then what are the ways that we can get that? Well, we can do servers. Like if the data model resides only on the server side, then we can think about how we can get partial updates back to the client so that we don't have to do that full page refresh. If we want to split the data model of the client, now we're talking about escalating client-side complexity and costs. we have a budget, hopefully, that falls out of that earlier decision matrix about what we can afford. So could we afford to do the legacy framework, like the React style loading of the entire tree of rendered content as a parallel JSON structure and then double it up again in order to demo it as a second virtual DOM tree? Right? Like, do those costs make sense? Does pulling all the componentry down the wire make sense? These are questions that we can evaluate more objectively from the frame of reference of wanting to ensure that our end-to-end latency is low. Now, optimistic commit for clicking a tweet with the same tools that you use on the server as on the client is interesting, but a real engineering organization is not going to be taking that as a shibboleth. That's not how we talk about engineering trade-offs. It's like, OK, do we have the skills necessary to handle differences between those two things on the server and the client? Is that a trade-off worth making? What is the latency impact? And should we just decide to pay it for the future? So we would have, I think, a richer conversation if we didn't take as rote this kind of working backwards from the presumed solution to a single answer that is kind of preordained. We would have a more, we would be less the JavaScript and more the web development community that I think the JavaScript community kind of needs to upgrade itself into. And so, I think that's a great question.

 

Dan_Shappir:

In that context, you know, there seems to be people out there trying to solve this conundrum that you're describing, but without like giving up on the way in which the community has decided, the path the community has decided to take over the past decade or so, but instead by to address the problem from the framework perspective. So I'm thinking about like Chuck at the beginning mentioned, we had Mishko, for example, on our show. And you have quick as an example of a framework built in JavaScript using very much a lot of the same mental models and approaches that are used in React, but trying to do it in a way that... can theoretically support those users and use cases that you were initially discussing. So what do you think of that approach?

 

Alex_Russell:

I mean, I think it's important for all of us to, and it will be a big change, but I think it's important for all of us to treat the world as it is, not as we wish it to be. And so there is a lot of React centric content in the world, a lot of React centric teams, a lot of folks who are going to be looking for a path out of the wilderness. And I'm excited about some of these paths, right? If you look at what remix sends down the wire, and this walks back to what is the technical thing we can afford. What we want to get to is a lower baseline cost so that when we decide to put our specialized content into the remaining budget, there's more room for our stuff rather than the framework. So one of the good things about pushing costs down in the framework output, the default framework output, is that it creates a larger space for us. It creates space for us to be fallible. We're not perfect. I've never made a perfect web page. I will never make a perfect web page. I don't expect anyone else to. We're all going to screw stuff up. That's just how it goes. So how much space is there for us to screw stuff up? How close to the edge are we running at every moment? And the objectionable thing about the way we have constructed things for the last decade or so has been that we have assumed that CPUs were getting faster and that networks are going to save us because they're going to be really great. And there was all of this latent compute power that we get and memory that we could throw at the question of how to manage pieces of complex life cycle And none of that panned out. So like it just hasn't been true. So those now that we've invalidated those Extremely wrong and continuously falsified assumptions, right? Like they're not true. They haven't been true for a decade They're still not true. They're not going to become true next year, right? Like because the devices haven't cycled out the networks haven't upgraded, right? All of those things are not true true, they're still not true. So now that we've gotten rid of the falsehoods from the kind of conversation, we can start to reset and go, OK, we've got this pile of stuff. How are we going to fix it? And so we can drive the framework cost down to zero with a cauterization or a tourniquet. We can do kind of what remix is done, where they say, OK, we're going to take what you've got, and we're going to reinterpret it so that we're going to extract most of those costs, going to put a sieve in front of your React. And then there are this other track, path, the road not taken, the tools and frameworks that have, at their own detriment, marketed something other than developer heroics. If you think of the phrase SPA, not as standing for single page application, but as slow page apologetics,

 

Dan_Shappir:

Ha ha 

Alex_Russell:

I think you'll

 

Charles_Wood:

Oh

 

Alex_Russell:

You'll

 

Charles_Wood:

Oh

 

Alex_Russell:

get a better view onto how we spent the last decade.

 

Aj:

Shot's

 

Alex_Russell:

Like we spent

 

Aj:

fine.

 

Alex_Russell:

the last decade apologizing and then retelling the same wrong story about how CPUs and networks were fast now. It's not been true. It just hasn't been true. It still isn't true. So if we take that out of the conversation and say, what is my actual user journey? What does it look like? How many tabs are there? What's the depth of that session? Then we can start to think about, knew what stacks would I pick. Which stacks fit under my budget. And so when I see Mishko make the turn, you know, like he got some extremely direct feedback from me back at Google. Like their team, I'm an equal opportunity

 

Aj:

Equal opportunity offender. That's

 

Alex_Russell:

trace

 

Aj:

me.

 

Alex_Russell:

taker.

 

Aj:

That's me.

 

Alex_Russell:

I don't mean to offend. I do want to distribute evidence. I think it's important for us to be grounded in evidence. And our community has decided that for a long time, and decided that that wasn't where we were going. I'd like us to return there. But as we return there, seeing Mishko kind of take on board the critique that was uncomfortable for a long time and really make a turn, you can see what these incredibly intelligent, extremely talented people do when the constraints are reset that those results are significantly better. So when I look at Astro, I look at Quick, I look at Svelte and Sapper, I look at the Preact team, or any of the web components frameworks that have been doing this kind of great stuff. And now that they're kind of like getting into SSR with the Claritive Shadow DOM, the Lits and the Fasts and those folks. I am absolutely, I mean, even Vue has done a pretty good job of whatever the technology underneath it, better story about why we're here and who we're here for. Because as professional people making web pages on the internet, we're not making them for us. Like we're weird. Like we have to acknowledge that like we're wealthy, we have good devices and networks, we use maybe different services, we use them differently. And so as professionals, we're not here to make stuff for us. We're not hobbyists in our day jobs. We're trying to serve other people and serve them well. In the spirit of doing a good job of that service, I think about not just the technology changing as these folks have made a turn towards other stuff, but the narrative changing. Trickle down, DX doesn't work. The Laffer curve is bullshit, and the Laffer curve for front end is also bullshit. And it's now entirely falsified. None of this works.

 

Dan_Shappir:

I think we're using the terms UX versus DX as a justification for a lot of the decisions, but realistically, I don't actually think the DX has improved that much. I mean, in a lot of ways, we are building incredibly

 

Alex_Russell:

Hahaha.

 

Dan_Shappir:

complex, I'm glad I'm using you, we're building incredibly

 

Charles_Wood:

Ha ha!

 

Dan_Shappir:

complex systems. repeatedly see developers who are way out of their depth when they're trying to deal with the details of modern frameworks and we keep on throwing more complexity at it. So for example you know I'm looking at at a lot of the meta framework providers promoting edge computing as a means of addressing a where in reality, first of all, it's throwing a lot more complexity into the mix because edge is not the front end and it's not the back end. It's yet another level that you would need to support. And it's also adding cost because most of them are promoting edge because it's a way for them to make more money. But at the end of the day, it's not about improving UAC. and it's not really about improving DX. I think it's more about the perception of higher ability. I think maybe. Like if I know React, then I can get, then I can, if I say, if I can say that I know React, then I'm more likely to get a job or something along these lines.

 

Alex_Russell:

Yeah, this brings us full circle to the failure of the management class today. The people who are paying for front end experiences are buying bad stuff. Now, I wrote a whole post this past weekend. It's maybe a little bit too spicy for this group. You know, referring to George Akoloff's most famous paper called The Market for Lemons. And the TLDR is, you know, there's a... This was based in the 70s on the idea the used car sales market where it's very hard for a potential buyer to know whether or not there's a defect in a used car. And so the price for used cars was frequently wrong because of hidden defects. And it makes less sense for someone to sell on a high quality thing because they're not going to get what they would actually require for it because it's going to be mispriced. And so what happens is... that in that market, the market for lemons, because of low information, information asymmetry on the part of the buyers versus the sellers, it's extremely hard for people to judge whether or not they're going to get a quality product on the other side. Like, if you don't know that the contract you put up was going to mostly get you clowns laying the bricks, then you might be surprising on the other side, maybe unhappily. But if you can't predict when that's going to but then it always turns out bad, you're gonna stop buying walls. So I think this is actually where we get to the TLDR for me, which is if we keep going down this path, there is no such thing as a requirement that businesses continue to buy webpages. Right? Like, there doesn't have to be a future for us if we keep screwing it up this badly. It's not preordained. There's no Uh... there's no imperative that people continue to make new web stuff. And so one of the outcomes of the Market for Lemons paper is that the market, in addition to getting worse, like the contents of it getting worse, which we have definitely seen in our end of the world for the last decade, the market itself shrinks. There's less demand overall for these products because when they're bad and they're consistently bad and they're unknowably bad, people just kind of don't want them. So when bad experiences you know, put a little bit more prosaically. When bad experiences are the norm, why would you buy one? Why wouldn't you go make a native app? Why wouldn't you go try some other way to deliver? Why wouldn't you just go like, give all your content to Facebook or like push it out through RSS or something else? Like why would you make web stuff? There's no... There's no preordained market for a front end. It is what we make it. And if we keep making it poorly, we're not gonna have much of it. So I would encourage folks to think

 

Aj:

Bye.

 

Alex_Russell:

hard about how doing a good job for users is doing a good job for yourself in the future. I'm gonna go ahead and do a little bit of this.

 

Dan_Shappir:

I think

 

Aj:

I- I-

 

Dan_Shappir:

I'll go for it, AJ.

 

Charles_Wood:

We do need to wrap

 

Aj:

I

 

Charles_Wood:

up

 

Aj:

just

 

Charles_Wood:

soon.

 

Aj:

feel like this is an argument that's dead in the water because I feel you, right? You're making the points that I want to make, except you've got way more research to back it up and that is so awesome. But the idea that because something is bad and has a detriment that it's going to go out of fashion.

 

Alex_Russell:

Oh, I can tell you for, I'll drop a link to a talk I gave back in 2019. The data that we were seeing inside the Chrome team about the use of the web on Android falling off a cliff is everything you need to know about how badly it's going. People don't want the web because it sucks,

 

Aj:

Okay, okay,

 

Alex_Russell:

right,

 

Aj:

so you're

 

Alex_Russell:

for them.

 

Aj:

saying that apps, now I could see a future in which, because most people don't have computers today, it seems. From my

 

Alex_Russell:

Uhhh

 

Aj:

observation, outside of programmers, people don't have

 

Alex_Russell:

Oh, you

 

Aj:

a computer

 

Alex_Russell:

mean desktop

 

Aj:

in

 

Alex_Russell:

computers?

 

Aj:

the home.

 

Alex_Russell:

You mean desktop computers, yeah. They all have phones, yeah, that's right. Yeah. 

 

Aj:

Yeah,

 

Alex_Russell:

Yeah. Yeah. Yeah. Yeah.

 

Aj:

yeah.

 

Alex_Russell:

Yeah. 

 

Aj:

And

 

Alex_Russell:

Yeah.

 

Aj:

so

 

Alex_Russell:

Yeah. Yeah. Yeah.

 

Aj:

in

 

Alex_Russell:

Yeah.

 

Aj:

the app experience is, is it's not just that it's often a better experience for the user. It allows them to pry into the person's life, have registered hooks that fire every hour to remind them to do something that, you know, tracks where their location is. It gives them complete. It's like, it's like you get to be in their bedroom, you know.

 

Dan_Shappir:

Thank you.

 

Alex_Russell:

But those are also downsides, right? From an end user's perspective, right? The total invasion of privacy is not great. So there should be a vibrant market for the web to compete for that business. So that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's

 

Dan_Shappir:

And

 

Alex_Russell:

a good point.

 

Dan_Shappir:

I

 

Alex_Russell:

I

 

Dan_Shappir:

think

 

Alex_Russell:

think that's a good point.

 

Dan_Shappir:

that there is, because luckily for the web, the app store experience is just so bad. I mean, there's a reason that most people have like what, seven apps installed on their phone, and that's more or less it. I mean, if I'm going to do some, you know, if I'm going to look to buy some clothes online, I won't install an app for that. used by the fact that I walk into some store, some physical store, and they try to convince me to install their app, and I'm going like, yeah, right, I'll install your app.

 

Alex_Russell:

Yeah, there's hope. We have advantages, right? We can be in the hunt, but not if the idea of buying a web experience is just going to reliably end up in a terrible time for the user. That's just not going to be the way that we win. So I'm going to go ahead and do a quick demo. I'm going to go ahead and do a quick demo. I'm going to go ahead and do a quick demo. I'm going to go ahead and do a quick demo. I'm going to go ahead and do a quick demo. I'm going to go ahead and do a quick demo. I'm going to go ahead and do

 

Charles_Wood:

Alright.

 

Alex_Russell:

a quick demo. I'm going to go ahead and do a quick demo.

 

Charles_Wood:

I'm gonna wrap us up, because at this point, I've gotta go, I know, I've seen in the chat a couple other people saying that they've gotta go soon. But I think the point is well made. I think there's more debate to be had. I'd love to dive a little deeper on this, maybe at a different venue or... I think that's a good point. I think that's a good point. I think that's a good point. I think that's

 

Aj:

and the

 

Charles_Wood:

a good

 

Aj:

solution.

 

Charles_Wood:

point. I think that's a good point.

 

Aj:

I want

 

Charles_Wood:

But.

 

Aj:

to hear the solution. We need a part two for what do you do about it? We can complain about it, but what do you do about it?

 

Alex_Russell:

Sure, sure. I'd be happy

 

Charles_Wood:

Yeah.

 

Alex_Russell:

to come back and talk you through how we can do that.

 

Charles_Wood:

Yeah, let's do that. In the meantime, though, we're going to wrap up. We're going to quickly do and keep it short. The self promo segment and then we'll do the picks. Dan, what are you working on that people should know about?

 

Dan_Shappir:

Nothing much to be honest, nothing beyond what I've said on previous shows. I'm mostly working at the, you know, working on my day job at the company where I'm at. And that's mostly on,

 

Charles_Wood:

Right.

 

Dan_Shappir:

and, and, and, and to be honest though, there are a lot of aspects to my day job that kind of echo a lot of what we were talking about today. And, you know, how, you know, fighting the good fight against certain technical decisions that were made. years ago, mostly involving SPAs, which are resulting in suboptimal performance.

 

Charles_Wood:

All right, AJ, what are you working on? other than the mute

 

Alex_Russell:

unmuting

 

Charles_Wood:

button.

 

Dan_Shappir:

Thank you.

 

Alex_Russell:

himself.

 

Dan_Shappir:

Bye.

 

Aj:

Well, let me unmute there. So with Dash Incubator, I am working on a wallet, a cryptocurrency wallet that is very in the vein of what crypto nerds would hate, but what the average person might be able to stand using. But I don't really have anything to link anybody to about that yet, but I've been rewriting a whole ton of blockchain transaction and HD wallet And basically the entire stack of tools that are needed for a cryptocurrency wallet, I have either rewritten from scratch, heavily refactored from someone else's code, or curated a very select module from someone who's written very clean, very minimal, very modern code that doesn't rely on shims and hacks and, you know, that uses BigInt and that uses web all those sorts of things so that it's actually a nice experience for the developer as well as a better experience for the end user not having to download six megabytes of transpiled C++ and whatnot.

 

Charles_Wood:

Cool? Steve! What are you working on?

 

Steve:

Nothing to share with the outside world, just sort of internal app using one of my favorite current stacks right now, UJS, InertiaJS, and Laravel, PHP on the backend, sorry, AJ. So yeah, it's pretty cool. It's a learning experience, it's a neat stack for sure. And so, yeah, I think that's pretty cool. I think that's pretty cool. I think that's pretty cool. I think that's pretty cool. I think that's pretty cool. I think that's pretty cool.

 

Charles_Wood:

Yeah, I know a lot of people that like Larivell. I am working on launching and continuing to launch Catapult Your Coding Career. I think it's self-explanatory other than saying it's a podcast. So go listen to it. I will probably start adding some of those episodes to this feed just so that you can kind of get a feel for whether or not you want to listen to it. And then I'm also launching another podcast that's going to be the Developer's Toolbox. And that's going to be interviews people who are making tools that you use on a day-to-day basis. And yeah, more to come there. Alex, what are you working on these days?

 

Alex_Russell:

Well, I spend about half my time with teams inside of Microsoft trying to make our web apps better and faster. So if you hear primal screams from this side of the world, that's probably where that's coming from.

 

Charles_Wood:

Nice.

 

Alex_Russell:

We have every React order. I will say outside of that, I think it's really important what this group of open source and sort of advocates are doing around browser competition on mobile. They've organized under the banner open with advocacy. You can find them at their website, open-web-advocacy.org. I know that they're about to start a fundraising drive to support this work. And it's extremely, I just cannot stress enough how much impact this group, this Mary Band of fellow travelers have had over the last two years. They are a key reason why the European Union's DMA may finally force browser competition on iOS next year. They have done so much incredible work, working closely with regulators in their spare time. They are not funded, they are not associated with some big company. This is all volunteer and they are doing the Deities work. So check them out and as they open up their pitch for fundraising, if you can support them financially, please join me in doing that. And that's it for today. I hope you enjoyed this video. I hope you enjoyed it. I'll see you in the next video.

 

Charles_Wood:

Awesome. All right, well, we'll take that as a pick and move into picks. Dan, what are your picks? I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks. I'm gonna pick a couple of picks.

 

Dan_Shappir:

So my first pick is actually, so it's funny. I ran a poll, it's more of an observation, I guess, in an actual pick. So I ran a poll and I'm gonna make a jab at Steve, because Steve likes to say that we should always use the best tools for the job, to which I tend to respond and it kind of falls into the conversation we've had today that yes, but practically we use the same tool for every job as long as they can somehow get the job done. And I basically asked in the poll who people side with, do they side with Steve as in they pick the best tool for the job? Do they side with me in the sense that they are, they likely use the same tool for everything? Or do they think that we both are correct or that neither of us are correct, which is kind of amusing. and it turns out that I beat Steve 4-1 so yeah that's the way it is and it kind of as I said it kind of matches what we've been discussing it today that people basically use React for everything whether it's right or wrong you know in terms of the end result.

 

Steve:

Well, I think that pole could have had a little better phrasing maybe

 

Dan_Shappir:

Of course, but it was

 

Steve:

and

 

Dan_Shappir:

my poll.

 

Charles_Wood:

Ha ha

 

Aj:

I...

 

Charles_Wood:

ha ha!

 

Steve:

split it between what you'd like to do versus what you really have the bandwidth to do.

 

Dan_Shappir:

Oh, for sure. And you're more than welcome to run your own poll and beat me at it.

 

Steve:

Okay, as long as you retweet it, you have more followers than I do probably.

 

Dan_Shappir:

I promise

 

Charles_Wood:

Yeah.

 

Dan_Shappir:

to retweet it if you run that poll.

 

Steve:

Thank you. Bye.

 

Dan_Shappir:

Anyway, so that would be my first pick and my second pick would be the pomelo fruit. I don't know how familiar you guys are with it. It's the season, at least here in Israel. I love it. It's amazing. It's sweet and it's tangy. And, you know, it's, I guess it's also called citrus maxima. It's like, you know, because it's kind of big. And, And I, you know, I literally eat some every day and it's just great. I hope the season lasts as long as possible. So that would be my second pick. And my third pick is that same pick that I pick at Ancient Every Time, the ongoing war on Ukraine. You know, whatever anybody can do to help the people of Ukraine, please do. And that's, those are my picks for today.

 

Charles_Wood:

Awesome. Steve, what are your picks?

 

Steve:

All right, I'll keep it short and keep it to the high point, the dad jokes of the week. First one has quite an interesting story though. So as it goes, I ordered a deck of cards from Amazon. And two weeks later, it hadn't arrived. I called customer service and they said they're dealing with it. I called customer service and they said they're dealing with it. I called customer service and they said they're dealing with it. I called customer service and they said they're dealing with it. I called customer service and they said they're dealing with it. Now, the funny part of this is that I got an actual response from Amazon from that tweet. They said, if you follow me on Twitter, you can see it. And they said, we're sorry for the wait to clarify, have we missed the expected delivery date given in your order confirmation email? You can find this email in your Amazon message center. So I had to reply to the gal, her name was Christie, and tell her, sorry, this was actually a dad joke, I wasn't being serious. So they appreciated that. But that was, that was funny. That tells me how much they're scanning Twitter. And then I asked, I asked a librarian if she had a book about Pavlog's dog and Shroedringer's cat. She said it rang a bell but she wasn't sure if it was there or not. And I had to go look up Schrodinger's cat on that one. I wasn't even sure about it. I'd seen the name all the time, but I didn't know it off the top of my head or off hand either. And then finally, my boss the other day asked me, why do you only get sick on weekdays? I said, it must be my weekend immune system. For those not

 

Dan_Shappir:

I

 

Steve:

watching

 

Dan_Shappir:

like

 

Charles_Wood:

All right.

 

Dan_Shappir:

that one.

 

Steve:

on video,

 

Dan_Shappir:

I like that.

 

Steve:

Alex is really shaking his head

 

Dan_Shappir:

No,

 

Steve:

here,

 

Dan_Shappir:

I like

 

Steve:

groaning.

 

Dan_Shappir:

that one.

 

Steve:

That's all

 

Charles_Wood:

All

 

Steve:

I have.

 

Charles_Wood:

right, AJ, picks.

 

Aj:

So I've got one really important one, which is I'm gonna pick Vemail. And I'm not gonna pick Vemail because it's great, which it is. I'm gonna pick Vemail because the maintainer did something incredibly stupid. In a minor release, he made an update that basically Vemail is an asynchronous tool. So it'll run the linter not on save, but while you're typing. And it made this feature show up in line with the code rather than just down at the bottom. And that so if you open up a new bracket, it'll show 100 error messages because if you open up a new bracket and there's not a closing bracket, then then every single line is an error and it makes it completely unreadable, completely unusable in version 3.3, which I accidentally updated to. And so I open up an issue opening up issues or start commenting on that issue pretty much immediately. And the author is just defending himself and, you know, he's insulting his users and asserting that, well, it's a good feature and people won't know about it unless it's on by default. So it's it's better for them to have it on by default and complain about it. They're not know it's there and, you know, yada, yada. But so we did a little bit of. who's is bigger and back and forth. And at the end of it, he just said, well, it's the option and I'm sticking with it. And I just appreciate that we were able to be able to be rude to each other and quote unquote toxic. And that we were able to have a real conversation, that we were actually able to have a real conversation and it's not like, oh, you've offended me, I'm going to block you. Oh, you don't come to my project anymore. You know, it just, it was so nice to be able to get into an argument and to just handle it like men for once and let it be. So I've had three arguments online in the past week. One of them ended in the person telling me that I wasn't creating an emotionally safe space for them and blocking me. And the other one actually went kind of well too. But it's just, it's just, it's so nice. when people can accept criticism and respond in kind if that's what they feel they need to do and not have to have it be a, well, I need to call the police because I don't like your opinion. You know, it's just, and so I picked that author because he handled the situation well and he believes in his point and he stuck to it even though he's wrong and I respect him for that.

 

Charles_Wood:

All right, so we're doing picks and rants.

 

Dan_Shappir:

Before we continue, if I can make just a really quick observation, because it happened, obviously I'm also on Twitter as we speak. And earlier today, I tweeted the things I like about React, because believe it or not, there are actually quite a number of things that I really like about React. And somebody replied to my tweet with, I like the fact that it's easy to learn. If you know JS, you can start with React pretty quickly, to which I couldn't help but respond If learning React is so easy, let's see you name all the built-in hooks in React and their purpose.

 

Charles_Wood:

Oof. Oof.

 

Dan_Shappir:

And then I also put, I don't remember those either, so it's not as if I'm better than he is, because I'm not.

 

Aj:

That was the sort of tweet that got me the person say that I made them

 

Dan_Shappir:

No,

 

Aj:

feel emotionally unsafe. It was very similar to that.

 

Dan_Shappir:

yeah, but that's why I included in my response that I don't remember it either because I'm really not attacking them or trying to prove them as unknowledgeable in React. I'm making the point that React is definitely not as easy as a lot of people like to make it out to be. And then a lot of people then are kind of struggling with the fact that if React supposed to be so easy, why am I finding it so challenging? Anyway.

 

Charles_Wood:

Right. All right, well.

 

Alex_Russell:

And more to the point, if you've hired a whole set of people who specialize in this extremely complex tool, why don't you believe that they can retrain onto something else? They mastered this extremely complicated thing. They're clearly smart enough to do whatever. You can make whatever choices you want. You're not a hostage. Sorry.

 

Charles_Wood:

Nope, all good. All right, I'm gonna jump in with my picks. I do a board game pick every time. This one I'm gonna pick Harry Potter Death Eaters Rising. Came out in 2019, two to four players. It is Harry Potter themed obviously, and I'm not gonna go into all the details of how it is played, but it is a little bit more complicated game. Board game geek waits it at 2.31. My wife and I have really enjoyed it, but the first few times we played it, we just couldn't win it. And then after after that what we figured out is that we just needed to stay on top of Healing and removing corruption from locations and things like that And we had to make sure that we didn't allow too many death eaters to get Out there and be hurting us on a regular basis and then we were able to actually win it So that's just some advice if you're trying to win this game and you have Struggled right some of the games you can kind of take a chance with stuff and away with it and this one is a little less forgiving that way. You can still do it sometimes, but some of those times we've taken those chances and either lost or really had to fight to come back from it. It also looks like though that there's another game that is more or less the same and that is Thanos Rising, Avengers Infinity War. I do not have this game, but yeah, it says it's a an avatar one, but they all kind of follow the same structure. So if Harry Potter's not your thing, it looks like there are others. Yeah. Avatar last to airbender Fire Nation Rising, that's 2022, that came out last year. The Batman who laughs rising, SpongeBob SquarePants, Plankton Rising, and Star Wars Dark Side Rising. So yeah, if Harry Potter's not your gig, you can find another one that plays kind of the same. I'm gonna do a quick shout out for a couple of other resources. One of them, I just joined this group and it's been terrific just to kind of get the feedback on things that I'm working on to run a podcast business. It's called Aratase Syndicate. It's run by Andy Frazella and Ed Milet and they do a call every few weeks and, you know, kind of break down business and discipline topics. And then there are a whole bunch of people. in there that are all pulling for use to succeed and that you help other people succeed. So it's kind of an online mastermind-ish without the mastermind call and I've gotten a ton out of it. So I'm going to pick that as well. Alex, what are your picks?

 

Alex_Russell:

I feel like I'd be double dipping if I

 

Charles_Wood:

No, go

 

Alex_Russell:

was

 

Charles_Wood:

ahead.

 

Alex_Russell:

to recommend anything. In the same vein as maybe what we were just discussing, I can commend Andy Bell's recent blog post about Task for Who, talking about the kinds of trade-offs that we as a community have been making, you know, for our own benefit, maybe to the exclusion of benefits for our users and customers.

 

Charles_Wood:

Awesome. Alright, one last question. If people want to follow you online and they're not doing that yet, where do they find you?

 

Alex_Russell:

I'm on Mastodon. I am at SlightlyOff at Toot.cafe. And my webpage as ever is at infrequently.org and you can find links to reach me there.

 

Charles_Wood:

All right, good deal. Well, thanks for coming. This was really, really fascinating. And until next time, folks, Max out.

 

Dan_Shappir:

Bye!

 

Steve:

Adios.