(upbeat music)

- Welcome to Svelte Radio.

- Welcome everyone to another episode of Svelte Radio.

I am back with yet another guest.

Can you guess who it is?

It's Rich Harris.

Hello, Rich.

- Hello, Kev.

- Nice to meet you again.

We're here in your beautiful apartment in Brooklyn.

- Welcome to my digs.

- Yeah, it's nice.

You've offered me tea, I've graciously accepted the tea.

It's nice.

- She's currently sitting on a--

- On a Svelte's coaster.

- A Svelte-themed coaster, courtesy of Dana Woodman.

- All right, Rich.

It was a long time since you were on Svelte Radio.

You've been on the devlog on YouTube a couple of times.

But yeah, Svelte Radio, it's been,

we haven't recorded as many episodes as I'd like to lately,

so it's great to have you on.

Let's, do you wanna introduce yourself?

Do you need to introduce yourself?

(laughing)

- I mean, I guess I should.

I'm a guy who works on Svelte for a living.

- Did you make Svelte?

- I did the initial commit, yes.

A little over eight years ago.

- Eight years?

That's been that long?

- It's been that long.

- Wow, that is a long time.

That's nice.

All right, so we've got a bunch of topics here

to get through.

Svelte 5 is finally out.

What are your thoughts?

Positive, negative?

- I mean, my main thought is thank God I can--

- You can breathe again?

- Yeah, have some sleep and relaxation.

Feeling pretty good about it, if truth be told.

There was definitely some nervousness from me

and from the rest of the team that,

because in some ways it is quite a radical departure

from Svelte 4, that a lot of people were gonna be like,

ah, you know what, I'm out, I don't like it anymore.

And the feedback that we've had,

obviously there's a couple of people who are like,

who moved my cheese?

But the overwhelming consensus seems to be

that this is a good and needed change to Svelte.

Even the people who initially were very skeptical.

- I was kind of one of them.

I don't know if you remember, I was pretty--

- You were, you've pushed back on a lot of things.

And in a lot of cases, that pushback has resulted

in better and more refined designs.

But in some cases, the ideas just kind of took a minute

to become apparent that they actually do make sense.

I can't remember Fireship in particular.

It was always like a big proponent of Svelte on his channel.

And when we previewed some of the Svelte 5 stuff,

he was like, what is going on?

This is, they've cocked it right up.

And even Fireship came around after we launched.

- He has a huge following as well.

- He really does, yeah.

And so it's very gratifying to see people

who have approached this from a position of skepticism

and have taken an honest look and re-appraised it

and said, yeah, this is the good stuff.

- I'm in that camp, for sure.

For me, as someone who doesn't really use that many,

or I did not use that many reactive statements,

for example, I heavily relied on SvelteKit

and the load function and the form actions

and use/enhance, I never ended up really having

to use reactive statements for a lot of things.

So for me, that part had never really been a big issue.

It was never, it never got complicated enough

that I would really have to sort out lots

of reactive statements that are tied together

and depending on each other in some weird ways, right?

'Cause that's kind of what effect and derived by

is trying to solve.

- It is, and the biggest pit that people dug

with Svelte 4 was using too many reactive statements

to do effects, basically.

- Yes, yeah.

- And that is still a pit that you can dig in Svelte 5.

If you use the effect room too much, then chances are

you're going to end up with some code

that is a little bit difficult to reason about.

But having that as a separate concept

from the derived concept, which they're obviously

different things, but in Svelte 4,

they're treated with the same mechanism.

We're able to much more clearly disentangle them now

and say you probably shouldn't be using effects

most of the time.

There are cases where they are valid,

there are cases where they're necessary,

but for a lot of tasks that people want to reach

for an effect for, actually it's not the right tool.

- Right.

- And having that distinction is very helpful.

- Yeah, it's clarifying as well,

like the code makes it easier to read.

Yeah, I have some horror stories of seeing components

where like everything is a reactive statement

rather than just like having a let something,

it's just like dollar sign, colon, something equals.

- Yeah.

- Why?

- Yeah, I mean.

- 'Cause people are confused probably,

like when to use it, when not to use it.

- In some cases, yeah, I mean, there's this idea

that if you just put a dollar in front of it,

then it'll become reactive and you can do what you want.

- Why wouldn't I want it to be reactive?

- Exactly, and part of that is perhaps

a little bit of laziness on the part of component authors,

but a lot of it, I think, is really that you are

kind of pushed in that direction by Svelte 4

because if you start putting something

in a reactive statement, it becomes pretty hard

to refactor it out because of the compile-driven semantics

of reactivity in Svelte 4, they become magnets

for more and more code, and the larger it gets,

the harder it becomes to disentangle.

And that's something that when you have

runtime reactivity based on signals,

refactoring is just like refactoring

any other JavaScript code.

- Finally.

Yeah, one thing about other features of Svelte 5

that I've heard people like a lot is snippets

'cause that was a missing piece in Svelte 4, right?

You couldn't reuse logic unless you created

a completely new component.

Like recently I heard, it was probably someone mentioned

it was their favorite new feature of Svelte, actually,

so that might be surprising, but I can see it.

It solves a lot of issues with slots,

especially the, you know when you had slots

and you had to use the let directive?

- Yeah. - It just got super confusing,

like which way is it going, like what is happening?

Just like, ah. - And now there's no symmetry

between the things that are part of the default slot

and the things that are not part of the default slot.

Like the lexical scoping is very confusing.

- Oh yeah, yep. - Yeah.

Always been one of my least favorite parts

of the design of Svelte 4, also the code,

like the implementation of that stuff is really filthy.

And it all gets so much cleaner with,

now that we just have this one concept that is used

both to pass stuff to components,

but also if no other components are involved at all,

it's like, it's all one consistent way of dealing with it.

- Yeah, and it's very nice, it's very nice.

- And the implementation is much nicer.

I'm really looking forward to when we're eventually able

to delete some of the code powering the,

you know, backwards compatibility was felt for me.

Not gonna happen anytime soon,

wanna reassure people that like a minimum of, you know.

- One major version at least?

- Yeah, I mean, we think in terms of timeframe

rather than version numbers,

because, you know, that's how people operate

in the real world, like it takes a certain amount of time

to migrate the code. - Is that how it works?

- Yeah, and I, you know, I'm not gonna say that

on such and such a date we're gonna flip a switch,

but I can say that it will be a very long period

with lots of warning.

But when we get to the end of that,

and the warning has been issued,

and the deprecation notices have been emitted,

and all the rest of it, and we're able to delete that code,

we're gonna be able to just get rid of swaths

of code in the code base, and it's gonna feel so good,

because deleting my code is like one of my favorite things,

not just in programming, but in life generally.

Deleting code makes me so happy.

- Yeah, yeah, I agree, same for me.

Like, seeing those red lines on GitHub,

like the diffs, it's like, oof.

- My hot take is the color of the diffs is wrong.

- Oh, right, yeah, yeah. - Like, you see a big diff

where you're deleting a bunch of stuff and it's all red,

but it's a good thing, like, if I'm deleting all this code,

like, I want a big green thumbs up.

- Yeah, it shouldn't be a--

- Give me the red danger color for when I'm adding code,

'cause adding code, that's--

- Leads to problems.

- That's the stuff that you should avoid.

- That's a nice hot take.

So any other feedback on Swath 5,

like, what have you heard?

- The thing that's brought me the most happiness

is hearing people say they have like 100,000 plus line

code bases who've migrated to Swath 5, like, in a single day.

- Right, with the new migrate script, right?

SV migrate, is that?

- Yeah, yeah, so we have a new command line tool.

- Oh, yeah.

- One of the commands of that tool is the migrate command.

MPX SV migrate Swath-5 will take your existing code base

and upgrade to Swath-5 and change the syntax

of your components where appropriate.

- Yep, I actually used it recently at work, more great, so.

- Yeah, it's been a huge success.

Lot of that is down to Simon, who from the start was like,

we've gotta be really good at the migration stuff,

otherwise, like, we're gonna lose people's trust

and people are gonna be very, very annoyed.

- Then you'll end up in like the Vue 2, Vue 3.

- Exactly, exactly, and so, you know, a lot of that

initially is down to him.

Paolo, which you think has been doing a lot of work

on the migration tool more recently as well.

It's turned out really well, very happy with that.

- Yep, yeah, it's like one of Svelte's strong,

like really, what's it called, strong points?

Is that a word, no?

- Yeah.

So it was like, I feel like the other frameworks

are not as good in general at migrating stuff.

So there was a migration script for kit as well, I think,

from like before the plus page stuff, right?

- Yeah.

- So it really is a very strong point,

like having an easy way to upgrade your stuff

without having to manually change laborious things

that are just like name changes or stuff like that.

- Yeah, I mean, there's basically three ways you can go.

You can make it easy for people to migrate.

You can retain backwards compatibility forever.

That's sort of what React has done.

You can still use--

- Class components.

- I think you can still use the thing

that was before class components.

- There was something before class components?

I had no idea.

- Yeah, but before classes were part of the language,

you would do, I think you would call create component

or create class or something like that,

and then you'd pass in your definition

and it would do auto binding of your methods

and all of this sort of thing.

A lot of stuff that with modernized looks super janky,

but that was how it was before classes were in the language.

And then obviously hooks came along,

but you can still use that very, very old stuff today.

And the third option that you can do is just not care.

Just say, all right, people, you're in version.

And that's what Angular 2 did, for example.

And of the three of those, I understand and respect

the whole backwards compatibility thing,

but at the same time, that is technical depth

that can really kind of slow your development down.

And so for me, I think it's better

if we can get the whole community

singing from the same hymn sheet

and working with Svelte5 as a baseline.

It'll allow us to move a lot faster

and add a lot more cool stuff.

- And it's not only the code base itself, right?

It's also all the content that's done around the framework,

like articles and all this stuff.

Like if you can somehow get people to write new stuff

instead of writing it in the old way,

then that's a good thing.

I think having migration scripts

is a good way of promoting that.

- Yeah, although you really can't do anything about--

- No, no, I mean-- - The Stack Overflow--

- Yeah, I mean, it's gonna live forever,

but it's at least like someone can just drop a comment

or add a notification, or like a, I don't know,

an information box or something that says,

oh, this is deprecated, use an npxsv migrate svelte5

and get the new stuff, or something like that,

rather than having to rewrite the whole article, maybe,

or stuff like that.

All right, cool.

So before we started recording,

we talked a bit about Advent of Svelte.

So we actually did an Advent of Svelte last year

at Svelte Society, right?

A bunch of different coding challenges, if you will,

with different, I think it mostly used just svelte,

but might have used SvelteKit as well, I don't remember.

But now you mention that there's an Advent of Svelte

from the core maintainers as well, in some way.

- There is, yeah, I'm not sure how

or if we're gonna combine forces on this, but--

- Yeah, yeah, there's been some talk about that, yeah.

- Yeah, the basic idea is we've been working

on the Svelte5 release for, what, 18 months or so.

And all of our effort has been basically spent on that.

And as a result, there's a whole lot of features

and ideas that have been sort of left to languish.

And now that we have this brand new shiny stable foundation

to build on top of, wouldn't it be nice

if we can start knocking out some of the quick wins

that have been piling up in the issue tracker?

And so our plan is, once a day,

from the first of December up until Christmas,

we'll ship a feature that people have been asking for.

Maybe in Svelte, maybe in SvelteKit,

maybe it'll be something--

- Like an ecosystem thing, or--

- An ecosystem thing, or the svelte.dev/playground.

- Ah, great, yep.

- There's various ways that that could be improved.

And so that's gonna be our big thing for the next month.

- That's a lot of new stuff, right?

25 things?

- It is, I mean, some of these things will be fairly small.

- Of course.

- Some of them are things that people have been asking for

for a long time, but we just haven't got around to.

But actually, the implementation isn't that taxing.

It's gonna feel good.

- Can you, do you wanna spill the beans on some of them?

- I can tell you what we're shipping first,

because by the time this airs, it'll probably already

have happened.

Day one of Adventist Svelte,

we are gonna ship error boundaries.

- People have been asking for that.

- People have been asking for error boundaries.

This has been a pretty big gap in Svelte,

like ever since it's existed, really.

And the way that Svelte operated from day one

is that you have a state change,

and that directly results in an update to the DOM.

- Right.

- And that just kind of happens sequentially.

And that was why Svelte, in the very early days,

like Svelte was so fast because it didn't have

all of this intermediate stuff of,

oh, we're gonna update some key value store,

and then we're doing the key value observation,

which is gonna, you know, or some virtual DOM diffing,

like whatever it is, all of the different mechanisms

that people use for translating a state update

into a DOM update, Svelte just kind of bypassed that.

- Screw it.

- Yeah.

And so, because of that, it was, I mean,

really hard as understanding it.

Basically impossible to add error boundaries

in a really consistent and reliable way.

But obviously, if you're building an application,

error boundaries are important,

because you can't always guarantee

that you've written your code perfectly.

- Or if there is a network error,

maybe that you didn't anticipate,

or anything that you didn't anticipate, really, right?

- Yeah.

- You don't want your whole application

to just like crash, and you end up in that state

where you're like clicking a button, nothing happens,

and you're like, you open the console,

oh, there are 58 different errors over here.

- Yeah.

- It's not a nice experience.

- Yeah, so the state becomes corrupted,

and like it basically can't recover from it

without refreshing the page, which is obviously no good.

- Yeah.

- Pretty shocking that we've been without it for so long.

- Maybe a testament to how resilient

Svelte applications have been written, I don't know.

- Or how just gushed-down, talented Svelte developers are.

- That is also an option.

- Everyone's been writing perfect apps.

- Obviously.

- Yeah, but that's gonna be a really nice thing to have.

And it's one of the things that is actually pretty easy

now that we have this new approach to--

- The layer in between, the update, right, so you can--

- Yeah, so in Svelte 5, if a piece of state changes,

then what happens is immediately, like fan that out

to all of the effects that ultimately depend on that state,

including intermediate derives, like your dirty deriver,

that will cause everything below it

to be considered maybe dirty.

And then once we've run a microtask

so that any other state updates happen at the same time,

we then go through all of those effects

and update them in a group.

- Yep.

- And with this way of doing things,

we're able to say, oh, one of these failed,

but because it happened within a boundary,

we can just remove all of the effects within that boundary

that had been updated up to that point

and show some fallback content.

And it means that you're given the opportunity

to retry whatever operation failed or show some UI,

describing the failure, and you don't need

to have really defensive code.

- Yeah, yeah, it's interesting with the defensive coding.

So I talked to someone about how I tried

a different kind of handling errors,

just experimenting with it, with like,

instead of doing like a returning,

you know how in Rust you usually have like an okay

and error tuple that you get from functions and stuff?

- I'll take that for it.

I'm not a Rust-ation.

- Yeah, same, but yeah, it's a thing.

So you return like, you handle the errors

where they happen and stuff, but I was thinking like,

maybe I could just like wrap the load function in kit

and then just throw somewhere and just handle

all the errors at the top in some wrapper function

and then return error depending on what kind of error it is

rather than like returning it up all the way

to where I send it back to the client and render something.

And that makes your control flow logic much easier,

but then you also lose like context from the error

and where it happened and why it happened and stuff.

You only get like a, I don't know.

Well, I would do stuff like prepend the error message

with validation, for example, and then I would do like,

oh, you didn't enter your details correctly

and something like that.

- But you know, you're still left with the possibility that--

- Oh, yeah, yeah, yeah, for sure.

- That like somewhere in your template

you refer to foo.bar and foo is undefined and--

- Yeah, so to clarify, this was in the back end, right?

So in Svelkit, so in the load function specifically.

I didn't try it in the front end, but it's like a fun,

it's a different way of doing errors

that I haven't done before.

Interesting experiment, fun experiment.

All right, what else other than error boundaries?

Are we getting portals?

Is that a thing?

- No, I don't think that's on the radar.

I know that is a thing that has come up

as a feature request in the past.

I feel like a lot of the time you can do the thing

that you would want portals for in userland already.

- Yeah, I don't think I've ever really needed a portal,

to be honest, but.

- Yeah, you know, with some of the CSS stuff,

we have anchor positioning,

and we have these new popover APIs on the platform.

Like, do we still need portal APIs?

I don't know.

- Probably not, probably not.

- So by, yeah, I think we can probably get away

without adding a first-class built-in portal API to Svelte.

But, I don't know, people feel very strongly otherwise

then, let us know.

- Yeah, all right.

All right, what else?

I kind of interrupted you there with my portal question.

- What else?

All right, I don't want to give too much stuff away,

'cause we've got some nice surprises lined up.

But I will say that people who use Tailwind

have found it a little bit annoying

that you can't have multiple classes in a class directive.

And so, if you have an element that is conditionally styled,

you either have to use a big old ternary statement

inside a class attribute,

or you have to have a whole bunch of class directives.

You know, like class margin for equals condition.

- Very ugly.

- Whatever, yeah, and we have a solution to that,

which we think people are really gonna like.

- That's exciting.

I use Tailwind, so that'd be great for me.

Like, the way I do it now is I just opt out

of writing the Tailwind stuff in the template,

and I do it in the style tag instead.

'Cause you can still use like an @apply something.

- Which I believe the Tailwind guys don't like.

- Yeah, yeah, but it's like a work-around, right?

Because it's like I'm not gonna have

16 class directive statements in my one element,

and then maybe have to do it in six different places.

I'd much rather have like class colon danger,

and then I'll apply all the like border red,

whatever, in the class.

But yeah, kind of defeats the purpose of Tailwind, I guess.

We chatted a bit about the bind directive as well,

is that something that's gonna change, or is this a secret?

- Yeah, well, it's not a secret,

because it's in the pull request queue.

In general, if people wanna know

what is coming down the pipe,

then looking at the pull request queue

is the best way to do that.

- This part I will edit out, because no, I'm kidding.

(laughing)

- Yeah, and honestly, there are people who spy on that,

and it's pretty great, because they'll offer feedback

and sometimes help us make better design decisions.

So the deal with bindings is if you have a bind directive

on an element or a component,

the value of that must be some local state or a local prop,

which we read or write directly.

Sometimes you wanna intercept the write.

- Yep.

- Maybe you wanna do some validation or something like that.

And at the moment, the only way that you can really do that

is by having an object with a get set property pair.

- Oh, right, you could already do it, I guess.

- You can, so suppose you have const text equals,

and then you have an object with a get current,

which returns some other piece of state

that you defined elsewhere,

and a set current, which just writes that value.

Inside that set function, you can do your validation.

And then, on the element, you'll do input bind colon value

equals text dot current,

and then that will use the getter and the setter.

It's a little bit cumbersome, obviously.

- Yeah, I mean, the way I've done it,

it's just like I opted out of bind

and just used an event.

- Which is also a totally valid approach,

but that, too, is a lot of boilerplate.

- Yeah, yeah, it's pointless.

Well, it's not pointless,

but irritating to have to write.

So we have a way now to provide the getter

and the setter directly within that bind directive,

which is particularly useful

if you want to do some one-off validation,

like you don't want to go through all the rigmarole

of creating this object or adding an event handler,

and that's something that you should be shipping

pretty soon, too.

- It's like one of those things

that when you try Svelte the first time

and you try the bind directive,

and it's like, oh, it's so nice.

You don't have to write any code.

And then as soon as you have to do something

where you have to manipulate the value a bit

before you send it up or do anything,

it becomes a bit irritating,

'cause you're like, oh, I could use this very nice thing

over here, but I have to do something here first.

- It is irritating, but it's also,

it pushes people towards using effects.

Like, you often see people using effects to do validation.

- Right, okay.

- And that's absolutely the wrong thing to do.

The effects are very bad for validation.

And there are a lot of things that they're good for,

but if you want to do your validation,

that should be happening upstream.

It should be happening within an event handler, essentially.

And having bindings where you can control

what happens on write,

that essentially gives you a place to put that logic

that's equivalent to the event handler.

- Oh, that makes sense, that would be a nice addition.

There's also, we chatted a bit about actions, is that?

- This is, no, this is--

- That's not for Advent of Svelte, maybe.

- Yeah, this is a longer term goal that we have.

So the use directive and the transition directives,

transition in and out, these are actually quite similar

in that they are essentially element lifecycle callbacks.

And another thing that they have in common

is you cannot spread them onto an element.

Like you cannot receive them,

if you're building a component,

you cannot receive those things as props

and then spread them onto an element,

which by extension means you can't really pass them

into a component in the first place.

- Yeah, you kind of have to do weird workarounds now, right?

- A lot of weird workarounds.

And just the design of them is a little bit funny,

like even on a syntactical level,

they're candidly a bit weird, like use colon foo

means that you have something that is called foo

that is lexically scoped, like you can't define an action

in line on the element, and all that sort of thing.

So I think we can do a better job,

I think we can make these things more composable,

spreadable, and so on.

We can make them more consistent with each other,

have less syntax, less API surface area

than having all of these separate bindings,

write things that are actually quite similar.

And I think we can make it so that they're

a little bit more flexible and powerful as well.

So we have some ideas for what the evolution

of that basic idea of an action could look like,

and that's something that we'll be focusing on in 2025.

- 2025 isn't that far off.

All right, what about this async stuff

that you mentioned beforehand?

Is that something you want to talk about,

or should we skip it?

Like, what's...

- I can give the very high-level view,

which is wouldn't it be nice if we had

more of an ability to think sensibly about

how async state works inside Svelte components.

At the moment, we have the await block,

which is really good if you have a promise

and you want to show some pending state

until the promise resolves,

and then you want to show the value of the promise

or some fallback UI if the promise rejected

for whatever reason.

Really great in the case of a single promise.

As soon as you have multiple promises

and you want to coordinate somehow,

and you want to show some skeleton UI

until multiple promises are resolved,

doesn't really help you anymore.

And so you have to do a lot of

fairly tedious orchestration yourself.

Some frameworks have kind of solved this problem.

Like, you hear about React suspense, for example,

which is essentially a way of coordinating activity

that could be happening in multiple components

that aren't aware of each other

and haven't been designed to coordinate

with each other in the first place.

And Svelte doesn't have that,

and it would be nice if we did.

And so while we don't exactly know

what the Svelte way of doing that is going to be,

it's something that is definitely top of mind.

- Yeah, and that would probably also affect

like data loading in KIP.

- Potentially, but potentially.

I don't see the load function going away anytime soon.

Like, I think that the distinction that SvelteKit has

between the loading and the rendering phases

is actually really useful and important.

Like, the fact that you have this loading phase first

in which you can throw errors and you can do redirects

and all of that sort of thing

before you start the rendering process,

I actually think that's a pretty essential separation.

- Yeah, I mean, I prefer it as well.

I'm very, like, I really do not like to have logic

inside of my visual, like, mixed into the visual stuff.

- Yeah, at the same time, at the same time,

sometimes you'll have a component somewhere in your tree

that needs to get some data asynchronously,

and you're left with a choice of showing some,

like you have a flash of unfetched content

while that component does its business,

which might have to happen with a fetch inside an on mount

or something like that,

which is kind of a grubby way of thinking about the problem.

Or you have to hoist that data requirement

all the way up to your load function

and then sort of prop drill

all the way back down to that component.

And then, you know, if you end up not needing it

and you delete it, then you've got to remember

to also get rid of the data loading code

in your load function.

And that kind of sucks.

It would be nice in a lot of cases

if you could have that loading logic inside the component

so that it was co-located sensibly,

and if you deleted the component,

you're also deleting the data loading code.

Obviously, you want to be careful that if you do that,

you're not introducing the possibility of waterfalls.

So you have to be very careful

about how you design these things.

But if we do that, then that's one less thing

that needs to happen inside the load function.

And so, you know, it's very possible

that if we do manage to design async state

in a really good way that allows us to do this sort of thing

without introducing waterfalls,

then the way that we think about loading in SpeltKit will,

you know, could change quite substantially,

but, you know, that definitely not in the immediate future.

- Would that mean kind of like component-based loading,

or would it, how do you imagine it looking if?

- Yeah, I think you would probably want to have

the dependency on some asynchronous resource

expressed inside the component,

and then maybe your load function is primarily

about doing, you know, the errors and the redirects and--

- Right, yeah, yeah.

- Authentication and all those sorts of things

before the actual loading happens.

- I think I misspoke.

I meant component-by-component loading functions.

Maybe that's what you answered, though.

I don't know.

- It's very--

- Like, instead of having one page,

I'd have sidebar loading function, or, you know, like--

- Yeah, it's really hard to say what you like at this point.

- Like, I also, like, I kind of like having it all

in one file, in the sense that, like,

oh, I know where my loading is happening, right?

If that was split up into, like, 15 different files

that are all over my code base, then I'm like, ugh.

But then at the same time, if I'm in, I don't know,

the post list component, then it kind of makes sense

to also have the data loading next to it.

I don't know.

- Yeah, I mean, to push back a little bit on that point

of, you know, having the code in 15 different components,

like, do you think about CSS that way?

Do you think--

- I mean, I write Tailwind, right, so--

- Right, right, right, but, you know, it's a--

I mean, no, I think it does apply, actually.

Like, you're defining the styles on the element itself,

which is the most granular--

- That is true.

- You can do that, but the slightly less granular

and maybe more self idiomatic way is to have the styles

defined in the component, and if you don't do that,

then, you know, if you say, I don't have all my styles,

like, split across all of these 15 components,

I want to have, like, one global.css file.

And that's essentially what a load function is today.

There are obviously pros and cons and trade-offs and so on,

but I do look at what people can do

with React server components, like, a little bit of jealousy.

I think it would be nice if we could steal

the good parts of that.

- Yeah, all right, fair enough.

We also mentioned here that we wanted to talk about

the store, that stores are not scoped in Svelkit.

If you're doing the server side,

don't remember what it's called.

- Yeah, the, so people--

- They're global, right?

(laughing)

- Yeah, there's this meme that stores aren't SSR safe,

essentially. - Yes, yeah, yeah, so.

- You know, if you're referring to a store value

inside a component in your Svelkit app,

and you're deploying to a multi-tenant environment,

like a node server, then, in theory,

you could have a response for one user

displaying another user's data.

- Right, yeah, that's my point.

- Obviously, that would be very bad.

In practice, like, I think you've really got to mess up,

like, substantially before that.

And also, it's not about stores.

Like, this isn't a problem with stores.

This is just a problem with variables that,

yeah, with global state, essentially.

However it's expressed can be just a normal variable.

- Yeah.

- Like, if you really code things in quite a strange way,

then there is a possibility that you could leak data

between users, but like, number one, don't do that.

But number two, there is this primitive

that exists in basically every server runtime now

called Async Local Storage.

And in theory, it should allow us to build some primitives

that essentially make that a non-issue altogether.

What Async Local Storage does is it allows you

to associate a context with a specific request,

and then at any point while you're responding

to that request, you're in that context,

even if the response takes place

over multiple sequential steps that have, like,

an asynchronous gap between them.

- Right.

- So whereas today, you have a load function,

and you're sort of given things that pertain

to the current request, and they're part of the arguments,

the load function, so you know, you call event.fetch

instead of just calling fetch or whatever.

The reason that we do that is because that's how Svelker

is able to associate those resources

with the current request context.

- Right.

- But if we use Async Local Storage,

then we might be able to design things

in a slightly more ergonomic way.

So you know, sometimes you will see people

have an abstraction around an API,

and it requires a fetch implementation to be passed in.

- Yeah, that becomes cumbersome, yeah.

- It does, and so you have to pass event.fetch

in every time you make an API call.

It's very annoying with Async Local Storage,

like things like that, are no longer necessary.

And similarly, if you can associate

a particular store read with a request context

you know, store read or any other type of variable read,

then you can ensure that the stuff that you're rendering

while responding to this user is scoped to this user

and not some other user.

So I think that will hopefully put this--

- Alleviate and get rid of the mean.

- Yeah, once and for all.

And you know, this isn't a problem that's unique

to Svelte by any means.

This is like just the reality of building--

- Just how it works.

- Applications that work in multi-tenant environments.

- Yeah, you also mentioned here PPR.

- I did, yeah.

- What is that?

- Next.js has a feature called PPR, partial pre-rendering.

And what that means is in the same way that in Svelte

you can pre-render a page of your app,

or you can pre-render a root of your app,

I guess I should say.

In Next, you can do that on a more granular level.

You can pre-render a particular layout or a particular page.

So say for example you have a navigation bar

that has a login/logout button.

Obviously that needs to be dynamically rendered

because we need to read cookies and see who you are

and what your name is and include that in the rendered HTML.

But maybe the page is just a static piece of content,

like a blog post or something.

So does it make sense to de-opt out of pre-rendering

so that you get the navigation bar,

but then you've got to hit a database to get the blog post

because you're dynamically rendering the blog post?

No it doesn't.

It makes a lot more sense to have the inner HTML

of the page pre-rendered and put somewhere,

and then you just do the dynamic rendering for the layout.

Or vice versa, you might have a static navigation bar,

but then you have some content on the page

that needs to be dynamically rendered.

- How granular could you get with this?

Like can you do it per component basically and then like?

- I don't know about that.

That starts to get--

- The overhead is bigger than--

- I think it's just too complicated for,

at least for me personally,

to figure out how you would do that.

But definitely pre-rendering at the granularity

of layouts and pages, I think is,

most of the time that's kind of--

- That's enough, good enough.

- Realistically that's what you want.

- 'Cause we've had some people asking for,

you know if you have a, before Svelte 5,

if you had a really long blog post,

like that could be, that could end up being

quite a lot of JavaScript, I think.

Because like, if you have a,

takes a long time to hydrate, right?

If you have a really, really long blog post.

And if you could pre-render that

and still have some things that are interactive,

that could be nice.

- Yeah, that's a slightly separate issue.

Yeah, that's about how you describe the component

in JavaScript, and what techniques you use

to avoid doing any unnecessary hydration work.

And Svelte 5 is a lot better than Svelte 4,

was it avoiding unnecessary hydration work?

We can skip over entire subtrees

if there's nothing to hydrate inside,

whereas Svelte 4 would do a lot of fairly unnecessary work.

And so things are definitely better in that regard.

There's room for improvement still.

Like we're still not as fast at hydration

as frameworks that don't ship any JavaScript

by default at all.

Those that use islands or resumability or whatever it is.

In practice, like, it's fine,

but there is room for improvement,

and that means that we, our work is not done.

- Right, yep, yep.

Well, I'm excited about partial pre-rendering.

Does that mean, like, so partial pre-rendering,

does that mean that we can stream just HTML

to some parts of the page,

like stitch it together somehow with,

'cause I remember I read a blog post a while ago

by Phil Walton, like some Googler.

He'd done like a service worker kind of thing where--

- That sounds like a Phil Walton thing.

- Yeah, yeah, he'd done like a,

he would split up the page in different,

like HTML sections, and then he would like

stitch them together in a service worker

and like stream that to the browser,

and just change the content part of it.

- Yeah.

- Maybe that's completely different though,

probably to partial pre-render.

I don't know.

Like could you stream in the,

make it so the layout section that's pre-rendered

streams in while the data for the other stuff,

like, am I making any sense?

- Yeah, I think streaming in SvelteKit

is gonna continue to be based on data rather than markup.

The way that we think about streaming

is a little bit different to other frameworks.

Like I'm not entirely convinced that streaming markup

makes that much sense in most cases.

You can invent scenarios in which

the ability to stream markup is helpful,

but most of the time what you really want

is to render the page immediately,

and then stream in the data that populates

the components that then subsequently get rendered.

You're much more likely to avoid broken layouts

and things like that if you do it that way.

- All right.

Yep, cool.

Let's talk about, so I'm here in New York

visiting a friend, but then for some reason

there was also JS Nation at the same time.

You did a talk, North Star I think you called it.

Should we talk a bit about the conference?

Did you like it?

- Yeah, I mean look, conferences are always fun.

They're a lot of work if you're going there to speak.

- Yeah, if you're just going out to talk to people

and hang out, then it's not a lot of work.

- But once the talk is over and you can sit back

and just enjoy hanging out with a bunch of other nerds,

then yeah, these things are great, have a good time.

- Yeah, definitely recommended for people

that haven't been to a conference.

It's definitely something you should experience.

What was your talk about?

- So the idea of the talk was Svelte has had

a lot of different identities over its eight years.

And we've just shipped Svelte 5 which is

a bit of a departure from what the framework

has looked like up until this point.

And so the talk is sort of a forcing function

for me and the rest of the team to try and codify

what it is we're actually trying to do with this project.

When Svelte 1 came out, its raison d'etre was to let you

ship applications with the smallest bundle size possible.

And then later that focus switched to be a little bit more

about making apps that are very fast

because you have compile time reactivity.

And then we realized that what people actually like

about Svelte is that it allows them to write applications

very concisely and that it's just kind of fun to write.

And so we leaned into this idea that with Svelte

you can write less code and as a result of writing less code

you can write more robust code, you can write code

more quickly and so on.

And then obviously SvelteKit, we shifted focus towards

well here's how we think you should build an application.

Doesn't solve all of the problems of application building.

Like it's, wouldn't call it a full stack framework

but like a lot of the stuff that Svelte itself

doesn't help you with, SvelteKit is there to help with that.

So with Svelte 5 a lot of the focus has been on

reliability and predictability and so on.

And that's changed a lot over the course of the project.

And so the last maintainers meeting that we had last month

we sat down and we talked about why we're doing this.

Like why we do all this work, what impact are we hoping

to have in the world through Svelte.

And what we realized was the thing that we kept coming

back to, the thing that I for one am particularly motivated

by is this idea that most software just isn't usable.

Like most software in the world sucks.

Software is everywhere, it's ubiquitous.

Like everything in life nowadays is mediated through

software and collectively we have done a terrible job

of writing software.

You just think about the number of times you see

inscrutable error messages or--

- Blue screens.

- Blue screens, blank screens, I pick on GitHub a lot

because that is probably the piece of software

that I spend most time in.

- Right, yeah.

- And it's not good, there's a lot about GitHub

that is really not good.

And there's reasons for this and the reasons

that we're all reasonable and it's not because

people don't care, it's not because people aren't trying.

But it's a problem nonetheless.

And so our North Star, we concluded, should be about

helping people make better software that doesn't have

some of these reliability issues and so on.

And so the talk was really about how we arrived

at that conclusion and what it means in practical terms

to orient a project around those goals.

- Yep, cool.

So that kinda ties in a bit to error boundaries, I guess.

Like a way of handling errors and not bricking

the application when something goes wrong.

Like imagine if you're, I don't know,

you're at a ticket kiosk and you're buying a ticket

and for some reason the application is a JavaScript

application and it just errors and nothing's happening

when you click the screen, that's not good.

So yeah, that's nice.

All right, I think we've gone through all the talking points

that we have here.

There's just the two last sections left,

hot takes and picks.

So let's start with hot takes.

Do you wanna go first or should I?

- Sure, my hot take is a meta hot take.

It's that there should be more hot takes.

There's a little bit too much resistance to openly

being critical of each other's work, I think, online.

Which isn't to say that I think we should all be mean

to each other, I don't.

I think that one of the things I like about our community

is that everyone is, in general, pretty friendly

and respectful towards each other.

But I don't think we have enough willingness to say,

you know what, this thing sucks, this idea sucks.

- This is wrong.

- I personally relish it when someone comes along

and makes a reasoned argument about why something

that I've worked on sucks.

Because that's how we can make things better.

And we tend not to do that, we tend to shy away from that

because we don't wanna hurt people's feelings,

which is understandable and admirable.

But ultimately, if we're gonna get better as an industry

at our craft, then we need to get better

at telling each other when stuff sucks.

- Yeah, all right.

I do wonder, though, if that actually is a hot take.

'Cause it's kinda like, it probably is,

but I also feel like it's like common sense as well.

- I mean, I think it's common sense,

but it's common sense that is not very common.

Like, a lot of people just don't seem to wanna do that.

And I think a lot of times as well it's because

people aren't all that confident in their positions.

Like, sometimes if I see something and it seems not great,

then my first instinct is like, oh, it's probably me,

like I'm holding it wrong.

- Right, right.

- And so there's a little bit of a reticence to say,

hang on a minute, this is--

- Is this really right?

- This is bad, you know, you don't wanna do that

and then it turns out that you're the idiot.

- Yeah, I feel like that happens to me a lot.

I always have weird opinions and I'm like, oh, wait,

I was using it wrong.

Happens a lot.

All right, my hot take is that SQLite is the best database.

I use it specifically synchronously as well,

which is kind of different, I guess.

Well, for SQLite, I don't think it's that weird,

but fetching data from a database synchronously

is probably not the most common thing.

I think more people should use SQLite.

I've had great fun using it for the new

Roosevelt Society website that's coming up soon and yeah.

I think that's it for my hot take.

Maybe it's not a hot take either, I don't know.

- I mean, I think everyone loves SQLite.

I think it'd be hard pressed to find someone

who doesn't think SQLite is great.

Maybe the hot take is that you're using a database

that intended to be used in like embedded devices

instead of using a traditional database server,

like you're using SQLite over Postgres

even though you're building something that is web scale.

- Yeah, yeah, yeah, always on Hacker News, right?

Someone posts something and you're like,

oh, but how will this scale to one million users?

I'm like, nah, you don't need it, it's like, it's not,

you're not gonna have one million users.

It'll be fine with SQLite.

Yeah, all right, picks.

- I have two picks.

My first pick is Blue Sky.

- It's having a bit of a resurgence at the moment.

It's nice.

- It really is.

So at the time of recording,

Blue Sky had just passed 20 million users.

It has been consistently adding like a million users a day

for the last several days.

- That's awesome.

- Which is, yeah, I mean, I joined sometime early last year.

- Yeah.

- I was a relatively early user.

- Felt completely dead for a long, long time.

- Felt completely dead.

I think I was one of the first 40,000 users,

which now that it has 20 million users

feels like I was pretty ahead of the curve.

But the reality is, I just squatted on a handle

and then ignored it for a long time

because it didn't feel like a lot of conversation

was happening there.

All of a sudden, basically all of the people

that I wanna hear from are on Blue Sky.

- It's like Twitter, but without all the Twitter.

- Yeah, it's Twitter without all the Twitter,

Twitter without Elon in particular.

And it's nice.

Like, a lot of people, the timing of this

was obviously around the US election.

Like a lot of people were just very mad at Elon Musk

because of his involvement in the US election

and moving to Blue Sky was sort of an act of protest.

But regardless of the catalyst,

because it's so based around network effects,

it kinda doesn't matter why it's happened.

But the fact that it's happened

is reason enough for it to keep happening.

And for a long time, I was a total Twitter addict.

Like, I was like on Twitter all the time.

Even if I wasn't posting,

I was just like mindlessly scrolling.

And I tried a bunch of times to just quit

because I know it's not healthy being on there.

But I couldn't because it's like heroin.

Well, it turns out Blue Sky is like methadone.

It's the thing that has,

like, I no longer have a Twitter addiction.

- Right, now you have a Blue Sky addiction.

- So this is the thing about Blue Sky.

It is so much better and healthier

than Twitter in a lot of ways.

But it is also not, like, Twitter is like crack.

I just couldn't get--

- I mean, it's also--

- I guess I've compared it

to two very, very destructive substances.

But the point I'm making is that you go on Twitter

and it's gonna tickle the outrage sensors in your brain

in a way that you just keep coming back from.

Blue Sky doesn't really have that.

Like, it doesn't reward the sort of engagement bait

that you see on Twitter.

And that's such, even though I like being there a lot more

and I check in on Blue Sky probably multiple times a day,

I don't feel, and my thumb doesn't naturally gravitate

towards the icon as soon as I turn my phone on,

which it did with Twitter.

- Same for me.

- I mean, maybe that'll change.

Like, a lot of people are like,

"It's gonna go the same way that Twitter went."

- I don't think so.

- Yeah, I mean, it's being designed specifically

to avoid some of the things that happen to Twitter.

But even if it does, like, I will take the possibility

of future shittiness over the guarantee

of present shittiness.

- Yeah, I mean, yeah, Twitter is crap, right?

It's really bad.

I recently found out that there's, like,

you can actually use different feeds in Blue Sky.

- Oh, yeah.

- I had no idea about that.

And that's, like, a great feature.

And also, the fact that it's chronological by default,

I think, is good.

'Cause that's one of the dumb things about Twitter,

like, also makes you, there's this never-ending scroll

of seeing new content all the time, and ugh, yeah.

I wish I could delete it, though.

But there's still a lot of folks on Twitter.

- There are for now.

I mean, I haven't deleted my Twitter account,

partly because, you know, I'm candidly hedging my bets.

Like, maybe this thing doesn't work out,

and everyone moves back to Twitter,

and if everyone else moves back to Twitter,

then I'm gonna do the same.

Because I wanna be where my friends are, honestly.

Partly it's because when people delete

or deactivate their accounts,

anything that they've posted in the past,

like, if it's embedded somewhere, that vanishes.

So there's a lot of holes in dev.to articles

all of a sudden, stuff like that,

which, as someone who cares about

the archival properties of the web,

it would feel very hypocritical for me to do that,

because I know that, in some cases,

my tweets are those end breaks.

But also, like, I won't be able to refer back

to thoughts that I've had in the past,

and conversations that I've had in the past,

because, you know, sometimes I'll remember

that I had a conversation with someone,

and there was a link that was shared,

and I wanna be able to go find that again.

And if I destroy that archive,

then it's gonna be a lot harder for me to do that.

So I'm keeping it around.

Also, you know, the Svelte accounts

have way more followers still on Twitter.

And even if a lot of those followers are illusory,

they're bots, or they're inactive, or whatever.

- Still a lot of people following them, yeah.

- You know, it would be irresponsible

to delete those accounts, but.

- It's funny, by the way, when,

I think the Svelte Society account,

no, it was the Svelte site that added the blue sky link.

- You did, yeah.

- And some people were outraged because of,

like, the, oh, you removed, oh, this is so woke.

- The Svelte Society removed the Twitter icon

and put the blue sky icon there, because they're woke.

So, first of all.

- There was no Twitter link.

- First of all, I'm begging you to define that word.

Absolute numskulls.

But second of all, yeah,

we never had a Twitter link in the first place.

- It's so funny.

- Yeah.

- Oh, well, it is what it is.

- Yeah.

- All right, your other pick.

- My other pick, I'm reading a book at the moment

called Lifespan by a chap named David Sinclair.

- That name sounds very familiar.

- Yeah, so it turns out he's quite a well-known guy.

I didn't know about him until fairly recently.

He was in Brooklyn for an event at a place

that we like to go to from time to time.

And it was a sort of a panel discussion

on the topic of longevity, which, I don't know,

I guess I've had a passing interest in longevity.

I think it would be cool to be able to live

a healthier life for longer.

Like, I like being alive.

I would like to keep being alive for as long as I can.

- I think that makes sense.

- Yeah, and this guy, apparently a lot of people knew this.

Apparently this is like a very widely read book.

He has a theory on why we age

and by extension, why we suffer diseases

like heart disease, cancer, Alzheimer's.

A lot of things are all fundamentally driven

by the same mechanism, which is aging.

I'm not a scientist.

I'm not qualified to know if this is now a mainstream view.

But the idea is that aging is a result

of an information breakdown in the epigenome.

And then you can repair that.

You retain all of the genetic information

that you need to create new young cells.

- Right, yeah.

- But it's the stuff around the genome

that starts to break down and results in aging.

And science is starting to uncover ways

that we can inhibit or even reverse that process.

- Yeah.

- And so I've been learning about where we are

or at least where we were when this book was written,

which I think was about five years ago.

So after I finish reading it,

I'm gonna try and catch up on the latest science.

- Right, yeah.

- And where we might be in the very near future

once a few of the clinical trials that have been underway

either turn up some results or don't.

Like, maybe--

- Maybe we can live forever.

- Maybe we can live forever, but even if we can't,

there's some tantalizing ideas about a pill

that can cure blindness and things like that, which--

- I mean, it's interesting.

I recently read about this thing

where you can, so basically, where I'm from,

there's this medical university,

and they've developed this method

of working with stem cells, basically,

to kind of, basically what you do,

they extract these stem cells from donors,

and then you can get a shot with stem cells

like into a joint or something if you have arthritis.

And then the idea is that the stem cells

are gonna regenerate the tissue and stuff like that.

I guess that's kinda, maybe not exactly longevity.

I guess it's longevity focused,

but it's kinda like repairing tissue damage in a sense.

- Yeah, it is-- - I just find it

super interesting.

- It seems like a different approach

to solving-- - Yes, yeah, yeah, exactly.

Like, fixing issues after the fact,

maybe rather than before, I don't know.

Super interesting.

All right, what is my pick?

My pick is gonna be Silo season two.

So Silo is a TV show based on a series of books.

I don't remember what the books are called.

I think the first one's called Wool?

Anyway, it's a good TV show.

It's about a bunch of people living in a silo,

and it's like a dystopian kinda sci-fi thing.

- So I watched season one, and it started out really strong.

By the end of it, I was like, "What is going on here?"

- They really lost me, but people have been raving

about episode one of season two.

Should I give it another chance?

- I would, I would.

But then I really liked even the end of season one,

so I would give it a go.

- All right.

- So yeah, I think it's great.

And also, the main character, the actress is Swedish, right?

So I had to support it.

- Oh, she is?

- Yeah.

Yeah, so that's my pick.

And with that said, I guess we're done.

Thanks for doing the interview with me again.

And thanks for having me over here.

- Always welcome.

- And yeah, where can people find you?

Not on Twitter, but maybe on--

- Blue Sky, @rich-harris.dev.

- Yeah, awesome.

All right, and with that said,

thank you everyone who is listening,

and we will see you next week.

Bye bye.

- Hey, it's Kev here.

If you like the show,

please drop a review on your favorite podcast player.

It would help out a lot.