(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.