Rich Harris joins this week's episode. They dive deep into the world of web application performance, signals, and the capabilities of Svelte 5. Join them as they explore the innovative features of Svelte 5, its compiler capabilities, and its potential impact on application building. From discussing the fastest mainstream framework to drawing parallels with traditional compiler optimization modes, they leave no stone unturned in dissecting the advancements in Svelte 5. Stay tuned as they also explore topics like React server components, the controversy around embedding SQL in React components, and much more. 

Sponsors

Charles Max Wood [00:00:06]:
Hey, folks. Welcome to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards.

Steve Edwards [00:00:14]:
I'm gonna step in for AJ and say, yo yo yo coming at you from a sunny and blue Portland.

Charles Max Wood [00:00:19]:
We also have Dan Shapiro.

Dan Shappir [00:00:22]:
Hey. From a warm and sunny Tel Aviv. And here we lost Steve.

Charles Max Wood [00:00:27]:
Right. Nice, sunny. There he goes. Hey. Charles Max Wood from Top End Devs. Couple of quick things. One, I'm looking for work. So if you wanna hire me to help you with podcasting or with programming, let me know.

Charles Max Wood [00:00:40]:
Chuck@topendevs.com. And then I'm also launching JavaScript Geniuses this week. So go check that out at javascriptgeniuses.com. I usually hold that to the end, but I anyway. We have a special guest this week, and that is Rich Harris. Rich, do you wanna say hello?

Rich Harris  [00:00:56]:
Hello from Brooklyn, which is not sunny at all today. It is in fact quite gray out there.

Charles Max Wood [00:01:03]:
Yeah. So, you know, I think everybody knows you as the guy behind Svelte.

Dan Shappir [00:01:10]:
I

Charles Max Wood [00:01:11]:
think that's the big thing. Are there any other things that people ought

Dan Shappir [00:01:13]:
to know?

Rich Harris  [00:01:18]:
I Rollup. I was the original creator of Rollup, although I haven't been maintaining it for many years. It was taken over by, by Lucas who has been a much better maintainer than I ever was, and it's really since then that it's become this sort of essential piece of the JavaScript ecosystem.

Dan Shappir [00:01:37]:
Yeah. It's part of Vite, isn't it? Like, Vite is kind of built on top of it.

Steve Edwards [00:01:43]:
Although

Dan Shappir [00:01:43]:
amazing.

Steve Edwards [00:01:44]:
It just came out that Vite is starting to write their own tool for that based on Rust so that that they can sort of have complete control over that portion of their process. But, yeah, till now, it has been part of Beat.

Charles Max Wood [00:01:55]:
Dan invited you, and I don't know if he had something in particular that he wanted to go into first. Or

Dan Shappir [00:02:03]:
I'll start with a story because I know that's what you like, Chuck. Oh, yeah. I got a story. Yeah. It's something we spoke about a little bit before the we started recording, which is about the first time that I actually met Rich in person. And that was at the conference called YGLF or You Gotta Love Front End Mhmm. Where, Rich gave what turned out to be like a seminal talk, kinda blew my mind at the time. And the name was, rethinking reactivity.

Dan Shappir [00:02:34]:
Right? That's the name. And it was right when you introduced Svelte 3, which kind of turned everything on its head in a in a lot of ways. And now it seems that you're about to do it all over again, with, Svelte 5 and runes and, you know, you tell us. So I thought it would be a great opportunity to kind of speak with you again and and listen to what the new hotness is going to be.

Rich Harris  [00:03:06]:
Yeah. You you could say that we're rethinking rethinking reactivity. You know, we we had a we had a lot of really, interesting ideas with with Svelte 3. The idea was to see how far you can take a compiler centric framework design and push that in order to have, like, this really idiomatic way of of a reactive user interface. And a lot of it really succeeded. Like, people, it turns out, love this style of authoring components. And we got it to, you know, to to power some really large and complex applications, And people have had a great time working on it. People had a great time building stuff with it.

Rich Harris  [00:03:50]:
But as the years have gone on, we've started to, like, butt up against the limits of what you can do with static analysis. And at the same time, there's been this, renaissance of the idea of signal based reactivity really spearheaded by the solid team, taking ideas that were, like, first being explored in the JavaScript world in, like, around 2,000 and 9, 2010 maybe with knockout and bringing that into the modern era. Nowadays, most frameworks are using signals through their reactivity. Svelte was really one of the 2 odd odd people out. Svelte and React both doing things very differently to everyone else. And, essentially, we decided to fall in line. We decided that it's it it signals all the right primitive to build a a reactive framework on top of, but we have a slightly different relationship with them than other frameworks. And so I guess we can get into what I mean by that, over the course of this podcast.

Rich Harris  [00:04:56]:
But, essentially, we are rewriting Svelte from the ground up. It's gonna be the same authoring experience that people are familiar with to a very large extent, but it's gonna get rid of the rough edges that people have found with the old static analysis based reactivity. And I'm pretty excited about the things that we're able to do now on top of this new foundation.

Charles Max Wood [00:05:17]:
I think a good thing to do just for folks that aren't as familiar, can you just give people, like, a really short explanation of what signals are? And then and then you can explain what Svelte is doing and why you're changing it.

Rich Harris  [00:05:31]:
Absolutely. So the idea of of signals is that you have an object that represents some value that is changing over time, And then you have other parts of your code base that read those signals. And then you have a scheduler that is sort of aware of which functions are running and which functions are reading these reactive values. And so when those reactive values change, the scheduler is able to re execute that code to, for example, keep a text node, up to date with some piece of state that has changed in your application. And where signals differ from, some other related, primitives like observables is they're very effective at making sure that your code runs in a efficient and glitch free manner. The code that relies on these reactive values doesn't overfire. It never fires prematurely. Everything just kind of flows in a very natural way down from your reactive state down to what we call the effects, which is the DOM updating in response to that state changing.

Rich Harris  [00:06:39]:
And by by building on top of signals, we're able to achieve this very surgical approach to updating the page instead of having to rerender things frequently or having to to do a lot of checking to see if things are dirty or not. We can just sort of let the reactive graph do its thing

Dan Shappir [00:06:58]:
Mhmm.

Rich Harris  [00:06:58]:
And things naturally update and and the optimal fashion.

Dan Shappir [00:07:02]:
So you mentioned Solid before, and, of course, the guy who created Solid, Ryan Coronado, sometimes people refer to him as the CEO of signals. Mhmm. And he, we had him as a guest several time on the podcast. And he likes to say about the solid that solid is effectively a state, management framework, which happens to update, the user interface or the DAW. It's almost like a side effect of what it is. Is is, your approach with, Svelte or Svelte 5 kind of similar, or is it more you're just leveraging signals but still very much staying, you know, front end framework?

Rich Harris  [00:07:49]:
So I I think the outcome is is essentially the same, but we are approaching it from very different directions. Ryan and I, we have almost opposing approaches to a lot of, a lot of problems. Ryan is really incredible at thinking in terms of primitives and how those primitives fit together, and Solid is just this really elegant example of that. We have these primitives that represent these reactive concepts, and they they tie together in in a really beautiful way. Whereas on the Svelte team, we tend to sort of work backwards from what we want the authoring experience to be like. And so, you know, we we have this idea of what it should what should go into a web framework, like, what features are involved in creating a user interface. And from there, we we work backwards to what do we need to implement for that to work. And they kind of meet in the middle.

Rich Harris  [00:08:45]:
These two approaches meet in the middle, but we we have these slightly different emphases. And it's actually, I think, really healthy to have, 2 projects like these in the same sphere because we can sort of bounce off each other a little bit and learn from each other a little bit, but also give people multiple options for how they want to build their applications based on their preferences. I I think one interesting way in which we have sort of converged on that idea of it being a state management system with, you know, DOM manipulation bolted on on top is that previously Svelte was a component library, essentially. Kind of builds the same niche as React or Vue or something like that. But with Svelte 5, we're introducing this idea of universal reactivity. And so, whereas previously you had this sort of magical reactive behavior inside your components, but then as soon as you needed to write code in JavaScript, you were sort of left out in the in the boring old black and white world of of normal JavaScript. With Svelte 5, you can take your reactive constructs and you can bring them into your JavaScript modules and your TypeScript modules so that we no longer have this nice, exciting, reactive world inside components and then the the world outside. It's all one thing.

Rich Harris  [00:10:07]:
And we've done that by, It's all one thing. And we've done that by kind of bringing reactivity into the language itself rather than by exposing these primitives for people to use.

Charles Max Wood [00:10:21]:
So, functionally, then if you're writing Svelte in Svelte 4 versus Svelte 5, how is it gonna feel different? How how is it gonna look different?

Rich Harris  [00:10:29]:
So the most obvious example would be, would be how that you how you represent state in a component. In Svelte 3 and 4, somewhat famously, if you have a variable that needs to update and you want to have your component update in response to that changing, then you would just declare it using let or var. So you might have let count equals 0. And then inside a click handler, you might do count plus equals 1. So you click on a button that invokes that handler and then wherever count is referenced inside your template, it will update. And that's still true, but now instead of that just being automatically reactive, you do let count equals dollar state parenthesis 0. And what that is is an instruction to the compiler, we call it a run, that is telling the compiler of this piece of state right here or this variable count is a reactive piece of state. It's gonna be part of the reactive graph that you need to track.

Rich Harris  [00:11:27]:
And when it updates, everything that depends on it is also going to need to update. So we've made things a little bit more explicit. And in return, you now have code that is super easy to refactor. It can be moved between components or outside of components. Multiple things can reference the same reactive primitives, throughout your application. And it it really gives you a lot of flexibility and power in how you define the, like, which parts of your application are reactive and which parts are not.

Steve Edwards [00:12:00]:
So when you talk about state, you know, I I'm a primary Vue developer and haven't done a lot of of Svelte. I'm thinking of, you know, Vuex or where you have a separate state. You know, I think it's, what is it React uses for state management? I forget. Redux or Yeah. Redux or something like that. Okay. So is this is am I understanding that this is as simple as you do declare a variable with your your rune inside a component? Is it automatically available in other components without having a separate library like a Redux or a Vuex to manage that, or or how is that working?

Rich Harris  [00:12:35]:
Yeah. So you can you just use that inside a dot Svelte file, which is where you off your components, you can put it inside a dot dot svelte.jsfileor.svelte.tsfile, and then you can just export that and use it in the context of other components. It's pretty unlikely that you would need a full blown state management library, because it's all just kind of built in, and you can pass these things around as as component props, and you can, you know, pass them into functions and and so on. And, you know, with that, that idea of state management just kind of falls out naturally from the way that, the way that Svelte is is designed. It's pretty unlikely that you're gonna need to have a state management library on top of that. That. The the one exception that I would maybe consider worthwhile is if you had some complicated logic that you wanted to model as a state machine. Like, we don't have a state machine primitive built into the framework, but it's really easy to build those sorts of abstractions on top of the runes that you get with the framework.

Steve Edwards [00:13:35]:
So how do you handle mutability issues then? So, you know, it seems to me if you're just you're declaring a state variable in one of your svelte dot whatever files. Right? And then you've got it available somewhere else. Maybe you mutate one place, and it misses up something somewhere else. Whereas, you know, I'm used to the Vuex pattern where you have state actions and where you commit your changes. I can't believe I'm blanking out on it. You can control where the mutability happens, where the actual changes happen so you're not accidentally mutating something somewhere else. And it seems like you could just have a variable. Okay.

Steve Edwards [00:14:11]:
Here it is. Now it's available over here. You could actually mutate it in another place and you're screwing up where you really don't wanna meet you know, affect your first, template.

Dan Shappir [00:14:20]:
Does that

Rich Harris  [00:14:20]:
make sense? So it's it's up to you how you expose the the state that you create to other parts of your application, and there's a few ways that that that that manifest. If you define some state inside a component and you pass it down to another component as a property, then if that component tries to mutate that state, we will actually say, hey.

Steve Edwards [00:14:42]:
You you

Rich Harris  [00:14:43]:
shouldn't be doing this. And the way that we do that is we have this concept of ownership validation. So if one component, say component a, owns a piece of state and it passes it down to component b, component b then tries to mutate it, it will say component b is trying to mutate some state that it does not own. That state was created in component a. And if you want component b to be able to mutate it because actually it's very often quite useful, like if you're building something, you wanna break it up into multiple components, then it's kinda useful if they can all share ownership of a piece of state. And the way that we do that in Svelte is with bindings. Instead of just passing a property down to a component, you can pass it down as a binding and then that effectively gives the child component read, write access to the original piece of state.

Steve Edwards [00:15:30]:
So is that sort of, like, passing something by reference? You know, like, in PHP, you talk about how you pass something where it's just you can just see it versus you can actually mutate it, you know, when you

Rich Harris  [00:15:40]:
In in terms of mechanics, no. But in in terms of, like, conceptually, yes. That's exactly what it is. Okay. You're you're you're literally passing ownership of the same piece of state, as opposed to giving someone else a a read only view of it.

Steve Edwards [00:15:53]:
But you have to specifically declare that possibility?

Rich Harris  [00:15:56]:
On both sides. Yeah. So the the component needs to say, this is something that I wanna mutate. This needs to be, a bindable property, and then the the consuming component needs to actually invoke the the binding with the like, so so where you pass in a prop, you do bind colon count equals count instead of just count equals count.

Dan Shappir [00:16:18]:
So so here's the thing about it. And and I've encountered it in the context of Solid, where, you know, Solid is kind of deceptively similar to React in the way that it looks because it uses JSX and and the syntax looks, very, very similar. But then you realize that the concept of components in in solid is much more diluted than it is in react. Because in react, components are really, self contained. And and you really need to be explicit about how you pass stuff into them or out of them. Whereas in solid, you can share signals around or you can put signals totally external to components. And and therefore, components just kind of become, a unit of code rather than necessarily a unit of of, of rendering or of logic. How how does where does Svelte kind of stand in this regard?

Rich Harris  [00:17:27]:
If if anything, we've taken that idea to its logical conclusion. So some years ago, I wrote a blog post called virtual DOM is pure overhead. Oh, yeah. This this was so this was about not

Dan Shappir [00:17:38]:
for professional at all.

Charles Max Wood [00:17:39]:
You made people cry, I'm sure.

Rich Harris  [00:17:42]:
Yeah. So it's yeah. This is about, trying to correct some misconceptions that people had about React's rendering model and and whether it was, you know, faster than the real DOM or whatever. The the details of of that aren't so important. It was just that this x is the new overhead became sort of a a a a a baton that I could later be head with by Ryan who wrote an article called Components Are Pure Overhead. And so it's become this, this fun little meme. I think there's a quick blog post somewhere called hydration is pure overhead and and so on. And what components of pure overhead was arguing was that, you know, a lot of frameworks, as you say, have this idea that a lot of the stuff lives in the component.

Rich Harris  [00:18:24]:
And in React, you you don't call a function. You do like React dot create component, and then you pass in the component constructor. And then when that component is is rendered, there's all of this bookkeeping that happens so that, like, all of your hooks belong together and, you know, so on. Whereas in Solid, it's it's a lot more kind of transparent. Like, a a component can literally just return, the result of calling document dot create element, and that's that's totally legitimate in in Solid. And that was, you know, a a really smart blog post. And Svelte 5, I think, is probably the purest expression of that idea because in Svelte 5, components are literally just function calls. If you have, you know, angle brackets, capital f, Foo to create a Foo component in your inside another component, The compiler takes that, and it turns it into a function call whose callee is just the Foo function and whose first argument is the the anchor node that it should be prepended to, followed by an object of of properties.

Rich Harris  [00:19:27]:
And there is a little bit of bookkeeping that happens in Cy components. You know, we we push onto a stack so that we can have a context API, for example. And for some life cycle purposes, we we keep track of when effects are running so that we can control the timing of effects because we think it's very important that things run-in a certain predictable fashion. But there's almost no work happening when you create a component. And it was really Dominic Ganaway who opened my eyes to to the power of this when he, joined the team and had been working on, an experimental framework of his own called Octane. Sort of showed that if that's what your components are, if they are literally just function calls, then tooling can take that and it can inline some of those function calls. And it can really be smart about minimizing the overhead that is involved in composing multiple components together. And so, you know, Ryan was right, and we have absolutely no shame about stealing the best ideas from other frameworks, and Matt is no exception.

Dan Shappir [00:20:29]:
So components are really just a method of organizing code rather than having any, runtime is what you're saying if I'm understanding you correctly, or hardly any runtime consequence.

Rich Harris  [00:20:43]:
That is, yeah, that is sort of the the north star. There was the the talk that you referenced earlier in in this podcast, Rethinking Reactivity had a slide in which I said frameworks are not a tool for organizing your code. They are a tool for organizing your mind. And, I don't I don't think Svelte prior to version 5 really lived up to that, but now I I think we we really are. Like, how you author your components and how that manifests in terms of, the code that gets actually executed in the browser, like, they don't need to be the same thing. You can you can optimize things by, by treating them as something other than than how you wrote them, if that makes sense.

Dan Shappir [00:21:31]:
So going back to the practicalities, you said that if I want to create a reactive value in Svelte 5, instead of just doing let counter equals 0, I do let counter equals dollar state 0. First of all, it's interesting that you put dollar at the front rather than at the end, like, solid and quick. I actually approve. I like dollar in front because I think it makes it clearer. Right, you don't need But

Rich Harris  [00:22:00]:
it just means you hit the dollar key and then you see a drop down list of all of the rooms that are available to you.

Dan Shappir [00:22:06]:
Yeah. That's there's that, obviously. Also, the fact that just when you read the code, it's up front. You don't need to read the entire word to realize that, that it's not, you know, just a regular function. And and I'm guessing it even makes parsing simpler because you see dollar upfront and, you know, you don't need to, like, put, you know, put it aside. My question is actually different. What happens if I have old Svelte code that just has let counter equals 0? Will my counter stop being reactive? Will I need to do a global search and replace across my entire code base? What happens?

Rich Harris  [00:22:48]:
This is an excellent question, and I'm very happy that you asked it. The answer is it will continue to work. We have spent a lot of time making sure that Svelte 5 is as backwards compatible as it possibly can be. In fact, the first thing that we did when we started working on this code base was we ported over the Svelte 4 test suite. And so as we've been building Svelte 5, we've been building it against that existing test suite. So, essentially, there are 2 ways that you can write a Svelte component now. There's what we internally call legacy mode. I I guess it would be nice to call it classic mode or something like that so that people don't feel like their their code is is now technical debt.

Rich Harris  [00:23:27]:
And then there is rooms mode. And you can opt into rooms mode explicitly by setting a compiler flag, but, really, the way to do it is just start writing rooms. If you have a room in your component, then the compiler will opt you into rooms mode, and then you'll get the new style of reactivity. But if you don't do that, if you have an existing component or if you're using a library that was built for Svelte 3 and 4, then even though the mechanics under the hood is still signal based, it's using this modern ultrafast system, The authoring is exactly the same, and it's very important to us that people are able to migrate their applications incrementally. You can upgrade from Svelte 4 to 5. Everything should, in theory, keep working. And then as you have time, you know, new components will be in rooms mode, you can gradually migrate your old components to rooms mode to take advantage of some of the new features. But it's a very important question, and I'm very glad that you gave me the opportunity to answer it.

Rich Harris  [00:24:27]:
This is something that we take very seriously.

Dan Shappir [00:24:29]:
So I now have a new role for components in Svelte. They're a unit of versioning of Svelte. Basically, if I'm understanding you correctly, you're saying if I in my component, I had let x equals 1 and let y equals 2 or both of them are reactive. But now if I do let x, change just the x, let x equals state a dollar state 1 and leave the y as it is, x is still reactive, but y is no longer reactive.

Rich Harris  [00:25:01]:
That's right. You you need to migrate the entire component to rooms mode. Otherwise, things will stop working. We plan to offer some automated migration tools to make that a little bit, easier for folks. Although at our current stage of development, that's not our top priority. But before we have a stable, then that will be something that we offer.

Steve Edwards [00:25:23]:
So who is the fantasy fan that named things Runes? Is that you or is that, somebody else?

Rich Harris  [00:25:30]:
So I, I I have one of one of these guys. The, this is the the meta quest 3. Mhmm. And on there, there is a game called Ragnarok.

Steve Edwards [00:25:42]:
Oh, yes.

Rich Harris  [00:25:43]:
And and Ragnarok drumming 1? It is the drumming 1. So the like, I'm sure a lot of people are familiar with games like Beat Saber.

Steve Edwards [00:25:50]:
Yeah. Yeah.

Rich Harris  [00:25:50]:
These are the rhythm games where you have sort of things flying at you and you need to Right. Bat them away or punch them away or or like simulate playing some sort of musical instrument. The shtick of Ragnarok is that you are, the the drummer on a Viking ship, and you need to motivate your rowers to row faster to Valhalla by smashing the runes as they come past you, and you have these drums in front of you. It is so I I don't play a lot of video games. I I I don't I I wish I'd had enough time to, but I I don't. I love this game so much. It is incredibly fun and a really good workout. And so one day, you know, we're we're we're thinking about what what can we call this concept? What is a good name for something that is it's sort of like it's a magical symbol.

Rich Harris  [00:26:34]:
It you're adding some you're invoking some magic within your code, and and it's it's changing the nature of its surroundings. We want a word that is memorable that a lot of people would associate with with that sort of thing. Ideally, a single syllable, and that is what we we we settled on. And the idea very much came from this stupid game where you have to make your Viking rowers row faster.

Steve Edwards [00:27:03]:
A funny story. I mean, when I think of elf runes, I think of Lord of the Rings because they're mentioned quite a bit

Dan Shappir [00:27:08]:
in Morven runes.

Steve Edwards [00:27:10]:
Or or runes. Yeah. Anyway, I thought it was elf.

Dan Shappir [00:27:14]:
Anyway The elves have an elvist script.

Steve Edwards [00:27:16]:
Right. Okay.

Dan Shappir [00:27:17]:
Ruins and elvist script.

Steve Edwards [00:27:19]:
Sorry. I failed in my LOTR terminology. But you talk about Ragnarok a couple years ago. My company were remote, and we had a a get together in Arlington and Washington DC area. And for a fun activity, we went to a place that uses the Quest MediQuest headset. It was a whole VR experience. This little it was down in a basement, and we had a couple hours to play games. And I came out of there sweating like a pig and had a killer workout, but the first game we played for probably a half hour was Ragnarok.

Steve Edwards [00:27:48]:
And so, yeah, I was that was just crazy just trying to keep up. There's, like, 5 different levels, you know, and the first level was, you know, pretty straightforward. You get to level 5, and it's like, you know, a drummer for a rock band. It's just some of the craziest, rhythms that you have to try to keep up with. And it has you're on the ship, and you're racing with each other. And the faster you go, the faster your ship goes as compared to the other people. And, there are circles coming at you, and you have your, you know, your actual it looks like, drumsticks in the video game, and you have to hit on the ones with the x or however they mark them to get the right rhythm. And so the more accurate you are, the better your score is and the faster your ship goes.

Steve Edwards [00:28:26]:
But, man, it's a workout. And it's really a ton of fun too. It's a lot of, heavy, yeah, heavy rock type music for sure.

Dan Shappir [00:28:32]:
I actually have a son who's a professional drummer, so maybe I

Steve Edwards [00:28:35]:
should probably do that. Yeah. He would do well with that. Me, not so much.

Charles Max Wood [00:28:40]:
Does it play on the ocular or the ocular MediQuest? Whatever. Does it play it on the quest too? Because that's the one I have.

Rich Harris  [00:28:48]:
Yeah. It does. It does. Okay.

Dan Shappir [00:28:51]:
Going back to Svelte.

Steve Edwards [00:28:55]:
This is directly relevant. You know that.

Dan Shappir [00:28:57]:
Yeah. So we we spoke about one room, which is a dollar state. What are the other rooms?

Rich Harris  [00:29:05]:
So there's the the 3 rooms that form the sort of holy trinity of reactivity, which is state derivations and effects. State creates the what are sometimes called the sources. Derived, dollar derived is the second rune, which creates a value that is, derived from state. So, you know, obvious toy example would be you've got let count equals dollar state 0. Let doubled equals dollar derived parenthesis count times 2. And it's a little bit different to, other frameworks. If they have a computer primitive, then typically you will pass in a function that returns a value. You can do that with, a Roon called derived dot by, but typically, you'll just use derived by itself.

Rich Harris  [00:29:53]:
And you pass in an expression, and that expression becomes, reactive. And we do that to discourage people from writing side effects inside their derivations, which is, you know, bad news bears, but it's like a a trap that people will fall into quite often. And it's also just, like, more concise and nicer to look at. And, these derived values

Dan Shappir [00:30:16]:
to be a compiler.

Rich Harris  [00:30:17]:
It is. It is. It absolutely is. We we say this a lot. Every time we're weighing up different designs, we're like, well, what what can we do that everyone else can't? Because we don't have the same constraints. And being a compiler

Dan Shappir [00:30:30]:
has to do true anymore. I mean, everybody's become a a compiler these days. Even React

Rich Harris  [00:30:36]:
It it it's it's true, but, like, a lot of a lot of frameworks are using compilers as kind of like an optimization step, but they're, you know, they're religious about not allowing the compiler to change the semantics of the code. Whereas we sort of take this view that changing the semantics of code is is exactly what frameworks are for. Like, all frameworks are changing the semantics of code. You know, hooks don't behave like normal functions, like these sort of functions that remember what the value was the last time you called them. That's weird. Angular has these things called zones where, like, if you do something inside a set time out, like, it will track the stuff that happens inside the set time out. That's weird. That's changing the semantics.

Rich Harris  [00:31:25]:
You know, view does a lot of stuff with property assignments because everything is a proxy. That is also kind of weird. And we just draw the line in a slightly different place. We say, it's okay to change the semantics as long as we're doing it in a clearly understandable way that improves the authoring experience without sacrificing user experience. And so, yeah, being a compiler just it gives us this this broader design space, and it it gives us a slightly different mentality when, when we're figuring out the best solutions to various problems. And so dollar derived is is one example. It's just a nicer way of declaring derivations than exists in other reactive systems.

Dan Shappir [00:32:10]:
And the third one?

Rich Harris  [00:32:11]:
The third one is the effect rune, which basically just defines a piece of work that happens when some arbitrary dependencies change. A good example would be you have a canvas element and you want to draw something to that canvas. You can't really do that declaratively using, using markup because that's not how canvas works. So that is a case where you would have to use the the escape hatch of being able to write imperative code inside an effect. Anything that you reference inside the effect, if it's a reactive piece of state, then when that changes, the effect will rerun. So, you know, if inside that canvas effect, you have canvas dot fill style equals color. And then color is a piece of state that changes or it's a property that's passed into the component and that changes, then that effect will rerun. But what you don't have to do is explicitly tell the system which things your effect depends on because this is the beauty of signal based reactivity.

Rich Harris  [00:33:17]:
It will just figure that out for you. That's the whole purpose. So So

Dan Shappir [00:33:21]:
similarly with the with dollar derived. So I guess

Rich Harris  [00:33:24]:
Exactly. Yep. So

Dan Shappir [00:33:27]:
you basically analyze the code inside that rune, identify which signals it depends on, and then automatically update execute it whenever any of these signals changes.

Rich Harris  [00:33:44]:
Yes. So that this all happens when the application is running, and this is the big difference with Svelte 3 and 4. In Svelte 3 and 4, we would actually look at the code that you wrote. And if you had a a reactive statement that contained a reference to something, for example, your canvas dot fill style equals color. Right? We would we would look at the code itself, and we would see that that reference to a reactive piece of state. And the compiler would emit code that depended specifically on that piece of state. But that doesn't scale very well because if you wanna take some part of that code and refactor it out into a helper function, then you're you're sort of out of luck because the compiler can no longer see it. And so the big difference with Svelte 5 is we're relying on the reactive dependency graph to figure that out at runtime.

Rich Harris  [00:34:33]:
And that turns out to be a lot more scalable, a lot more efficient. Not quite as cool, honestly. Like, there's something a little bit fun about using static analysis for this stuff, but it turns out that there are enough cases where that model falls apart. The the signal based approach is the right one.

Dan Shappir [00:34:51]:
Interesting. So in a lot of ways, you're you're even though you're very much still a compiler based, you're actually much closer to JavaScript than you previously were in in certain ways.

Rich Harris  [00:35:04]:
We are. Yes. We are still taking this compiler centric mindset, but I I think we're using it in a slightly more responsible way than maybe we did in the past. But, yes, we we

Dan Shappir [00:35:19]:
I I have to say that previously, this was one of my hang ups about, about, Svelte that I know that you put it in a Svelte file, which really highlights the fact that this is not just a regular JavaScript file or a or a TypeScript file. But in certain ways, I I I used to say that Svelte was deceptively like JavaScript in terms of of syntax, but very different in terms of semantics. And that that's a problem, and and at least in my opinion. And I really like the fact that you're able now to kind of, to a great extent, eliminate the semantic disconnect that existed before.

Rich Harris  [00:36:05]:
Yeah. And it means that we don't have to have 2 separate approaches to reactivity. Previously, we had, you know, let count equal 0 inside your component. But then if you wanted to have some piece piece of reactive state that was shared between components, you couldn't then do that. You had to use something that we called a store. Stores still exist in Svelte 5, but they are sort of deemphasized because now you can create reactive state anywhere in your application, and you can share it between components very easily. And so everything is just a lot more unified than it ever has been before.

Steve Edwards [00:36:38]:
But

Dan Shappir [00:36:38]:
it still needs to be inside Svelte files. I mean, I can't just use one of them inside of a regular JavaScript file because then the compiler wouldn't see it. Or am I misunderstanding?

Rich Harris  [00:36:49]:
Right. So, because we are essentially changing the language, we are adding something to the language. We took the decision to only do that inside dot svelte.jsand.svelte.tsfiles. So you still have the entirety of, you know, everything that works with JavaScript and TypeScript, like, all of the tooling, works as you would expect. And these are just normal modules, so you can import things. You can share things between them as you would with any other module. But the Svelte language extensions will only apply to those dots Svelte dot JS files. But it gives you a place to to put that shareable logic.

Dan Shappir [00:37:28]:
So so as opposed to previously, in in the past, a dot Svelte file would always be a component file by definition. And now per my understanding, it could be a utility file containing, you know, just room declarations or helper functions or stuff like that. They they just need to undergo the compilation step in order to work with the rules.

Rich Harris  [00:37:52]:
Exactly. Yeah.

Dan Shappir [00:37:54]:
That's really cool. I really like that.

Rich Harris  [00:37:57]:
Yeah. For a while, we we considered just just doing it for every file in your code base, But we decided that that was a little bit irresponsible. Firstly, it's gonna mean that the compiler has to look at a lot more files, and it means that in any case of ambiguity, we're a little bit stuck. But it also means that we're sort of squatting on on this Rune namespace. And if other frameworks were to come along and say, hey. You know what? That's actually a pretty cool idea. We wanna do some version of it ourselves. Well, that would be really difficult.

Rich Harris  [00:38:30]:
But, you know, if in the future, say, Preact wants to do some version of this, then you could do dotpreact.js, and they could have their own runic namespace in inside inside their own code. So it's mostly out of, kind of being trying to be a good citizen, but also some of practical considerations of of writing down the past.

Dan Shappir [00:38:52]:
Are you thinking about maybe trying to standardize or even spec the Roon signature so the different implementations might be interoperable?

Rich Harris  [00:39:04]:
We have not because we're still in this kind of exploratory phase where we're figuring out what what needs to be a room, and what is potentially just a function that you can import from from the library. And I I think it makes sense to start with a working implementation and then see what happens in the wild, see if it makes sense to collaborate with other frameworks on something that is a little bit more standards flavored. It's interesting that at the moment, we're having this conversation the day after the signals proposal was made public. So for the last several months, a team has been working a cross framework team has been working on designing a signal primitive that will exist in the language itself. And that was that was released yesterday. So it has a concept of there's analogous to our dollar state, and it has a concept that's analogous to our dollar derived. And then on top of those two things, you can build effects and all of these other things. And the idea is that all of these different frameworks are doing their own signal implementations.

Rich Harris  [00:40:13]:
Wouldn't it be great if, a, there was interoperability between the frameworks? You know, if I had a library that was emitting some sort of signal, then it could be used in all of these frameworks And, b, potentially, these frameworks could get rid of some of their own runtime code in favor of just using the platform. And so there's these two things. There's there's the mechanics of signals themselves and having that primitive in the language, and then there's the, like, how do you reference them in your code. And what we're focusing on is, like, this idea that that signals should be essentially a part of the language, not just a primitive that that you interact with like any other object. It's a part of the language because reactivity is so fundamental to the task of describing user interface that it deserves to be a language level concept. And so those two things, I I think, are like separate but parallel conversations that are worth having.

Charles Max Wood [00:41:12]:
So you keep saying, like, the language and the platform. Right?

Dan Shappir [00:41:16]:
And and

Charles Max Wood [00:41:17]:
I think when I talk to people about Svelte, usually they're just kind of referring to it as a framework. Can you kind of explain the different concepts here?

Rich Harris  [00:41:27]:
Yeah. It's difficult because, Svelte sort of spans a lot of different categories. You know, it's not it's not a traditional UI library, in in the manner of of what came before. It is a compiler, but it is also, a language. It's a superset of HTML.

Charles Max Wood [00:41:45]:
And the

Rich Harris  [00:41:45]:
compiler takes that language, and it compiles it down to JavaScript. That JavaScript imports code from the Svelte runtime library. That's how it it, you know, does its its its updating and it's, it's rendering and everything. And then on top of that, we have an application framework called SvelteKit, and the boundaries of all of these things are a little bit fuzzy. When I talk about the language, what what I essentially mean is, you know, in the same way that you have things in the language like dynamic import, looks like a function, but it's not a function. Wouldn't it be great if there was something akin to that that describe reactive values? And that's what we're trying to do with rooms.

Charles Max Wood [00:42:30]:
Okay. The the other question I have is it seems like a lot of this is focused around, sort of developer ergonomics and, you know, a good developer experience. And I guess you probably won't know completely the answer to this question, but when people are talking about web applications, they're also then talking about performance and, you know, how how well it it works and scales and things like that. You know, can I have, you know, 15 signals or 80 signals or 2,000,000 signals? You know? How how do how do the runes play into all of this as far as, you know, the the capabilities of the application, but also, you know, how it's gonna perform if I go and build out some application on it?

Rich Harris  [00:43:18]:
The performance, honestly, is is breathtaking. There's a a framework that's very widely recognized, the JS framework benchmark, which, is a really good sanity check for, for how well your framework does. And it it fluctuates a little bit as we add and remove things, but Svelte is it's it's basically the fast Svelte five is basically the fastest mainstream framework. There's, like, a a couple of other, like, very small ones that are very, very focused on the sorts of tasks that this benchmark tests for. But, you know, Svelte five, it looks like it's probably gonna be a little faster than solid, which is sort of the gold standard for this sort of thing.

Charles Max Wood [00:44:00]:
Okay.

Rich Harris  [00:44:01]:
And, you know, probably the reason is that sorry. Go ahead.

Dan Shappir [00:44:05]:
No. And and no. Go on. You were saying part of the reason for that. I'm really interested.

Rich Harris  [00:44:11]:
Well, again, because we're a a compiler, we have, luxuries that other frameworks don't. So, you know, for example, in Solid, if you create a signal and a function that updates that signal, you're creating a pair of closures. And closures aren't expensive, but they're also not free. In Svelte, when you create a source signal, it's just a very simple object. And when you read that signal and when you write that signal, you're using these get and set functions, which are are shared by all of these sources. So that's just, like, one small example of how having the ability to transform your code allows us to use a slightly more efficient way of reading and writing state without any ergonomic compromises.

Dan Shappir [00:45:03]:
You know what this kind of reminds me of? I'm old enough to remember compilers, for languages like, c and c plus plus.

Steve Edwards [00:45:12]:
Mhmm.

Dan Shappir [00:45:12]:
And and back in the day, we are usually for these compilers, we had the developer mode and, release mode. Where in the developer mode, it optimized for compilation time, Whereas in in, you know, release mode or production mode, it's optimized for execution time. So it would run the compiler much longer, but generate much more optimized code. And I'm starting to think that that might start being relevant for, you know, some of the stuff that you're doing that maybe during development, you might, you know, be willing to generate less optimal code, but just compile as quickly as possible so that the development environment would be nice and friendly. But then, you know, in a release mode, you could theoretically, like, do really significant compilation, maybe even looking across components and stuff like that.

Rich Harris  [00:46:08]:
It's a 100% the case. So we already do a lot of developer time checks. I said earlier, I talked about the ownership validation. You know, if b mutates state owned by a, then Svelte will yell at you. Well, we actually only do that in development because in production, that's just overhead which no one is is really gonna benefit from. And so there are certainly cases where we do the slightly slow but more helpful thing in development mode. But the kinds of things that you're talking about, like cross component analysis, is is very much where we want to take a lot of these ideas. We actually had some experimentation early on.

Rich Harris  [00:46:45]:
Dominic did, had, like, a a whole trench of work that was looking at this exact thing, but it it was difficult to to keep up to date with the the rest of the of the framework when it was all so very much in flux. But that is something that we're chomping at the bit to revisit once Svelte 5 goes stable. We think there's huge upside here.

Dan Shappir [00:47:05]:
Yeah. Well, premature optimization is the root of all evil. You know?

Rich Harris  [00:47:09]:
Certainly is.

Dan Shappir [00:47:12]:
So, it's interesting, though. Again, I kinda mentioned it before, but you know? So, obviously, you were probably may I I I wouldn't say that you were necessarily the first framework to use a compiler. I wouldn't be surprised if that's Marco because Marco is, like, first at everything, turns out. But you were certainly, I think, the first one to really promote it and popular popularize it. But now it seems like, as I said before, that all frameworks are kind of, to a lesser or greater degree, embracing compilers. Even React with React, forget is embracing, compilers. So how do you see the different compiler the different approaches in this context, or are all of the frameworks effectively converging on the same place?

Rich Harris  [00:48:07]:
It it's it's a great question. There's definitely been a lot of convergence just in general in the space over the last few years. And what I think tends to happen is there's a there's a sort of compression as everyone converged on the same ideas, followed by a period of innovation, in which people sort of go off. And, you know, now that we've centralized on a core set of ideas, like, how do we differentiate ourselves from one another? And I I think we're probably entering into that period right now, when we start to see, you know, what what our different foundations allow us to to do differently. And for us, the kinds of things that we're thinking about are, you know, as everyone else is thinking about, a server first mentality, like everyone is sort of retreating from client side JavaScript in general, we're thinking, well, you know, a lot of people still wanna build these richly interactive client side applications. And, yes, it's very essential that you have really tight integration with with the back end. Like, no one's disputing the importance of progressive enhancement and service line rendering and and all of these other things. But at the same time, are we forgetting that there is a place for local first thinking and for, you know, on device computation thinking and, all of these other things that some frameworks candidly are starting to deprioritize in a way that worries me a little bit.

Dan Shappir [00:49:33]:
So no Svelte server components in the near future?

Rich Harris  [00:49:38]:
We do not have a plan right now to make Svelte server components. So our RSCs are obviously the like, this fascinating Yeah. Brilliant idea, and they've sort of shaken up how everyone thinks about a lot of things yet again because, you know, this is what the React team does. They'll sort of sit quietly for 3 years and then just blow everyone's minds with with some new radical innovation. But to my mind, there are the good parts of React server components, and there are the bad parts of React server components. And I I I think, a lot of the the the proponents of RSCs would probably say that the good parts are different. But in my experience, just seeing people struggle with the concept, I would say the good parts of React Server Components are the ability to do asynchronous data loading. You know, the fact that you can have async components and and that just sort of works is very cool.

Rich Harris  [00:50:35]:
But the bad parts are the idea that you have these these 2 separate things running in 2 separate environments, and the ways that you can combine them, the subject to certain constraints, and, like, the things that you can use in one environment that you can't use in another environment is, like, super hard for a lot of people who don't do this day in, day out, all the time to get their heads around. And so, you know, the kinds of things that we're thinking about are, can we have the benefits of this asynchronous data loading, approach? Like, can we have a weighting component in a in a a way that is really orchestratable and, and and and and makes sense from the point of hydration throughout the the application life cycle without any of those, sort of authoring drawbacks and and the confusion that arises from having these two worlds sort of interleaved like that. And, you know, we we have some we have some ideas, but a lot of it is unfortunately gonna have to wait until after we ship Svelte 5 point o because, otherwise otherwise, we'll never ship Svelte 5.0.

Dan Shappir [00:51:37]:
So no. So for Svelte 5.0, no innovations associated with hydration?

Rich Harris  [00:51:44]:
So our our approach to hydration is, is pretty efficient. It's it's certainly faster than it was in Svelte 4 because we have decided that it's acceptable to assume that the structure of your application on the client side is the same as it was on the server side, like you're rendering the same components. And so as soon as you have that that constraint as part of your model, you can make your hydration a lot faster than if you try to, like, grate gracefully, repair every piece of slightly malformed DOM that that you encounter. So right out of the gate, hydration is really fast in Svelte 5. Because we're a compiler, we're able to do things that might be a little bit trickier if you're using, say, JSX. We can do now if you have, I don't know, an if browser block and then you have some code in there and then in the else that you have some other code, a lot of hydration algorithms will choke on that. They'll be like, hey. We've got a mismatch here.

Rich Harris  [00:52:48]:
We might need to throw away some work and start again. Well, Svelte handles that just fine because the compiler can can just drop in a little annotation that the runtime then knows how how to deal with. So I wouldn't say there are huge innovations around hydration, but it's fast and it's reliable and it's it's flexible. It's it's robust to things changing between the server render and the client render.

Dan Shappir [00:53:10]:
Yeah. But you're not trying to avoid, let's say, sending down certain code. You're basically just saying my code is smaller because it's it's generated by compiler, but I'm going to download the code for for component for client for components because they might be rerendered on the client.

Rich Harris  [00:53:32]:
Yeah. Because it it it it's a waste of time, honestly. There's I I know a a lot of focus is paid to the cost of hydrating an application, and it's that is not where the problem is. That is not why, the performance of websites is sometimes not great. I mean, it might be if you have, like, a really slow framework that is slow to hydrate. But generally speaking, the problems lie elsewhere. And so I I know that there are some frameworks whose whole deal is avoiding hydration cost.

Dan Shappir [00:54:04]:
Quick.

Charles Max Wood [00:54:05]:
The I was gonna say, you should talk to Mishko because he tells a little bit different story.

Rich Harris  [00:54:11]:
Yeah. I mean, of of course, he does because that's, like, that's why that framework exists.

Charles Max Wood [00:54:16]:
Yeah.

Rich Harris  [00:54:16]:
But, you know, every time we profile, Svelte sites that we see in the wild, the problems are things like, well, they disabled SSR, so they have a they have a waterfall. And they disabled SSR because of some business requirement or it's because they've got big images and we didn't do a good enough job of providing them with the tools to make sure that their images are tightly optimized, it's pretty rare that hydration moves the needle in our experience. And so our position is make it as fast as possible. If there are opportunities to skip hydration, in some cases, then take them. And there are some places where we do that in Svelte 5. Like, if we have a big blob of HTML from a markdown post or something like that, just assume that it was the same between server and client render. But by and large, don't worry about it. It's not where the problems lie.

Dan Shappir [00:55:06]:
You were also, as I recall, one of the first frameworks, if not the first, to introduce the concept of progressive enhancement, is related to hydration, or am I mistaken?

Rich Harris  [00:55:20]:
So we I mean, we've been on the progressive enhancement bandwagon for some time now. I think the the first release of SvelteKit's predecessor, Sapa, was in 2017 end of 2017, and and, you know, we we launched with server side rendering. But I I wouldn't say that we were the first people to to do that. We were essentially copying Next and Nuxt, and even they were copying other prior art.

Dan Shappir [00:55:45]:
Remix was maybe one of the first?

Rich Harris  [00:55:48]:
No. No. Remix was actually pretty late to the game.

Dan Shappir [00:55:51]:
Oh, yeah. Because it was a big it was a big thing with Remix as I recall, like their first demo where they showed everything effectively running totally server side without anybody noticing or something along these lines. Maybe it's worthwhile to quickly explain, like, this is not the point of this podcast, but maybe it's worthwhile to really quickly explain what progressive enhancement means in this context.

Rich Harris  [00:56:15]:
Yeah. I mean, it's possible that that we're even talking slightly past each other by using it to to mean different things. But, essentially, the idea of progressive enhancement is, well, take the analogy of of of an escalator. When it's running, when the electricity is on, the escalator, you stand on it, and it takes you to the top or takes to the bottom. But if the electricity fails or if there's a mechanical failure or something, it becomes a staircase, and you can still use it.

Dan Shappir [00:56:42]:
Oh, really? I like it analogy.

Rich Harris  [00:56:44]:
Yeah. So the escalator is progressively enhanced from a staircase. You can still use it, but it's just nicer if you have the things running as you're as you're using them. And in the context of a website, what that means is that if you have a page that doesn't have JavaScript for whatever reason, now maybe you're on the subway and the JavaScript failed to load before you lost connectivity or maybe you're on a browser that doesn't support some new JavaScript feature that is being used by that website, or one of a 100 possible reasons why someone might not be running JavaScript, that website should continue to work. And that means that links should still take you to their destination. It means that you should still be able to interact with form elements. It means that you should be able to submit a form and send data back to the server. And it's that latter part where Remix added some innovation.

Rich Harris  [00:57:37]:
They really prioritized form submissions in a way that other frameworks had had kind of said, you know, this is this is a problem that is solvable in user land, whereas Remix said, no. No. We're gonna make this, like, a core part of the framework's offering. And that was a very welcome change. Like, other frameworks certainly sat up and took notice and, and and started doing the same thing. But progressive enhancement more broadly, this idea that if you have a website, it should work without JavaScript is something that I think frameworks have been prioritizing for many, many years at this point.

Dan Shappir [00:58:13]:
And oh, and there was one more thing I wanted to ask. Oh, yeah. One of my last questions. A a lot of frameworks, it seems to me, are kind of embracing, in certain ways, in very different ways, concept of RPC as a means of communicating between the the front and the back end. Now this is more meta framework question than a framework question. But, basically, it means that you invoke code on the server side in a way that's kind of that looks semantically like calling a function. Is that something that you're also looking at or thinking about or considering?

Rich Harris  [00:58:51]:
I have some real qualms about RPC, as it's being implemented by by frameworks today. I think there is a real value in at least having to switch between different files if you're crossing a network boundary. There are too many ways in which it can go wrong. If you have some code that accesses database directly and you just put that inside some code that is running on the front end, then even though the compiler is gonna get rid of it, you know, there is a non zero chance that you are going to have some sensitive information in a source map or or something like that. And in general, any type safety that you get across a network boundary is fictional, and I don't think that these RPC systems give you as much type safety as as they as they purport to.

Dan Shappir [00:59:44]:
But all all TypeScript type safety is effectively fictional because it all it never happens at one time. And Right. So so in a lot of ways, it's no different than than whatever other type safety you get from TypeScript. But it's really funny because we actually had Sam Selikhov on on one of the episodes talking exactly about the scenario you just described because he's the one that that did that presentation with a slide that became a meme about embedding

Rich Harris  [01:00:13]:
Terrific presentation.

Dan Shappir [01:00:14]:
SQL. Yes. It was. Embedding some SQL inline inside the React component, which was yeah. A lot of people didn't like that.

Rich Harris  [01:00:25]:
Yeah. So, you know, a a a lot of people, were on one of two sides of that screenshot. There were the people who were like, oh my god. This is a giant security hole because they didn't understand that the sequel in that screenshot was being escaped by the library. And then there were all of these other people on the other side of the spectrum being, you idiots. It's being escaped. There's no problem here. But the reality is, yes, that code was being escaped, but it would be so easy for someone to write a SQL query that was not being escaped.

Rich Harris  [01:00:57]:
And by creating these arbitrary mini endpoints throughout your application and just, like, exposing this massive surface area to, you know, to would be evildoers, I think there is, you you know, there are some security questions that arise from this way of thinking about things. And, like, look, Smart people are thinking about all of these things, and I don't expect that we're about to experience a, you know, a a security apocalypse of of, of RPC causing, like, all manner of of new attacks. But I I do think that just at a a conceptual level, as you're writing the code, it's much easier to understand what's happening if there is a a just a tiny bit of friction between what's happening in the client side and what's happening on the server side. And for me, like, a a file boundary is a good place to express that distinction. In the context of a VIT application and SvelteKit applications are VIT applications, you can use something like Telefunk, which will allow you to to do RPC by importing, quote, unquote, a function from a server side module. And in the client, that is essentially, you know, an RPC, interface, which allows you to to call that function on the server, but it's not inside the same file that is running client side. And this is, you know, maybe a matter of preference, and maybe I'm being overly paranoid about this sort of thing, but I think there's too much your scientists were so preoccupied with whether or not they could, they didn't think about whether or not that not they should. Everyone's trying to be the, like, the slickest and most convenient thing.

Rich Harris  [01:02:46]:
And sometimes that's right. I mean, I Svelte certainly tries to be slick and convenient in a lot of places, but sometimes friction exists for a reason, and we forget that at our peril.

Dan Shappir [01:02:59]:
So just a final question on my part, because you mentioned SvelteKit. Is SvelteKit staying the same in this release? I mean, SvelteKit that runs with Svelte 5 is effectively going to be essentially the same as SvelteKit that's running with Svelte 4, or is there some are there some changes on that front as well?

Rich Harris  [01:03:20]:
It's gonna be exactly the same at release, I I believe. I don't think we're gonna introduce any new things that you know, use the new state primitives, for for example, straight away because everything is just gonna continue to work. It should just be like a a seamless upgrade. You can take your existing SvelteKit 2 app and upgrade Svelte 4 to Svelte 5. Everything's gonna be fine. That said, once we do get Svelte 5 out the door, there are certain ways that we're gonna be able to capitalize on it within SvelteKit. And longer term, I think we have some some ideas of where we want to take SvelteKit that are gonna be easier because Svelte five exists.

Charles Max Wood [01:04:01]:
So do you have do you have a date? I know people are wondering.

Rich Harris  [01:04:06]:
Come on, Charles. Don't don't do me like that.

Charles Max Wood [01:04:10]:
Oh, somebody was gonna ask it. Okay. Let me ask a different way then. So you I'm I'm figuring you have the roadmap pretty clear. It sounds like you know what you're putting in, how this is going together. It looks like you've got a lot of this kind of, you know, bolted in, you know. Are are you still bolting pieces in? Are you polishing? Are you I mean, where where are you at in the the life cycle of releasing something like this?

Rich Harris  [01:04:39]:
So in terms of the design of the framework, I I think we're pretty much done. There might still be 1 or 2 little API design questions that need to be resolved, but it's at this point, it is mostly implementing the things that we said we're gonna implement and fixing bugs. I wouldn't say that we're on the glide path yet. Okay. But we are pretty close. I think we're gonna have a release candidate in the not too distant future and a stable release not too long after that. I'm just very hesitant to commit to a specific date because in the past, whenever I've done that, people have got mad at me.

Charles Max Wood [01:05:17]:
Makes sense. It looks like from the comments on YouTube that some folks, have been able to try out Svelte 5. Right? So whatever state it's in, and and been able to get you feedback. So let's say that I'm thinking, oh, I want to try it out. Right? Whether I'm a an experienced Svelte 4 developer, whether I'm just, you know, I'm trying it out, and I'm like, I may as well just try the cutting edge thing. Where do I go pick that up, and how do I give you feedback?

Rich Harris  [01:05:50]:
So the the feature is available on NPM. We do NPM install Svelte app next. You will get the the most in development version, the most cutting edge stuff. If you have an existing SvelteKit app, you can do that, and hopefully, things will continue to work. If you're creating a new application and you wanna try it out, then when you create your SvelteKit application with npm create Svelte, it will present you an option to try out Svelte five.

Charles Max Wood [01:06:14]:
Okay.

Rich Harris  [01:06:15]:
And if you accept that, then you'll be opted into the new stuff. If people have feedback, it is extremely welcome. Come to github.com/sveltejs/svelte, and there is an issue tracker there. And we are accepting issues and pull requests for Svelte 5. A lot of people have already contributed, and it's been super helpful. Really great to have, like, an enthusiastic community who will take this very unfinished product and actually start putting it through its paces. It's helped us find a lot of things that might have slipped under the radar otherwise. And if you wanna be one of those people, then please come on by.

Dan Shappir [01:06:53]:
I have to say that I really admire how brave very brave you are in the scope of changes that you're making in this version. I mean, it's not totally not a trivial thing to take a framework that's already at version 5 or approaching version 5 and literally turning it on its head in a lot of ways. It's like it's a big gamble, and and I really appreciate you for doing it.

Rich Harris  [01:07:21]:
Well, thank you. And, you know, it's a testament to the Svelte community that this has been met with, by and large, a lot of excitement and enthusiasm and not too much grumbling and why did you have to change it. You know, we we have this this really great community that I'm very appreciative of, and they've been super encouraging and helpful, throughout this whole process.

Charles Max Wood [01:07:48]:
Yeah. I guess, one other thing that I'm just curious about, do you do you have some idea how large the community is out there using Svelte?

Rich Harris  [01:07:58]:
Let me see. The the I guess the best proxy I can give for that is, let's see how many people are in our Discord server right now. If I go to svelte dot svelte.dev/chat. So there's 8,845 members online in our Discord right now.

Charles Max Wood [01:08:15]:
Nice. We have

Rich Harris  [01:08:16]:
65,104 members. So it is you know, next to React and Vue and Angular and these other things, we are teeny, teeny, teeny tiny, project, but that's not a small number of people.

Dan Shappir [01:08:30]:
No. I I'm not exactly sure, by the way. I mean, obviously, React is is the biggest, and and it's effectively as big as all the other frameworks, put together. But once you go beyond React, the order is not as as trivial as you might expect from what I've seen. I I've been kind of using the, crux, the Google crux database, as as a reference. Now, obviously, you know, it it only shows a certain subset, you know, effectively just sites that certain sites that Google ranks, but it's better than nothing. And, and then I'll try to look up to see what the current situation is, but I'm not sure it's it's quite as linear as as you might think. That's, you know, that's what I'm thinking.

Rich Harris  [01:09:23]:
Oh, we're we're growing, but, you know, it's it's mostly upside as far as we're

Charles Max Wood [01:09:27]:
concerned. Awesome. Well, I'm gonna go ahead and slide us into the wrap up of the show. Rich, you kinda talked about people giving you feedback, but if if they wanna follow you or see what you're working on or connect in some way, where do people find you on the Internet?

Rich Harris  [01:09:47]:
For my sins, I still hang out on twitter.com, slash rich_harris.

Dan Shappir [01:09:55]:
You hang it on.

Rich Harris  [01:09:57]:
Yeah. I guess that's where I do most of my opinionating. But most of my time, I guess, is spelled is spent on GitHub. So come to the the Svelte organization on GitHub and and join the join the threads there. And and our Discord, of course, svelte.dev/chat.

Charles Max Wood [01:10:17]:
Yeah. That seems like an awesome thing. I just joined the Discord because I I love Discord. Alright. Well, let's go ahead and do some pics. Steve, do you wanna start us off with the pics?

Steve Edwards [01:10:28]:
Alright. So you wanna get to the high point of the episode first? I I get that.

Charles Max Wood [01:10:31]:
I get that.

Steve Edwards [01:10:32]:
So early. Early. Right. So, didn't really have any other picks here other than the the dad jokes of the week, which are the the high point rich. I'm not sure if you're aware of this. But, anyway, so recently, I found this, diet diary that I was keeping when I was losing weight. And it says day 1, I removed all of the fattening food from the house. It was delicious.

Steve Edwards [01:11:05]:
Side note, I found another diary I kept, when I was first born. It said day 1, still recovering from the move. Day 2, everybody talks to me like an idiot. I borrowed that one from Steven Wright. Continuing along with the food theme, a lot of French words have actually crept into the English language over the years, hors hors d'oeuvres for starters. Right? And then, you know, I've never really had pets because I'm just not good with pets. For what for instance, once I had a fish that could breakdance, but only for 20 seconds and only once. Those are my picks of the week.

Steve Edwards [01:11:50]:
Alright.

Charles Max Wood [01:11:51]:
Dan, what are your picks?

Dan Shappir [01:11:54]:
Okay. So, we saw this movie on on Netflix, which I, well, I really enjoyed, which is called I care a lot. It's, it's described as an American satirical black comedy thriller film. It's with, Rosemond Pike and Peter Dinklage. And like I said, we really enjoyed it. It's it's kind of gritty, dark comedy. And, and it has a certain message. So so, yeah, I recommend that.

Dan Shappir [01:12:27]:
And the other thing is we've kind of been, clearing out our library at home. Like, we've got, like, our library got to the point where we had 3 or 4 rows of books. So, we thought that we needed to make some space. And I've been, looking through my, collection of science fiction and fantasy books and trying to see which ones I like to keep and which one I toss away. And some of the ones that I've decided to keep, I'm kind of reviewing or rereading and thinking about also maybe recommending for our listeners. So, an interesting series that I recall enjoying very, very much when I read them, so I'm now going to reread them and see if I still enjoy them, is a series of books by, a woman author. Her name is Julian May. It's called Saga of Rios in exile.

Dan Shappir [01:13:23]:
It's it's kind of a cross between science fiction and fantasy in the sense that everything is kind of described in in a science y sort of a way, but the the settings is actually more similar to to a fantasy series. Now, I will make a certain caveat in some reviews have stated that it has trans some transphobic views in it. So if you might find that triggering, maybe this is not for you. I'm not sure that's the case or not because as I said, I I it's been a really long time since I've read it. So now I'll reread it again and see if that's indeed the case. But so that that would be a series of books that I reco that I'll recommend based on my recollection of of it being just an excellent series of books that I enjoyed reading, like, a few decades ago. And those would be my picks for today.

Charles Max Wood [01:14:22]:
Awesome. I'm gonna jump in with, some picks here. And, I probably picked this board game in the past, but we were playing it. And my my 8 year old wanted to play games. And so we pulled out some of the board games, but she wanted to play, an adult game. And so, you know, we were pulling up the the kitty games. Right? Right. And, you know, for those of you who are haven't listened for a while or are new, I pick a board game every week.

Charles Max Wood [01:14:53]:
So, this one is actually a card game, not a board game this week. It's sushi go party. And, it does have a little board, but it's just kind of for keeping track of your points and you have the different, sushi options. Right? Or sometimes you have other things like a spoon or chopsticks or something. And so what you do is it's a drafting game. So you have the cards in your hand, you keep 1, and you put it down face down. You pass the left. And then you reveal your card, and then you pick from the hand that was just handed to you, and do it all over again until all of the cards are exhausted.

Charles Max Wood [01:15:31]:
And then you score and the scoring is based on the, whatever the, the different, sushi options are. Right? So, the nigiri are just straight up the points that they, you know, that are on their face. You've got like, miso soup. Whoever has the most of those, I think it's a certain number of points. Anyway, there are a whole bunch of different things. And so and you can trade them out. Right? So there are different kinds of sushi that you can swap in. Right? And then you, score the desserts at the end and whoever has the most points wins.

Charles Max Wood [01:16:12]:
BoardGameGeek has a, weight of 1.30. So, you know, really simple game. She she could pick it up and play it. She actually won the second game we played. But it's mostly on sheer luck because, you know, she's not quite to the point where she can look at all of the options and put them together in the right way that works. Right? But she happened to collect enough of the right cards to make it happen for her the second time, which is kind of nice. Cause you know, then she can play it and win. So, that's sushi go party.

Charles Max Wood [01:16:51]:
I think it takes 20 minutes, half hour to play around of it. So, and it'll play up to 8 people. So if you have a big group and you're wanting a game that'll play all those people, then that sometimes that's the issue, and you can definitely do it with Sushi Go party.

Dan Shappir [01:17:07]:
We play Settlers of Catan at home, and I've yet to win.

Charles Max Wood [01:17:10]:
Oh, really? That makes me sad. We don't play Settlers anymore. We have it.

Dan Shappir [01:17:18]:
I think it's called Catan now. I I think they dropped the Settlers off.

Charles Max Wood [01:17:22]:
Could be. And they have a bunch of variants of that too, which are fun. So, anyway, I'll put an Amazon affiliate link in there too. If you click it, I get kickback, but you can just buy it wherever. It's been around for quite a while, so it's not it's not like a hot game that's hard to to track down. But, yeah, if I do it this way, then people just click and buy it. So other picks. I've been connecting with people a lot on LinkedIn, which I'm really liking.

Charles Max Wood [01:17:58]:
So I'm gonna pick that. Mostly what I've been doing is I've either been reaching out to people that I've worked with in the past or have some connection to. It's like, oh, I'd like to connect with them again. You know, as I mentioned at the start of the show, I'm looking for work. And so, you know, sometimes people throw me a connection or something, you know, they're like, Hey, connect with this person. Cause they may be able to help you. But, for the most part, it's just been nice to connect with people while I'm trying to figure out my work situation. And then, the other two things are going to be the things that I'm putting together.

Charles Max Wood [01:18:31]:
So I'm, I'm putting together JavaScript Geniuses and Ruby Geniuses. I think I mentioned it on the show before, but I finally got kind of all the platforms put together and everything so you can sign up and do it. It's gonna be a weekly call. We talk about JavaScript stuff. You know, we may invite people like Rich or Dan or, you know, whoever else we've had on the show to come in and just chat with us, about what they're working on. Right? So maybe we'll, hit Rich up when Svelte 5 comes out, and he can talk to us about what's involved there, you know, whatever, when people are available. And then, yeah, just kinda do some coaching, some career connecting. But it it's kind of that weekly meetup vibe that you get.

Charles Max Wood [01:19:13]:
And so if you're into Ruby or Java or JavaScript, I have, basically one for each. And then, I just, the other thing is I just barely set up on Spreaker. I set up the premium podcast. So, you know, we do insert ads into the audio of the podcast. And so if you want the version without the ads or if you are just, you just wanna support the show at $9 a month, that really helps because, anyway, Yeah. I I'd like to eventually not have sponsors, but, in the meantime, if you want to help us out, that'd be great. And you can just get that at javascriptjammer.com/premium. Alright.

Charles Max Wood [01:19:53]:
Rich, what are your picks?

Rich Harris  [01:19:56]:
Well, after being reminded about it during this conversation, my pick has to be Ragnarok.

Steve Edwards [01:20:01]:
Nice.

Rich Harris  [01:20:01]:
Go get get yourself a quest 3. Download Ragnarok. You're gonna have a great time. So the reason that we have a Quest 3 is because I was able to convince my wife that if I spent $500 on one of these, I was much less likely to spend 3 and a half $1,000 plus tax on a VisionPRO. And so far, that has helped me. I'm yet to yield to temptation.

Dan Shappir [01:20:25]:
I I can't you get them for cheap now that everybody's trying to return them?

Rich Harris  [01:20:30]:
Maybe. Maybe. Maybe. Honestly, I I haven't even tried one yet, and I'm scared to do so in case I am then compelled to to drop all that money on something that I will end up probably not using very often. But you know what? I think people are sleeping on virtual reality generally. I think that it's obviously early and there's a lot of things that has yet to be figured out. But if I had more time to spend on hobby projects and I wasn't working every hour that ends on Svelte, then, you know, forget about all this AI nonsense. VR is where is it where is it gonna be?

Dan Shappir [01:21:05]:
I have to I have to mention this. Something like 15 years ago, I think, more or less. I gave a talk at a conference where I said that if in a decade from now, we are still using the same old laptop form factor, I'd be extremely disappointed with humanity. And here we are still waiting on VR.

Rich Harris  [01:21:26]:
We're so close. We're so close.

Steve Edwards [01:21:30]:
Yeah. Alright.

Charles Max Wood [01:21:33]:
Well, this was really, really interesting. And I we do these episodes, and then I'm always like, I don't wanna go try it right now. So, anyway, thanks for coming, Rich. This was a lot of fun.

Rich Harris  [01:21:45]:
Yeah. Thanks for having me.

Charles Max Wood [01:21:46]:
Alright, folks. We're gonna end it here. Until next time, Max out.