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