Hello, another Svelte Radio episode.

Today, we're back once again and we have a guest today.

It's Rich Harris. Welcome.

Hi.

And of course, all of the hosts are here.

Hello.

Hey.

So, today we're going to talk about a controversial topic.

Maybe a controversial topic.

A bit controversial.

We'll see.

I mean, there definitely has been controversy.

But I think the controversy is going to be short lived.

All right.

So, we're going to talk about the new routing changes, basically,

that are coming to Svelte Kit pretty soon, I guess.

So, I guess we can start off with what have you guys been doing

before we actually start with the actual meat of the podcast?

What have you guys been up to?

Status update.

Yeah.

Well, I can start with this one then.

So, yeah, a child has appeared.

So that's what I've been doing.

Congrats.

Congratulations.

Thank you.

Were you just walking around in the grass?

It's not how it works, Sean.

It's not how it works.

I don't know.

There's something involving a story.

You announced...

Yeah, a story.

You announced, like, a Pokémon.

Yeah.

A wild child appeared.

Well, it is weird because, yeah, because, you know,

I guess all the stuff, all looking after it and all the waking up

and, you know, all this kind of stuff.

And this whole new life change thing does make it almost like a blur.

People keep telling me it's like a blur, but it really is.

It's like, where are the last...

I think it's been nearly seven weeks now.

So where are the last seven weeks gone?

And since you're pretty much tired all the time,

which is apparently akin to being kind of half drunk all the time.

How people could drive, I don't know.

That's crazy.

But since I'm also half drunk all the time, that's being fully drunk all the time,

which is not as good as it sounds.

But yeah, so essentially, yeah, it's an interesting thing.

It's very exciting.

It's very frustrating at times.

It's very... It's everything.

Like, it's great.

I mean, I'm enjoying it despite everything else.

You know, it's wonderful, but it has definitely reduced my ability

to actually do real work and podcasts.

So good to be back.

Racing a baby is real work.

That is real work.

It is real, real work.

It's a different kind of work.

It's real, real work. Yeah.

It does get easier, I promise.

Yes. Also being told that was just a relief.

So I actually visited Antony's place and we had a very nice lunch.

And I have an incriminating photo of Antony drinking a beer

while holding a baby in the other hand.

Yes, indeed.

And I have lots of photos of Sean holding the baby and holding my cats as well.

At the same time?

No, not at the same time.

That is more than anyone can handle.

Is that incriminating too?

So are you going to hold the shot?

Not really.

No, I think that's a... That's good dating profile photo.

Yeah.

There you go.

All right.

I have spent the week learning Remix,

which is kind of interesting to come into this topic today.

Oh yeah.

Anthony just like pushed away from me.

He said you were going to be controversial though.

No. Yeah, exactly.

Being controversial.

I feel like this topic... Keep your enemies close.

Right?

And I mean, that's part of the job, right?

I have to learn lots of new tech and it drives this conversation about nested routing.

So I'm kind of interested to hear what's going on today.

Cool, cool.

Yeah, I've just moved this weekend, which is why I'm in a new place.

And it's a total chaos.

Been assembling like a flat pack bed thing.

It's the worst thing I've done in a long while.

I'm never going to do it again.

That's pretty much me.

So Rich, you were last on this spring, I think, maybe back in March or something, maybe May.

I don't remember exactly.

Possibly.

What have you been up to?

I mean, the last couple of weeks, I have just been working on SvelteKit.

My updates are so much less interesting than everyone else's because it's a more than full-time job at the moment.

But it's the best kind of full-time job.

It's the kind where you're really energized.

Like I get out of bed and I immediately want to start working.

And then I kind of don't want to stop for meals, but that's not healthy or sustainable.

So I'm going to stop doing that as soon as we implement these drastic changes that we're going to talk about today.

Yeah, someone posted some of your git commit messages and it's pretty funny.

Some of them over the last couple of days have just been more, more, more, more, more, just over and over again.

And then there was one about ESLint being a fun sucker and Safari, hating Safari as much as the fire of a thousand suns.

Safari needs to die, man.

It's so bad.

This, like, people always complain about Safari and I get it, there's like features that it's missing and stuff.

But what I think is so often missing from the conversations about Safari and how it's like the last bastion that's preventing us from a Chrome monoculture is that it has the most weird, obscure bugs.

Like every project I have ever worked on, I have uncovered a new, completely insane bug.

And it's always like on deadline, so I don't have time to like file like a bug report with WebKit and all of that stuff.

But every time it just leaves me going, how?

How could you build software this way?

It makes no sense.

And, you know, the WebKit engineers are all like clearly brilliant people who are severely under-resourced.

But I feel like we don't talk enough about how that it's not just that it's missing features, it's that it is just an absolute rat's nest of random bugs.

And as someone who is not just a web developer, but someone who builds tools for web developers, I feel like I have an above average exposure to these and it just drives me absolutely insane.

Kevin, is your hot take going to be that you love, yeah, your unpopular opinion is going to be that you love Safari?

Absolutely.

Healthy diversity of opinions.

My note on the obscure bugs is that the unobscure bugs are even worse.

For instance, I think it was the date picker hadn't worked since 2013.

I think they've now fixed that.

But that's about the time I found that.

See, timely fix.

Eight years without a date picker.

I mean, that's pretty bad.

I think Jim Simmons is doing a good job with the CSS stuff, at least trying to get it caught up.

The data points, the data point I have about WebKit versus Chrome is that Chrome has a thousand engineers working on Chrome and WebKit has 30.

So, yeah.

That does explain a lot.

You can individually work very, very hard, but as a whole, there's a lot to cover.

Both of those numbers are stupid.

In different directions, they are both stupid numbers.

Well, how many people should work on a browser?

I mean, I don't know.

It's definitely between those two.

It's kind of hard to coordinate a thousand developers on a single project, right?

It doesn't make it go faster.

You're trying to work on different pieces of it and then put it back together.

Yeah.

Yeah.

It is what it is, I guess.

Meanwhile, poor Firefox.

I'm a Firefox guy.

That's my daily driver.

I do, too.

How many engineers are working on Firefox still?

Did you guys see the...

Did you see the hacker news today or yesterday about some large bank that was just going to straight up stop supporting Firefox for some weird reason?

And they were actually going out of their way of actually detecting Firefox and telling the user, oh, please use another browser.

A lot of these video things that we use for podcasting don't like Firefox.

I actually have to open Chrome to use things like StreamYard.

I've been using it for a while, but I feel like remotely, one of the other ones that I've used recently has not supported Firefox.

It tells you you can't do it.

Oh, ping, ping.gg.

Theo's new project.

I have no idea what that is.

It's a company.

It's not just a project.

That's his thing.

Sean knows what I'm talking about.

Yeah.

Cool.

What about this routing thing?

What's up with that?

So I guess the backstory here is the Svelte kit was a redo of Sapper, its predecessor.

And we got rid of a lot of the like the cruftier bits, like there's no more rollup and web packets or V under the hood, like shiny and modern.

And we took the opportunity to fix up a few other things.

But we inherited a lot of the design baggage from Sapper.

And so, for example, the way that the file system based routing works is inherited directly from Sapper.

If you have in your source slash routes folder, a file called about.svelte, that will create the slash about route.

Which like seems very straightforward on the surface.

But that one decision turns out to have some very far reaching ramifications on the design.

Because if you want something under that route, then you have to create a directory.

And then you can have the about.svelte or you can have the about slash index.svelte.

You can't have both.

But either one of those is equally valid.

But you probably don't want to have the about.svelte and then have child routes inside the about directory.

And so all of this stuff starts to get like immediately this from this very obvious starting point, you've immediately got some ambiguity.

And as we've been working on SvelteKit, we have found that design feature to have cascading ramifications.

And so recently...

Is there a reason you can't have both?

Because that is the way Remix does it, is you have like an about.tsx or jsx and then you have a directory with index.

Well, no, it's not.

In Remix, the way that they do it is they have about.js or jsx or tsx or whatever.

And that is the layout for all of the about routes, unless there isn't a directory.

But then if you do have a directory, then you also have to have the about slash index.svelte.

And that to me is the worst of all worlds because now you've got the directory and you have to have the top level file as well.

So for each of your routes that have children, you're doubling up the number of items in your directory.

And it's also just kind of not clear when you're inside the directory that there's this layout being applied and stuff.

And I've looked at like all of the different versions of file system based routing to see which bits are worth stealing.

And I'm pretty confident that that is not an idea that we would want to steal.

The one that we have stolen to a large extent is the Next.js layouts RFC.

The next version of Next is going to have basically that it's designed to enable nested layouts,

the same that Sapper had years ago and the same thing that Remix had when it came out.

Next is going to have that in a future version.

But the way that they've done that, the way that they have gone about redesigning their file system based routing is they have a directory per route.

So you can no longer define a route with a file alone. It has to have a directory.

And because of that, everything instantly becomes so much more predictable and stable.

And so you have your page.js inside the directory route and then you have a layout.js inside the directory route and everything proceeds from there.

They also have loading.js so that you get like instant skeleton screens while your data is being fetched and stuff like that.

We don't have that equivalent yet.

But I read that RFC and some of the parts that haven't yet been published publicly and I read it and I thought,

this is fucking brilliant. I'm going to steal this.

And so I put something on GitHub discussions a while back that took elements of that design and adapted it for Svelte.

And the reaction was very split.

A lot of people didn't quite understand the benefits of the approach.

And that's fair because a lot of the benefits are the kinds of things that you don't experience immediately when you become a SvelteKit developer from that previous discussion.

But at the same time, we were starting to get issues in the repo about the way that load works.

The way that data fetching works in SvelteKit is historically we had this load function and any page or layout component has a load function that is responsible for getting data for that page.

And it works, but it's always been a little bit clunky, a little bit boiler platey because you have to put it in a script context equals module because it doesn't belong to the code itself, the component itself.

Inside there, you've got to have your function. Inside there, you return an object which, among other things, returns the props.

And so you're already like four levels of indentation deep before you actually start returning your data.

And there's so much boiler plate either side of that that it's just a very inelegant way to do things.

And the way that errors are handled is very inconsistent between apps.

And so we added what we called for a while page endpoints, which is a separate file, a separate page.js file or index.js file, which runs on the server, always runs on the server and sends data to the client.

And that's great. That handles like 90% of your data fetching needs.

But we also still have this other thing, this load function.

And we were starting to get issues around some of the complexities of that because that function, that load function is doing so much work that it's unnecessarily complex.

And a lot of the issues were the kind of things that we could have fixed with some incremental design, a little bit of engineering work.

We could have closed those issues, but to me, they were all starting to point to a more fundamental flaw in the design that we had inherited from SAPA, essentially.

And so a couple of weeks ago, Simon, who now works alongside me at Vercel, kind of said, I'm looking at some of these issues that we've tagged as being related to this topic.

And I'm starting to think about like, is there a way that like, is there something that needs to be done here?

And we started brainstorming.

What if we had started with page endpoints and then we added the load functionality after that, we would probably end up with a very different design.

And so we bagged some ideas around and we did a bunch of research into how other systems operate.

Like Simon drew this very complex whimsical chart of like what Nuxt and Remix and Next and everyone else does.

And that was it.

The dam had kind of broken and came up with a discussion and we battered it around internally for a while.

The maintainers took pot shots at it.

We refined it and then put it up publicly last week.

Expected it to get some reaction, but all hell broke loose.

Yeah. And do you think it has to do with the syntax change?

Can we talk a little bit about why that's happening and what the reasoning behind that is?

We can. So I mean, so when I say that all hell broke loose, I should clarify what I mean by that.

This was on the whole a very well received proposal.

The emoji reactions were overwhelmingly positive.

We got loads of great feedback on Reddit and Twitter and on the discussion itself.

But there was obviously some some dissension.

Just the sheer scale of the feedback.

In about 12 hours after we posted it, we had hundreds of comments on this discussion.

I remember when the Next.js layouts RFC went public.

I was looking at it and I was thinking, man, I'm so glad I'm not on the next team.

Because when they put something like this up for discussion, it's just an absolute fucking fire hose.

How can you keep on top of this much feedback?

By the time we closed the discussion a day after it went up,

it had had way more comments than the Next.js layouts RFC had had in a two month period.

Because people were seriously energised about this.

For better or for worse, people were extremely energised.

And the thing that stuck in most people's mind was the fact that root files,

which is to say any file that is responsible for creating a root, now has to have a prefix.

And the prefix is a plus sign for a variety of reasons.

There's a lot of different symbols that we could have used.

But we settled on the plus sign because it's a character that people use all the time.

Every time you add two numbers, you're pressing the plus sign.

So everyone has the muscle memory and it's a lightweight, symmetrical symbol.

And it has the connotation that you are adding a root when you create that file.

So we added this prefix and a lot of people were like, well, why do you need a prefix?

Why can't we just have either what we had before,

where you can just put files in your folder willy nilly and they'll all just create roots,

or why don't we have something like index.svelte or page.svelte without a prefix?

And there are some really good technical reasons why it makes much more sense to have a prefix.

But I also want to argue that once you get used to doing it this way,

the DX reasons as well become very apparent.

Not least the fact that when you look at the contents of your code base,

all of your files are lexically sorted in a way that really makes sense.

You have your child directories first, then you have your root files,

and then you have everything else in that directory.

So whereas before, if you had a component that only belonged with a single root,

you would have to either put it in your lib folder and then import it that way,

which is kind of annoying if it's only used in one place,

or you would have to give it an underscore prefix so that it becomes invisible.

And you don't have to do that anymore.

So it's much, much easier to collocate code in a sensible way.

And that's possible because of the prefix.

The other big technical reason, of course, is that it allows us to add new files

that have special meaning to SvelteKit in future without it being a breaking change.

But it's also easier to teach.

Yeah, I guess that could be a controversial opinion, right?

I was just going to ask, what does that mean?

So I think some people feel like the previous way of doing it was closer to the,

well, what you would call the platform way, I guess you could call it.

So slash index would be slash index dot HTML, right?

Or slash about dot HTML would be slash about dot Svelte.

So I think on a very superficial, yes.

Yeah, yeah.

For very new people, yeah.

I mean, it immediately breaks down, right?

Because on the platform, quote unquote, if you have a file called about dot HTML

and you have a file called about slash index dot HTML, those are different things.

And they will be treated as different things by most web servers.

But in SvelteKit, about dot Svelte and about slash index dot Svelte, they are the same thing.

So even at that very, very basic level of, oh, this is close to how the platform operates, is bollocks.

It's not how the platform operates at all.

And I also think that if someone is coming to web development for the first time,

they don't come with all of that historical baggage.

And so we've got to focus on what is actually the simplest thing that we can teach people?

What is the most straightforward thing?

What is the thing that requires you to memorize the least number of special rules?

And the answer is, if you have a plus sign, it's a root file.

And as soon as you see that in a code base, you're immediately going to be like, oh, something's strange about this.

I haven't encountered this before as a web developer.

And so you go to the SvelteKit docs and you start typing plus page or plus server,

and it immediately takes you to the documentation that you need because there's no ambiguity.

Whereas right now, like if you open a SvelteKit code base and you see a file called about dot Svelte

and you see a file called underscore widget dot Svelte, like unless you already know the system,

you're going to have a hard time understanding what the distinction is between those two things

or why about dot Svelte and underscore underscore layout dot Svelte are more similar

than about dot Svelte and underscore widget dot Svelte.

So all of this stuff, like all of the baggage, we're just getting rid of it

and we're providing people with one thing to learn that is going to be consistent throughout their application.

One thing that I do like is the dot server.

So we're adding the plus to the prefix of a file name to create a route in the routes directory.

And then if it has a dot server, that indicates that it's only going to run on the server, right?

Correct. Yes. So there are three server files.

There's the artist formerly known as page endpoints.

So if you had about dot Svelte and then you had about dot JS,

about dot JS would get data from the server, pass it to about dot Svelte.

Shadow endpoints.

They were briefly called shadow endpoints.

That was just like some dumb internal terminology.

I love that.

There was recently like a petition to get that reinstated somehow.

I don't know. I want to get rid of the word endpoint altogether because it's just jargon.

And if you can just say like page server file and server file, like that's a lot less ambiguous.

So anyway, so page endpoints are now page dot server dot JS plus page dot server dot JS, I guess.

We also have layout endpoints or what we're going to be called layout endpoints at plus layout dot server dot JS,

which does the exact same thing.

It gets data from the server and passes it into your layout component.

And then we have plus server dot JS, which is a completely standalone endpoint,

not responsible for getting data into a page.

That's when you completely control the response.

So if you need to do something like you want to stream some binary data

or you have some other requirements that cannot be met by SvelteKit's SSR,

then that is when you would use plus server dot JS.

So would that be the equivalent to what you would now do like index dot JS or dot TS?

Yeah, so if you have today in SvelteKit, if you have an index dot JS or indeed this file can be called anything dot JS,

as long as it doesn't have a sibling component by the same name, it is treated as what we call a standalone endpoint.

And that itself is another example of why the current system is so confusing once you look past the superficial simplicity.

The behavior of the code in this file depends on whether or not another file exists.

That is not a good design. And so we're getting rid of that.

I kind of started looking at these changes as like all of the pluses, they add functionality to your route in a way.

Exactly. Yeah.

Yeah, it's nice.

One more note on the dot server thing.

Something that is not going to be implemented as part of this redesign, but will follow soon after,

is we want to have that as a convention that any file, any module that has the dot server in it is something that can only run on the server.

And once we have that convention, once we have that rule in place,

then we can actively prevent you from accidentally importing server side code into your client facing code,

which means so we already do this with your private environment variables.

For example, you can use your API keys and whatever quite freely on the server,

and we will prevent you from accidentally importing those into the client.

We're going to do that with all of your code.

So follow up question on that one. My understanding is react server components introduce this naming syntax,

but also they are in the process of leaving it to some unspecified future.

Are you aware of this?

I wasn't. Is that because they don't like the word server?

I don't know. I mean, you talk to Seb and you see what he thinks.

But they originally introduced dot client dot JS and dot server dot JS.

And one feature of the migration script that I really like is that it respects your git history.

It will use the git command line if it detects that we're in a git repo and git is installed.

It will do git move instead of fs rename,

which means that you're not going to have a hard time understanding how these changes are applied.

And so your git diff is very easy to review.

It's very easy to check that the auto migrated parts went well,

and it's very easy to see what tasks are left for you.

So yeah, I'm super happy with the migration scripts.

I'm glad that we ended up going the extra mile.

Yeah.

We want to say what the migration script is again, because I think that got cut off.

Sure. To run it, all you need to do is npx svelte-migrate-routes.

Obviously, it won't work today.

It will migrate your app, but then your app will be broken until we release the next version of SvelteKit.

But if you want to try it out on a branch and then see what effect it has, understand the changes,

then that is something that you can do today because we released it this week.

Do you know timeline on when the upgrade might happen, when the new changes might come?

I think it's going to be soon, honestly.

A few people asked me, they're like, so is this going to be like in a few months or next year?

And I was like, hopefully it's going to be in a few days.

And we've been blazing through it this week.

We've made some pretty solid progress, I think.

A lot of the tests are already passing with the new implementation.

And I would guess that if the bulk of it isn't done by early next week, then certainly by the end of next week.

And I would hope much sooner than that.

So yeah, if you're not already on the most current version, it's worth getting to the most current version as soon as you can

because the migration script assumes that you're on a recent version of SvelteKit.

If only we had a conference to announce it at.

Yeah, it'll probably be out before the episode is released, so it'll be perfect.

Yeah, probably.

Well, I mean, OK, there are several ways to release things.

You can release candidate things before you 1.0 something.

I do want to try to test run it through a use case that I have.

So I'm kind of waiting for it to be released in some usable form before I really understand the new layout changes.

Can we hop on the PR branch?

Start using it?

Yeah, so the first commit on the branch, the commit message was, it begins.

And because GitHub automatically names PRs after the commit message, unless you come up with something different,

if you have multiple PRs, it'll do something different.

The PR is also called, it begins.

So if you just go to the pools tab on the repo, you'll see it there.

Exciting.

You're muted, Brittany.

Oh, no, I was just, ntype, it begins.

It's just great.

All right.

That was a lot of changes in one PR, I guess, a couple of PRs.

But it is, I mean, you know, sometimes you have this experience when you're writing code that

something has felt slightly off about the way code is structured for a long time.

And it's always hard to put your finger on what exactly.

And then when you do hit upon the right design and you're able to just delete huge chunks of code,

everything starts to make sense.

I have had that feeling all week.

This is the happiest I ever am as a programmer is when I'm switching to a design that just suddenly makes sense.

And so even if, like, I don't expect people to care about the implementation details, I don't expect them to care about my happiness as the person implementing this stuff.

But I can tell you that the design that we have come up with is so much more logical, so much more robust and so much more scalable and maintainable than the one we had before.

So even if some of the cosmetic changes are a little bit odd at first, I hope people can trust me that this is, on every technical level, just a vastly superior design.

And I think on that note, we can probably move on to unpopular opinions, unless you guys have any other questions.

Oh, I pulled up the It Begins PR, and it adds 2,000 lines of code and removes 3,000 lines of code for a net decrease of 1,000 lines.

So it kind of checks. Very, very rough.

All right. Unpopular opinions. Who wants to go first?

There's some browser wars, so I'll go first because I have a small one.

I'm curious to get Richard's opinion about this, actually, as someone who designs metaframeworks.

So my opinion is metaframeworks should handle URL state management, meaning query params.

I think it's one of those things where you can kind of serialize states and usually is handled on the client side.

But it would be interesting if we're dynamically regenerating responses on the server to take it in and render it.

I'm not sure I thought that. I mean, we do take account of query parameters, don't we?

I did not know that. I don't know. We don't really have an API.

So if you're designing the function that responds to a request, then you have access to the URL search parameters.

Is there something more than that we should be doing?

Well, no, I think like get set and then like sort of render on like when we're rendering,

we should be rendering with the parameters that have been fed in.

I don't know. Maybe that already comes out of the box.

I have not been used to doing that. I've been doing it entirely on the client side.

And now I'm like, this should just be a pattern with everything.

So maybe I should change my opinion from Metaframe should handle your state management to just like all apps

can make more use of your state management.

Yeah, I think that's kind of what I'm pushing for is like serializable state that goes into the URL

so that people can copy and paste it into different places

and get to that client side state that other people have on their browser.

Yeah, I mean, you've spent a lot of time thinking about this sort of thing.

You've got the seven levels of state management thing, the Dante's Inferno of state,

which I would like to understand better because I feel like you're hinting at some problems

that as a community we're not that great at solving today and a more unified approach could be found.

It's like you have another PR on forms. It's unauthenticated storage.

It's authenticated storage. It's user settings. It's team settings. It's organizational settings.

If we keep having to add different paradigms to this, like basically the whole idea is that it should be easy

to bump things up and down levels of privilege so that we can innovate more.

It's kind of the same philosophy in my mind as what you have with the Svelte stores

and Svelte motion stores or the Svelte animation stores.

It should be easy to go from setting something to animating something.

So it should be easy to go from setting something locally on the browser

to persisting something on a server with different levels of authorization.

So I feel like that is something that's always like meta frameworks

that just kind of have their hands up in the air and just go do whatever you want.

We're not opinionated there.

Maybe there should be a bit more standardization here so we know what to do.

To me, I think we talked a bit about this last week, right?

And I think the example that we talked about were forms in particular

and being able to just go to a specific state of the form just automatically

by just pasting in a URL with the query params.

That just takes you to the, let's say it's the second step

and then it's prefilled with the first step, the wizard or something.

Yeah, for example.

And I think like, doesn't Phoenix Live View kind of work like this?

So I'm not an expert on Phoenix Live View, obviously, but like, can't you go from,

like you can drop the connection to the server, right?

And then the URL still has all of the state that you need.

And then you just refresh the page and it like reconnects with that specific state.

I don't know.

I wasn't aware that it did that, but very cool.

I think so.

I mean, there's definitely some state that cannot be serialized in the URL.

Anyway, just a thing.

It's unpopular because everyone kind of reinvents it from first principles every time.

And I'm just like, why isn't this more popular?

All right, you guys go on your browser wars.

Browser wars.

Safari is the best browser.

Barnon has the best features.

Firefox is the best browser.

I am a diehard Firefox user.

I do not think it is the best browser.

I think it's actually kind of terrible a lot of the time.

Like I keep it open a few days and I can't type into text inputs without like a 800 millisecond lag.

So I had to restart Firefox.

That doesn't happen in Chrome.

It's been open for weeks and it's fine.

I love Firefox.

I support the Mozilla vision.

I want Firefox to succeed, but it is not the best browser.

I was throwing that out there to throw shade at Kevin.

It's just not as bad as Safari.

Yeah.

I do like their CSS tools better though.

Yeah, I'm just thinking it feels like Safari feature-wise is on a roll lately.

Hopefully they pick up on the buggy stuff that people are experiencing.

And it's also like the fact that, well, it doesn't really have to do with the browser per se,

but like you can only use Safari on iOS, right?

That is frustrating.

And you always run into these bugs where people have only tested something on Chrome.

That has nothing to do with the browser.

Yeah, I mean, that's true.

I don't know that that is Safari's fault that web developers are lazy.

I am optimistic a little bit about Safari's future because of the regulatory stuff that's happening in Europe

that is going to force Apple to open up iOS to competing engines.

And if that lights a fire under Apple's ass and gets them to hire more engineers and devote more resources to Safari,

then hopefully we can have this privacy-focused, battery-conscious, blah, blah, blah browser

that has features that make it useful and also doesn't have the world's longest list of random bugs.

But it's not going to happen overnight.

No, hopefully next year then I'll hire 2,000 engineers that will compete with Google.

Yeah, that was my unpopular opinion.

All right. We ready for picks? Anyone else?

I was just going to say something stupid like sandwiches are overrated.

Only pizza rolls for you, right?

There's actually a new pizza roll that opened up here pretty close to the venue as well.

Maybe there's time for a new profile picture?

I was on the fence about coming to the conference, but now that there's pizza rolls.

Now that pizza rolls.

Yeah, they're even giving them away for free at the moment.

They're trying to make them popular or something.

Interesting.

Can you just get a bunch and put them in your freezer?

I think you'd have to download some dumb app or something.

Unfortunately not.

Yeah. All right. Picks.

All right. Can I go first? I have to run.

Okay. So at Svelte Summit, we are going to hold a Svelte Sirens luncheon.

We're going to take one of the lunch times on one of the days.

We don't know which day yet, and we're just going to have a section for women, non-binary people, allies,

anybody to come and ask questions, see what we're about, just hang out, chat with like-minded folks in a safe space.

And we're going to do that at Svelte Summit.

I guess more details maybe to come on the website at some point.

And we also have an August talk with Josephine Schaefer from Storyblock coming, I think August 16th.

I probably should have had that 17th.

And they'll also be at Svelte Summit.

They will. Yes. Very excited.

All right. Thank you. I'm going to run y'all. Have a good one.

Bye.

Okay. All right. So I'll do a quick one.

I realized that essentially working remotely, especially if you're running meetings,

you are essentially a streamer.

You are a live stream entertainer.

That is your whole purpose in life.

You produce entertainment for the people that you're streaming to.

And whether or not it is on Twitch or whether or not it's in Zoom,

you should use streaming tools and streaming tricks of the trade.

So I've adopted using Stream Deck to entertain my audience when I run meetings.

So I will play applause, I'll play intro music, I'll play pause music,

meme sounds, anything that will keep people entertained because we are professional streamers now.

That is just like peak Swix.

What?

Just like having that take in the first place,

like drawing that connection is just like a very Swix-ish opinion to have.

And I love it.

I love the way that you can draw threads between different domains like that.

Do you have like a button that goes pew, pew, pew, pew, pew, like that?

I do.

I can't play it now because I don't have the audio hooked up to this recording.

But I actually invested in Loopback, which combines audio streams to pipe it to one input

so that when I'm in an application, I can actually set that up.

And you have to pay like $100 for that.

And I did it just to make the streams more entertaining.

And so now when I joined a company, All Hands, I joined a board meeting once

and they actually request for it.

They request like, where's my intro music?

Where's the applause?

And I can do it.

And I think it's just fun.

But also just generally the whole cross-domain thing, I call it being a barbarian.

Barbarians don't care about territory.

Barbarians just see what's out there in the plains.

And they don't care about the artificial lives you draw between domains.

And they just say, all right, this thing looks similar to the other thing.

I'm just going to do exactly what I want on the other thing to achieve the results I want

and screw your arbitrary domains.

So I like being a barbarian in finance and tech, whatever.

I love it.

Yeah.

Do you have one, Rich?

Yeah.

My pick is climbing.

It's my new obsession.

Like bouldering?

Climbing gym.

Mostly bouldering.

A new climbing gym opened up around the corner, and Jen and I have been going regularly.

We climbed with a friend last week who came bouldering with us and was like, no, no, no,

no.

This is fine, but top roping is where it's at.

And so this morning, we went to the gym, got our belay certifications.

And so now we're climbing these very tall walls and then turning around at the top and

realizing it's a very long way down.

And it's fun.

It's a really good form of exercise because, I mean, apart from the gym being just down

the road for us, it's like you're in, you're out.

It's very quick.

There's like very little fussing involved.

But while you're doing it, it's impossible to think about anything other than the climbing

because it's a cognitive thing as much as it is a physical thing.

And so for those of us who spend most of our lives hunched over laptops thinking about

tasks, it's just a really good reset, as well as using muscles that I didn't know I had

before.

So if you have a climbing gym in the area, I heartily recommend that you get a day pass

and give it a whirl.

It's a lot of fun.

Yeah.

Yeah, I can plus one on that.

I have a gym pretty close by as well that I go to sometimes.

It is a lot of fun.

And it doesn't feel like exercising, right?

That's part of it.

It's just fun.

It feels like solving a puzzle.

It feels like being a kid again, like you're playing.

Definitely a lot of fun.

I don't have a pick.

This usually doesn't happen, but it's OK.

We've got plenty to make this episode interesting.

All right.

I was going to say we should do climbing as felt summit.

So I mean, sure.

Just an analogy.

Yeah.

I mean, I mean, so it's so it's basically like I think it's like a 10 minute walk from

the venue and the hotel.

So it could be fun.

All right.

Yeah.

I'll see you guys at Svelte Summit.

It's just a it's just a month away.

Oh, it's exciting.

It's going to be a lot of fun after.

It's going to be a lot of like I'm going to take a vacation after because it's a it's

a it's a lot of weird issues and stuff.

It's going to be fun for us.

It's going to be an absolute whirlwind of stress for you.

Don't say that.

I guess I need to be prepared.

Yeah.

Well, anyway, I'll see you at Svelte Summit.

And thanks for coming on again, Rich.

Yeah.

Thanks for having me.

Yeah.

See you guys.

Bye.