Svelte 5 Is Here!

Welcome to Syntax. Today, we got a show for you on Svelte five. Svelte five has been out for how long, Scott? Couple

couple months now? Yeah. Yeah. Maybe maybe by the time we're listening to this a couple months. Yeah. Okay.

And there is a couple new primitives, couple new ways to sort of approach state and and effects and whatnot and some kinda new features. And, Scott, you did a a video on, on the Syntax YouTube channel. Right? And CJ's done a couple?

Yeah. I did a, actually, you know what? It's funny. It's my 1st long form tutorial since, LevelUp Tutorials became Syntax on YouTube. And, yeah, it's a it's a, like, a 2 and a half hour long tutorial on, you know, getting up and running with Svelte five, especially if you've never used Svelte or you're coming from React. I do a lot of, like in React, you do it like this. So, yeah, it's a it's a good base understanding of all of these APIs. And I I've been working in Svelte five since, man, the first, alpha. The 1st time I could, get my hands on it since I'm a a Svelte ambassador.

I'm I've been in the Discords, and I've been giving this stuff a go and testing the new APIs out as they've come pretty much as they come. So yeah. It's it's pretty nifty. I'm a big fan of of how all this works.

And, we thought, let's do, like, an audio episode running through the different features of, of what Svelte five has. But let's talk about Sentry. If you are upgrading to Svelte five like we did on the Syntax website, you're probably or maybe gonna hit, some issues where you break something, especially JS a pretty pretty big website. Right? And, Century is gonna be there to to figure out when those things go awry, whether it's a database query that has has run away on you or whether it's a syntax error that when somebody clicks a button, it breaks or or rage clicks, things things like that. So check it out for your website. You definitely want this before things go wrong, not after. Century.ioforward/

syntax. Yeah. Cool.

Yeah. Let's get into it. 1st and foremost, Svelte five, what is new? I think the headline feature for Svelte five in terms of what people may have seen the most is the runes, r u n e s, runes, which the the word runes here is is basically just referring to the fact that Svelte is using a symbol, which is the dollar sign to indicate some bit of unique functionality.

So anytime you see the dollar sign before a word, you know that that is some Svelte specific code here, whether that is state or props or even effects or things like that. So that yeah. Yeah. And it's funny because it a rune is like a I believe it's a Norse thing, a mythology. Mark or letter of mysterious or mysterious or magic

significance? I would say, maybe a little bit of both.

Yeah. Yeah. Maybe a little bit of both. And it it's definitely, you know, there to give you an indication that something is happening here. And part of the thing that, comes about with these runes, and and we'll talk about each of them individually here, is that, specifically, in Svelte previous versions, reactivity, variables, state, those types of things were done in a couple of ways.

Inside of Svelte components, any variable defined in the past was a reactive variable, no matter what you did. That's inside of a component. Now outside of a component, you have to use a writable, or a readable. You have to use one of these reactive,

state features. Data store. Right? Yeah.

And and so because of that, there was always this disconnect of how you did state within a component Vercel potentially how you did outside of a component.

And it led to maybe some confusion about what you used, when, and where. And so the Svelte team's idea sometimes of and I don't wanna say simplicity, but the idea of, being able to quickly read and parse things is is that you should have, like, one way of doing things. Right? And so the fact that there's these multiple ways of doing things here, I think I I, you know, I don't know for certain here. I don't wanna speak for them. But I think that, in in the past has been something that they they've wanted to move away from. Right? Specifically, even with, like, SvelteKit file based routing. They've they felt like because the routing there were so many different ways to do routing with the file based routing. Once they stuck to only folders or routes, then that was like that is the only way to do it. So now within Svelte five, we have the dollar sign state, and that is the way that you create reactive state within Svelte five. So now when you create a normal variable inside of a Svelte component, it's not reactive.

Now I think this this change is controversial for a number of reasons. People really liked the simplicity of creating a variable and having that be reactive. I personally really liked it. I made a meme about it, and posted that on Twitter.

So the fact that that's gone, I think, upset some people. But in practice, creating a dollar sign state as a rune for reactive state, it just makes things more clear what's going on.

And on top of that, I think, you know, this this topic will keep coming up whether or not people are feeling like it's overly complex. But the state, when you have a state creation of a state, just like you did inside of Svelte 4 or Svelte 3, you still mutate that state. We're not doing a set state, get state, feature like you might have in React. Yeah. You create a variable with the Scott run, that variable is reactive. You mutate it, it updates. Right? So All the way down too. So, like like, if you have an object,

with 6 properties on it and you wanna update 1 of those properties on the object, you don't have to, like, make a copy of it and then update the 1 property and then call set state. Like, no. You just say, like, person Scott age equals 70, and wherever that object has been used or that property has been used, and it just rerenders and and updates it. So I very much like that part of Svelte, and I wasn't bummed to see that, like, oh, now if you want to have reactive state, you have to declare it with the dollar sign state instead of simply just making a variable.

Not a big deal.

At least, I don't think so. Yes. And so when you create a a state that way and you're accessing it, you're accessing a proxy of the state, which I also think can trip people up. Because let's say, you're using state as a default value to create other state.

Well, you can't really do that because it's a proxy. So you have to use a different rune, which is, I believe, Scott dot snapshot.

Let me even confirm that because this rune's name has changed a few times. That is the rough thing about, you know, getting onto something in an alpha is that the names of things change so frequently that, like, now I'm like, oh, what is the name? I believe it is state dot snapshot.

So you use state dot snapshot to grab a snapshot of that state at that moment instead of accessing the proxy itself. Proxy JS another thing that I I didn't use that much, really, before Svelte five. I I you you use them where you have to.

But the fact that your state is all in a proxy now for me is, like, something that I've had to

get used to. Oh, yeah. Because if you well, maybe answer this. If you console log an object that is state, it's not actually the object. It's what's called a proxy. And in JavaScript, a proxy will intercept, get getters and setters on an object so that it can do the getting and setting for you, with some logic. Right? And if you want just the raw object of the raw data, which sometimes you want to, like, send that to an API or sometimes you wanna throw it into something external, you can convert that. We have the same thing in in MongoDB where, like, you have a document.

And document both has the data, but it also has all the methods on it for for working with it. Right? And sometimes you just wanna convert that to just a raw object. Right? And there was, like, a 2 JSON method very similar to this.

Yes.

Yeah. So that is something you have to you have to get used to a little bit. But for the most part, it makes it really nice. Now you can also create reactive state in a more complex way where the you can create a function that then, contains runes.

And one of those runes may be state. Right? So you can create a function that creates an object that has these runes. But then you have to write getters and setters for that to be able to get and set the the state within that object.

Because of the getters and setters being, like, a lot of extra code, this felt community is kind of largely moving to class based state for, like, deeply complex state objects, which I've you know, when I initially posted this question to the syntax, GitHub discussions, like, should we use classes or or functions for this for state? CJ was initially like, don't use classes. But when I showed him the side by side, here's what it looks like. He was like, oh, no way. Yeah. Class is way better. It's less code. It feels nice.

It works really well. Contained. Yeah. Yeah. I I I like the class syntax quite a bit for that, especially when you have different getters, setters. And and and maybe we could explain, like like, why would you want to to build something that has its own getters and setters? And and often the case with that is you want to validate data before it's being set. A simple example might be somebody sends a a string, and you wanna convert that to a number. Right? It's a nice API to be able to just simply set a string, and you can parse it out to a number and then actually set or you might want to log all of the changes internally. You know? Like, at this time, you you changed this value from 6 to 7, and then 30 minutes later, you changed it from 7 to 8. You you could do that all in a, estate with getters and setters.

Yeah. And a lot of times, you know, I think about, like, the audio player on the the syntax side. There's a lot of stuff in there, and you wanna have specific methods to you know, when I click, you Node player Scott play with an Pnpm 3, a lot of stuff needs to happen. And it's nice to encapsulate all of that inside of some kind of, like, state object where that that state object or class is keeping track of all of the things and accessing the instance of this this state itself. Or or even, like, like, something like,

player Scott current time equals 36 seconds. Totally.

Then you could say, oh, well, I I need to do several things. Maybe we have analytics that the user jumped ahead. Maybe we wanna update some UI. Like, there's there's several things that might want to happen when you do that, and it's nice to just keep the simple this is just a JavaScript object, and I'm updating properties, and all the logic of what happens is is contained inside of that store. Is it called the store, or now is it just called

a state? And people call it a store. I I I think Yeah. I think that's just kind of a generic term.

Yeah. It's not specifically a store in their documentation, but, you know, I I think you anything that stores data, you could consider a store. Another new rune here for Scott specifically is called derived.

Now deriving state is a concept that many people are familiar, in view. I believe it's called computed state. But, basically, the idea of a derived state is that you have state that the value is dependent on another state value. So let's say you have a shopping cart full of products. They have prices, and that is in state. Right? You add something, that shopping cart changes. The derived state might be the total or maybe even, like, subtotal or those things Wes what you're actually doing is deriving the Node state value based on the other one. When one changes, this one also changes. And and that's what you use derived for.

When when a changes, b should also change.

And a lot of people might wanna do this in, like, in effect. Right? Or, like, in React, like a use effect. When this dependency changes, do this. But in this, you can just specifically use the derived, to do that. If you need more complex functionality, like more than just a simple expression, there is derived Scott by, which takes a function. And inside of that function, you can do your advanced things, like a reduce of all of the things inside of your shopping cart to get that value, to then keep that value to be reactive.

So derived and derived by are are 2 runes that I think they have been taking a little bit of getting used to for people because they'll often reach for effect. And so there's, like, been a common line from the Svelte team is like, hey. If you're reaching for effect, maybe think about, can you use derived first, before Yeah. You you go down that path?

Yeah. If there's like a saying is don't store what you can calculate.

And that that's kinda comes from, like, the database community where, like, if you have somebody's first name and you have somebody's last name in 2 columns, don't make a 3rd column called full name because then when somebody updates their name, now you're playing hot potato trying to update 2 different spots. So just store what you need and then derive what you you want from from the rest of that. And that's not always the the best use case for for databases. Sometimes it does make sense to simply just store both pieces because it's faster to query.

But in the case of a reactive application, it often makes sense to simply just store the pieces you need, like prices, and then derive what it is you need, like like a total added up in entirely.

Yeah. Yeah. And, specifically, you know, one of the the big use cases too, we'll talk about effects in just a second. But if you're if you're trying to update a state value inside of an effect, that is like a a big red flag that you should probably be using derived. Yes. Yeah. You don't wanna be maintaining 2 separate pieces of state,

and having to remember. Like so I I updated Adam Argo's gradient Scott style. This is the best website in the world for generating, CSS gradients, especially with all the new features that we have in CSS color and and radial gradients and conic gradients.

And it was on, like, a old version of Svelte and SvelteKit, and I had I upgraded the whole thing. And it actually the the upgrade thing pointed out some issues where, there was a function that returned a value. So it was, like but it was not a pure function, meaning it was going outside and also updating an external store.

I think it was like the color picker. And then what had happened is there was 2 spots in the application that were holding the current color, and they had to be kept in sync whenever you did it. And, like, that was it was causing issues. Right? So that's a perfect use case for for a drive. You should not have that information stored into spots.

Totally.

Yeah.

And let's get into effect here. Now effect is essentially the same as what you'd have use effect in React in in in a in a broad sense, where, basically, this runs when things change. Right? The difference between React and Svelte in many many ways, not just this way, is that because Svelte is a compiler, it can understand your code in a different way. Right? So because Svelte is a compiler, you can use a an effect, and the effect will automatically track what's inside of your effect. And it knows that if these things change, then this needs to rerun.

That doesn't so it kind of inverts the the the React Node. Right? Where the React model is, I need to tell you explicitly which things we're tracking, where Svelte says, we're tracking every reactive variable inside of here. And, there is an option to not track specific variables if you want to untrack things.

But for the most part, I find myself not really needing that that often. And for the you know, even with with React, people say not to use use effect that much. In effect, it's probably the same way. Now there's times when you do need to use effect. When something changes, you need your application to react in that way, you use effect. So dollar sign effect is just takes a function, and the return of that function is the cleanup, so it runs when the components destroy. Yeah. And just like React land, this replaces, for the most part, the on mount, on destroy, life cycle methods. And we move to just this effect where effect will run, you know, on mount and on destroy. Now there's also this effect Scott pre.

Now effect dot pre, it says you may need to run code before the DOM updates, and then you can use effect Scott pre. Otherwise, the DOM updates then effect runs. Right? And and I, again, I I think this is, like, pretty familiar with how people use this stuff. I do use effect dot pre sometimes if I'm, like, building a, like, an auth auth guard system. Right? Like, when my component's loading, I wanna check the state of authentication.

I don't want the DOM to render. I don't want the DOM to even touch that. If it hits that effect, I want it to check to see the authentication state before it does anything. And so that's what I would use auth dot or effect dot pre for. Some use cases for when you might want to use an effect is

a what we we call them side effects in programming, meaning that you need to go off and do something elsewhere. So, for example, if you need to write to Canvas, when a value changes, in the past, I've done if you need to update the title tag of the the browser, you could use an effect. I although most most things now have title tags built in. Mhmm. If you need to send stats off to a third party API, either when something loads or when something changes.

So for example, if you're watching a course and the current time changes, you may want to sync that data to an external service or API that tracks where you are in that specific video. And if that's the case, I would probably listen for changes on that data, which is like video Scott current time. That might be a store.

And then every single time that changes, it runs that effect, and and you could put a fetch request in there or something like that, which would go off and and update the external API.

Yeah. What what's interesting too, Wes, is that you can do, like, nested effects, which, man, there there's let me tell you. There's some, like, weird things in effect that I truly do not understand, and maybe it's just I haven't had the use case for them, like having a nested effect. Or another one is effect Scott tracking. Let me read you effect dot tracking, which I've I I cannot tell you how many times I've read the docs, people explain this to me, Node. I've done it all, and I still don't get it. For some reason, it's I have a mental block with this one. I it's like remember when Wes, like, Redux first came out? I was just like, I don't I don't get any of this until I, like, really got it. So I I'm sure it's, like, something I just need to hit, before it makes any sense to me. But effect dot tracking is a rune that tells you whether or not the code is running inside of a tracking context.

And their demo just shows running effect dot tracking outside of an effect, and it returns false. Running effect dot tracking inside of an effect returns true. Okay.

Sure.

I'd yeah. I I Node to spend some time with this Node, because I'm sure there's a valid use case for it. But Yeah. Let let me let me get rid of it.

Oh, I see.

I I I see.

The idea here is that if it is being tracked, meaning that, like, will this ever rerun? Will it ever rerun? Like, if you put it just inside the script tag at the top of a Svelte thing, it that only runs once when the component is is parsed. Right? Mhmm. But if it's inside of either inside of a template or if it's inside of an actual effect, then you know that that code is being tracked for changes and may rerun, at a certain point. So why would you need that? That is that is a great question. I'm too dumb for this hook. Do not know.

Or for this I just called it a hook. I'm so sorry, Svelte folks. This is Yes. The the Svelte nightmare is, referring to these things as hooks. Deno. I'm I'm too dumb for this room. I think a lot of these things Yarn, like

if you are building an app absolutely from scratch with Svelte and you're doing absolutely everything the Svelte way, then you're not gonna you're not gonna hit these things. But, like, actual applications are, oh, we have this third party charting library that works in in a certain way. And and when you're trying to, like, cross that bridge from declarative code that is Svelte to imperative code, which is a lot of, like, JavaScript libraries that you may have. Sometimes there's, like, oddities, and you and you need to do things imperatively inside of inside of Svelte.

There's all these little escape hatches, and I'm assuming that this is one of them.

Yeah. Yeah. For sure.

There's there's a number of other little things like effect dot root or whatever. But, basically, what they say is effect is escape is an escape hatch. And if you need it, you can go deeper with it. Now another rune that there is now existing is props. Now props in Svelte have long been one of those things. I think that trips up new people. Because in Svelte 4 and Svelte 3, you had to export a variable to have it be a prop, which I think even felt weird for me. I think the explanation I got for it made it make more sense, but it still felt weird doing that. And now, that's gone now. Now we have a dollar sign props.

And dollar sign props essentially returns an object of all of your props so you can destructure your props from here. Meaning that TypeScript for this has gotten both easier and maybe a little bit more verbose sometimes because the the type inference was a little bit better with the export props, because it could infer some types a little bit easier. But with dollar sign props, you now type it just like any normal TypeScript code. Right? It's an object. You just type it as if it, you know, were an object. And so because this is an object, you can have default values for fallback values.

You can define something as being optional with, with TypeScript.

You can do spread props, really, or arrest props. You know, when it's like spread arrest, I always mess that up. I don't know if you do. When you spread versus rest You,

you spread into, into a function or you spread into, like basically, when you're putting something in Into. Yeah. Into an object or an array or into a function, that is a spread. But when you are collecting, data, that is a rest.

Yes. Correct. So that that's cool. You could do that a lot easier Node. There used to be some, like, weird dollar Node, dollar sign, Wes, props, syntax that was just like

it felt like they they truly just like, we gotta do this somehow. You know? So now it makes way more sense. Yeah. This is nice where you can you can collect them all. Right? Previously, you had to know ahead of time what they all were.

In this, you can simply just use dollar sign Node props, which is helpful when you're doing, like, wrapper components that simply just need to pass down all of the props. I remember I had to use that double dollar sign somewhere on the syntax website.

You just collect them all and then pass them along. It was it was kinda weird. And the the export thing always tripped me up too because you were exporting,

and then 2 lines later, if you you can use it, but, like Yeah. I'm not export is for files I know. Not for different parts of the file. It was one of those things that you just like, or like, I get this. This is just how it is. Right? Once you you get used to it, you don't even see it anymore. But, Yeah. So that's how you do props now. And so the cool thing about state in Svelte, just like view and, I believe, Angular I I know Angular one at least.

You could bind state to an input.

Bind Scott in in general, you can bind, state to a a div and get access to that div, like you would like a ref in React or something. But if you're binding state to an input, sometimes you want that input to be nested in another component.

And so in the past, you always just exported that prop and you bound it. And if you updated the state in a child component, it updated the state upwards, which is great. But you want more control over that. So what they did is they introduced a bindable run, which basically says, hey. If this state needs to be passed back up to the component, then inside of your props declaration, you have to say that this this particular prop is equal to bindable, and then you give it a default value.

Because that makes it more explicit to say, hey. When I bind this variable, I warp it to pass upwards, which is nice. Again, it just adds a little bit of clarity. I I think that this, along with other things, JS, like, something that, you know, detractors of the new Scott stuff would say, we're having to do more, right, to do the same amount of stuff. But it does make it a lot more clear for sure. But the the idea with that is if you have a prop coming into a component, you don't necessarily know if that variable

or or prop being passed in is, like, bound to a state somewhere up the tree or if it's just a like a like a variable somebody passed in as a prop. Right? Yeah. Okay. Yeah. It just makes it more clear. I mean, the functionality is the same as the way it used to work without bindable.

But now it makes it so that if you you pass something and you're binding it in, not explicitly bindable.

So yeah. Well, it's it's still better than React state because in React, you have to pass the actual state itself and

the updater function if you do want to to update that thing. So Yeah. I'm I'm I like it. Yeah. I don't I don't mind it. Certainly, I don't mind it. And you you only bind state so much. I mean, obviously, you do inside of, form inputs a lot. Again, I bind state to, divs if I want access to that. Not just divs, but, elements if I want access to that element specifically.

And another new rune here is the inspect rune, which, inspect, low key, really, really cool. Now inspect is basically a console log replacement, but it's for reactive variables.

The reason why this is cool is that unlike React, a Vue component or Svelte components don't rerun top to bottom when something changes. Right? A React component is a function. Something changes, that function reruns. That has its strengths, and it has its weaknesses. Right? The fact that it's rerunning every time. And Svelte is variables are tracking. And if a variable changes, then either the effect that that variable is used in or the template Node, that reruns. But the rest of the stuff doesn't rerun.

And because of that, you can't just put a console log on a variable and actually have it console log every single time something changes because, you know, that code's not rerunning.

So they came up with a dollar sign inspect. Now the coolest thing about dollar sign inspect is you pass it a reactive variable, and it doesn't just tell you it doesn't just log out the value.

It will say, Sanity, and then the value, and then it'll say, update, and then the value. So you can tell if this is the initialized value or the updated value of that variable, which becomes really handy when you're trying to debug when is this getting set, how is this getting set. Oh, this is actually coming in as an empty array instead of a populated array. That's either something wrong, or now I have to check to make sure that those variables actually exist in the template code.

And and it's nice. There's also inspect with, which basically allows you to have a a callback function.

In that way, you can throw debugger statements in there. You can have a little bit more control over it. I pretty much never use inspect Scott with, but then again, I basically never use the debugger because I'm a, Yeah. I'm a low level developer.

Can you can you use inspect with a derived? Because, like, I feel like that'd be kinda nice to just watch for changes of, like for example, if you're trying to track the currently focused element or something like that and you're you're keeping that in state,

then you could simply just watch when it when it changes. So it's not just for state. It's also for derived state? Yes. It's for any reactive value, even nested reactive value. So let's let's say you had you created your class state object and their state are derived inside of that. You you can inspect those as well and and get those outputting. It it's nice. Now it's a little annoying that you can't just do console log, but I get it. In the past, we used to do this by doing dollar sign, colon, console log to make console log a reactive statement.

This actually is nicer because you do get that init or update, which you didn't get before.

I released a small little v s code extension called Svelte Svelte 5 wrap or inspect wrap or something. I'll post a link to it in this that, binds command I to just wrap the currently highlighted variable in a dollar sign inspect. That way you don't have to type it out every time. So that's something a little shorthand I gave for myself.

There's also a room called host, which is for custom elements or web components.

So if you are having your Svelte code being output as web components because that's something you can do, the host, Roon, let's see, provides access to the host element. Pretty straightforward. I've never used it. I've never output my my Svelte components as web components, but you can do it. So yeah.

Next one we have here is snippets. This is something that has been on my grown list for a while, which is you're not able to define more than 1 component in a file, and you you still can't do that. But my use case for defining more than 1 component in a file is often I'll I'll loop over something, and I I'll want to put the like, let's say you have a list of items, and you'll have a unordered ESLint, and then you loop over each item, and then you you render out a list list item for each of those. Right? Often, I'll want to put that in its own like like, just above. Right? Just so I can put it in its own thing. And and the big use case I have there is often I'll want to, like, create a couple of quick variables before I template it because it it gets a little bit fuzzy. And it's not enough to make it its own component and its own file, but it's enough to want to have to do it separately. And now we have this idea called snippets Wes you can define reusable pieces of, markup or or of template, and you can you can pass it arguments. You can type them.

And, it's it's pretty nice. Yeah. And, because of how snippets work, they also replace slots within Svelte. Now a slot was kind of how they did children.

Mhmm. You would have a Scott. You could have a name slot, and then you could have named, children. But now, inside of components, children is like React. It is the word children.

So you can use children, and children are now considered a snippet. Meaning that you can actually create in the same way you had named Scott. You could have named, snippet areas that allow you to, you know, put things as children inside of different parts. Now, I I don't you know, the syntax is fine. I think it's nice to be able to do this. I largely am still creating single file components. There is times, like, certainly, where I'm creating snippets, ESLint items, and those types of things to make it easier.

I you know, a lot of times when I am creating a little thing like that, I want an individual item to have its own maybe its own function or its own, you know, functionality in there. And then I'll overach for a single file component. It's a little bit easier. But, to to render any of these things, you use a template tag at render, and then you render the snippet name. So if you pass children, it's at render children. Right? Yeah. You still can't create variables inside of a snippet, though. Right? Like, if you wanted to

create a variable before you go ahead and render something, that's not something that you can do with this. A snippet must only contain markup. You can use the at const tag

Yeah. But it's it's not it's not great. Yeah. I agree with that. Yeah.

I know. We I was talking to a bunch of people at, the conference last week, and they're like like, what don't you like about Svelte? And I was like, that at Scott is killing me. I know. You couldn't the reason why, for people who don't know, at console allows you to define a variable in a template tag inside of your template, but it's only allowed as the immediate child of an if each or snippet. Oh, you can use it as an immediate child of a snippet.

Okay. Yeah. Okay. Yeah. K. But Yeah.

Yep. And, also, you cannot export a snippet, which makes sense. I I I think You just make it into a component at that point. Yeah. That's true. Just the the overhead to having to find all the props and everything is is kind of annoying, to make it a separate component.

Yes. It is annoying. You know, it'd be nice to just, like, one click encapsulate as component, turn into component or something. Another new change here, beyond snippets, I do find snippets to be handy. Like you said, it's nice to be able to create a component without having to make a new file.

But another new change is that the, events before in Svelte used to always be, like, on colon and then the event name. Right? And now there's no colon anymore. So on colon click is now just on click. Even with custom events, you create a custom event. It's just on custom event name. And this is really nice for a number of reasons.

But one of the the things that I take advantage of is in Svelte, let's say you have an attribute or a prop on something that the prop is the same name as the thing you're the variable you're passing into it. So for instance, if you have a function named on click and seven in in React Lane, you'd have to do on on click. I've even forget what is in React now. It's on click equals curly brackets on click. Right. In Svelte, it's just curly brackets on click. So you're just basically saying, hey. The on click is a thing named on click. And that works for all all props in general, but it's nice for these functions, especially if you have a small component. It has 1 function. That function is a click function. Yeah. Just say on click, the name of the function. On click. Shorthand. That's one of my wish lists for JSX is Same. Yeah.

All the time.

Yeah. You have, like, type equals type and, name equals name. You know? Like, you're just repeating yourself over and over again, and it's nice to be able to do it. Yeah. I see. So is that why they they took the on colon click? Because I kinda like the syntax of that. I guess it's not very TypeScript, though.

Yeah. Yeah. I HTML y? I think it's to get HTML y, and the side effect here is that you can just do it like this. Another thing too is that, like, now events can be passed in as props.

Before events, you had to do, like, a custom event dispatcher.

Now you just pass a function down in JS a prop.

That that prop is named on click, then you just the prop on click goes directly on the button on click. And, again, it's just, like, feels really, really nice that way. Sarah, let's talk about this one. The Sarah font on the website. So they,

Rich Harris is always known for for being a bit of a contrarian. And a lot of the times, he's he's right, meaning that, like, he's used, JS doc instead of TypeScript Vite. Underscores instead of whatever, Vite instead of webpack.

But he got one wrong. They were on Snowpack first, and then he made the choice to go to Vite. And that was, like, a big try. I actually talked to him about that in our interview. And it was like, how hard was that to make that call knowing that, like, people are gonna be writing think pieces and opinion pieces about Oh, yeah. Yeah. I bet.

I know. Right? He he got one wrong, and that is the Svelte entire Svelte website Node uses the Serif font. Like, it's like a Serif font. Microsoft Word document from 2003.

I'm I'm agreeable. Maybe that's it JS I'm just too much of a fanboy to see, that I'll just say, hey. I like it.

I like the Serafont, man. You know what? Everybody thing that bugs me the most about the web these days is that every single site looks like Vercel. And nothing against Vercel. Their site looks very nice. Everything looks like that. And it's also boring. Every single doc site looks like DocuSaurus and you look at you're like, alright, DocuSaurus, which is fine. It it works. It's predictable.

But I am bored, man. So, like, if I see somebody taking any sort of chance with just just simply by using a serif font, I'd I am not going to complain about that. The amount of people that are like, that sucks. It's like, who cares, man? Yeah. Who cares? It's really what I care. Good. Yeah. Just go on the website and change Wes

k font family body Yeah.

Variable to monospace

looks way better. Well, here's here's even an easier thing, Wes. You go to the doc site, and you click on the little a in the top right, and it makes the body font into a sans serif font.

Okay. I had enough people complaining about it that they had to add it. My whining. Yeah.

I don't have any beef with it. I'm gonna be honest. And and so many people complain about it that maybe I'm just being contrarian.

But code

is weird.

I I understand Serif for, like, paragraph text. I understand Serif for headings.

That's totally fine. But the sidebar Oh. Has all of the, like, the runes and the template syntax is in like, no one's coding in a a serif font.

You know? Svelte folks, if you wanna make one change to this, make any piece of code that's in the sidebar

into a monospace font. I think that's all set for me. Yeah. Because the the code samples are in a monospace font. Right. And and the paragraph tags are fine in in that. I think even the nav at some point was in serif. Is that true? I don't know. Honestly, I I'm Change the logo. If you care that much, change the Svelte logo to be serif font. You know? Make it Times New Roman.

Times New Roman. Yeah.

Georgia.

Georgia. Georgia, by the way, was the font that I used for everything back when there was, like, 6 fonts that you could choose. I was Verdana all day long. It. Yeah. I was a Georgia man. Yeah.

Was that a slight?

No. No. I could just see it. I could just picture it. Yeah. Oh. I yeah. I don't I don't know why with Georgia. Yeah.

Yeah. Georgia was was pretty nice. I my my new thing, when people tell me something like I would use Verdana, you just say explains a lot. Yeah. It is. Node actually poof.

Yeah. Yeah. I know.

Oh, one more thing here is, before we get into some other stuff JS performance.

Man, one of the big changes that they made a lot of this stuff is to make Svelte better, faster, smaller, all of those things. And I think it's even, like, setting up for future improvements. Like, the fact that the state is is signals based is that if the browser eventually gets signals or JavaScript gets signals, they'll be able to eliminate a portion of their code. So they're kind of thinking ahead because I do think that's inevitable. Right? But as far as, like, even, bundle sizes go, Ben McCann posted a really great post showing the same project in Svelte three was g zipped 987 k Bos, and Svelte 4 was 4 18 k b's. So that's a massive change. And then in Svelte 5, 244 k b's. So Wes. So the same site went from 98 to 418 to 244, just with library improvements. So, yeah, pretty sick. That's

that's really nice. And does this this website also shows it in

all these other frameworks as well? So that's that was from the tweet that I had posted in the show notes.

This this, have you ever you you've seen this this is cross Krausest? I'm so sorry. Krausest.

This Krausest JS benchmarks table is pretty massive. If you wanna get any, like, ability to read this, you kinda have to click which frameworks. But then even that is like a massive table. You just deselect all and then select the ones you want. For the most part, Svelte is very, very fast on these things. So if we Vercel been looking at libraries that it's competing with in terms of the one that you might wanna look at is the weighted geometric mean, which is the second from the bottom. You can see it's like a 1.02 for Janilla vanilla j or vanilla j s is 1.05.

Right? In terms of the duration in milliseconds, where svelte five is 1.13, which is great for Svelte considering the only things that people typically use that are near it would be like solid j s is a little bit faster at 1,100,000 Node j s. Shockingly, 1.09.

But then you have to scroll pretty Yarn, before you get to other things that people are using. I remember Inferno JS was supposed to be very fast, 1.15.

Mhmm.

Svelte classic mode, 1.16.

The 1,000,000 JS React implementation

is Insanely fast. Even faster than Wes, how? It is. And that's crazy to me. I don't know what the caveats there or are if there are any.

Vue Vapor is 1.26, so quite a bit further back.

And then, like, man, you gotta keep scrolling. 1. Hold on. Let's go all the way to the other side.

Blazer Wasm 8. Blazer

Wasm is 8.

Sauron.

Alpine, 2.83.

And, of course, this is just Yes. This is what? It's measuring

fast? Like, what does that even mean? So there's all these number of tables here. So create rows, replace all rows, partial updates, select rows, swap rows, remove rows, create many rows. And this JS rendering? Yes. And then so the very the second to last 1 is a weighted mean of all of those. So you can, see that, like yeah. So the that's definitely I I don't know where React with Hooks is in here, but it's quite a bit faster. Considerably faster. And then the other ones on here are like memory allocation or transferred size in in 1st bite or first paint.

So there there's this table is definitely worth spending some time on if you wanna see. But the long and short of it is that, Svelte is approaching Vanilla JS speeds JS is Million JS as JS Solid JS. So these things are getting very fast and that's good for all of us, especially when the upgrade path is running a migration assistant and getting a smaller bundle, getting faster. So It just just comes for free. I just say that I just said that,

Alpine JS was, like, on the on the slower end.

That doesn't really make sense to compare that because people aren't building at their entire website in Alpine JS. They're they're just sprinkling it on where they need it. Right? And this is this is this is doing apples to apples,

the entire website. Word. Yeah. Totally. So definitely worth spending some time in looking at. But, again, it's not the end all, be all. And and, in fact, you know, largely what determines the performance of your site is, images and crazy stuff that you're writing. So yeah.

But Svelte, I will say, gives you less foot guns in that regard Wes with React, because the component reruns every single time, you have to worry about, hey. What is actually running when this component reruns? Wes Svelte is like, what is changing when this variable changes?

Deno Bai, we had him on the podcast. He's the creator of Million JS. Million JS is a, like, rendering what, Like, a a React rendering optimizer, where it does kind of the same things as Svelte, where it figures out what needs to update rather than rerendering the whole thing.

And he's working on this tool called React Scott that basically just, like, visualizes which components are rerendering, and it's it's amazing.

He goes on, like, GitHub and Pinterest and, like, lots of very large websites, and they're all the whole website or is rerendering every single time you scroll or something ridiculous like that. And it's it's not because the developers behind it are bad. It's just like it's just like a foot gun. You know? And and the almost always the solution to these is just wrap a memo around it, and the rack compiler JS going to fix that. But it's it's at a point now where it's like, yeah. Like, do it for us because Yeah. Right. Highly paid devs at some of these big companies are not realizing that it it could potentially be an issue. I think a lot of the stuff is like, well, nobody nobody noticed that that was slow for, like, 10 years, until you build this tool. But there's the other flip side to it JS of, like, you don't have those foot guns in Svelte at all. Yeah. And hey. You know, I think React is realizing,

that there's a lot of benefits to using a compiler like Solid in Svelte considering Mhmm. There is now a React compiler. There was a lot of talk about the React compiler at React Summit. So it's definitely seems like it's obviously a good direction to go in. But that brings me, I guess, to a bigger point that the Svelte community has been arguing over JS is Svelte becoming React? You'll see a lot of posts on the, Svelte Reddit about stuff like this. And I do think it's largely because they chose the word well, 1, it's because you don't have reactive variables anymore, but, 2, they chose the word effect.

I think I think simply choosing the word effect, makes people say, oh, oh, React's got that word. That's React.

It Everything has that that, signals has like, signals has the idea of an effect in it. I think it's just that.

Because in reality, the things that are still, the reason why you pick Svelte, it's still, simple, and that's Scott, like, a great word to use. But, the compiler is still giving you a lot of, good magic.

The, state is still mutated. You don't have to do the whole set state, git state thing, and effects are automatically tracked. So, you know, it's the same way we did reactive statements in Svelte. It's now just a little bit more clear, and it's a little bit more dialed in. Right now, we don't have unmount, un destroy, whatever, and reactive statements. We just have reactive statements named effect. So in my opinion, I you know, this stuff aesthetically might look a little bit more react ish, but that's only surface level. Once you get deeper than that, it's still, the concepts the core concepts of Svelte have not really been rethought that much.

Alright. I have some, synonyms for effect for you. You you get to choose what the new API is called. Give it to me.

Consequence.

That's a good idea because Yes. Like, they say, ah, you probably shouldn't use the effect if if you don't know what you're doing. Right? Like, this could have consequences.

Ramification.

Oh. Repercussion.

Okay.

Conclusion.

Not really. Outcome.

Sequel.

Reaction.

I think I think I like, ramification.

I like ramification. You know what? It could even be, like, reactive. Right? This is a reactive area of code.

Yeah. Does not matter to me. It could be a doll it could be just the dollar sign for all I care. But dollar sign with a a callback function instead of just dollar sign, colon, to me, reads better and, do it a little bit more detailed. Especially for, like, multiline things where you had to do that weird, like, dollar, colon, open up a block. Yes. That was that was odd. Exactly. It was odd. And I I think a lot of the stuff makes it less Node, and maybe it being more JavaScript y means that it looks a little bit more React. But for the most part, Svelte's special sauce is still there, folks. There's there's nothing, stopping that. Let's talk about the migration really quick here. I know you had mentioned you did a migration. I migrated to Cintex. 3. Yes. You ran 3 migrations.

Let me tell you. I've run a number of migrations, whether that is from the beta of SvelteKit to the final release of SvelteKit, from Svelte 3 to Svelte 4, Svelte 4 to Svelte 5. Nobody does migrations like the Svelte team. I don't know.

Honestly, I don't know which individuals are the ones who are making this so good. The shout out to the entire team because I ran the Svelte migration assistant on the syntax website, which is not a tiny code base by any means.

And I would. I ended up having to touch, like, 10 files afterwards, just to clean up some things, and it told me which files. It's not like, alright.

Figure it out. There's things broken. It's like, here are the things that you need to to look at. Alright. I looked at them, swapped some stuff, made some choices, and bingo bango. I completed the migration in less than, like, an hour, which is kind of an absurd statement. I've never I'm a refactor guy. I've never refactored a code base that large in an hour that easily. So shout out to the Svelte team, the migration assistant. It worked really well. Yeah. And, like, I I ran it where I so I upgraded Svelte 3 to 4, then Svelte kit 1 to 2, and then Svelte 4 to 5.

And I'm I must have spent maybe 12 and a half minutes fixing a couple little effects. And the things that I fixed were actually like a bug in the not a bug, but like a a bad practice in, the thing where it was, like, updating a store as part of a pure function. And it it, like, it uncovered, an an actual issue. So, like, I was amazed at how well that actually worked. Yeah. Almost to a point where, like, I had to I had to actually go into the code and read it because the code looks significantly different than than it did before.

And if I'm gonna have to jump into that at some point, I have to understand what's going on here. Yeah. I don't know what they're I mean, I I get that they're they have their their tools. But the fact that it it JS so painless or at least it works so well when you know that there is such a wide variety of potential code bases and things, is is pretty amazing. So shout out to anybody who worked on the migration assistant.

Worked really well.

A big thing here is, I guess, what's next for Svelte. I had to, when I interviewed Rich at JS Nation again, I asked him very specifically.

Alright. We just have massive release. Like, what's next? Is it just felt kit 3 or what it what what what is next? And he told me that they're going to be releasing a ton of little things over this, like, this whole Christmas break time area Wes what do they call, like, an advent or something? Yeah. I I don't know if he specifically used the word advent. I'm trying to remember in my brain. But he's basically saying that they're going to release a ton of little features here and there as these weeks go on, and one of which they've already announced JS error boundaries.

So you're going to have easy error boundaries. He said that's something that people have been asking for for a long time, but they put off because they felt like it would be like a more difficult project. And then somebody just knocked it out in, like, no time. And they're like, oh, wait. Never mind. It's actually really nice and easy. So error boundaries are coming. You know, I think they want to do context better. Context largely works the same as it does in React without providers.

But, you know, you you have to type whenever you retrieve context. So it often feels like you're throwing your your data in a black hole, and then you're retrieving it and casting types onto it. So, like, some kind of, like, more type safe context API would be really nice.

I'm I'll see. I don't think you need context as often as you do in React because you can simply just import and export stores. Right? A lot of what people are using context for is because they like, with React state, you can't just export and import state like that unless

you create your own custom effect to hold it. Yeah. Well, I think there are certainly some use cases, specifically, like, when you get into server side rendering and you wanna make sure that you're, you know, if you create state that has, you know, sensitive data on the server side or something like that, that could be spread amongst users.

So you do have to, I guess, be a little bit careful.

So context, I I do use context somewhat. Most of the time, I am creating state in that way. But yeah.

There's also talk of potentially, like, class helpers, like, new things where you could have more advanced syntax for toggling and changing a bunch of classes. I know specifically, like, Tailwind folks really ask for this kind of stuff because, they got a lot of classes over in Tailwind land. So you gotta have a means of toggling a whole bunch of them beyond a bunch of if statements. Active and

active class or,

Yeah. But even, like, active class or whatever this one. Is now super easy. It's already super easy in Svelte because you can do there is already, like, a shorthand, for toggling 1 variable, but it's when you have, like, or toggling 1 class. When you have, like, 8 classes you wanna toggle again, it it gets a little bit rougher. You have to do a whole bunch of things. I I think that is a pain again specifically for Tailwind folks. But either way, I think, by the time you're hearing this, it will be, you know, into December, and we're gonna start to see little stuff trickle out here and there, and it's gonna be really super exciting.

Is there any did you ask more about this, which is data fetching at a component level? Because that's that's still on my Oh. My wish list as well as like, right now, SvelteKit must fetch at a page level and pass into components.

And, like, it doesn't that doesn't make sense to me because everything is is so component based. I'd rather just

fetch the data in the component and the page figure out what it needs. Yeah. I don't I didn't ask him about that, and I should have. I will because that is one of my things too. I want, like, islands, and I want Yeah. Data fetching at a component level. Like, those types of things for me are the things that I would really like to have. Yeah. Actions at a at a component level will be nice as well. Actions at a component level. Yes. I would like all of that stuff.

So hopefully. Yeah. We'll see. I'll I'll have to ping ping the Svelte channel about that stuff. Cool. What what do you wanna see in Svelte five and beyond? What do you wanna see in the next version? What do you wanna see in SvelteKit? Are you using it? Are you not using it? Why aren't you using it? Too much magic, not enough magic?

Do you think it's becoming React? Let us know. Leave a comment below. If you're on YouTube, we love comments. All, you know, is the best place, I think, to leave a comment is probably on YouTube. Where else? Do they do comments now on Spotify? Did you say that? Yeah. Yeah. There's there's they've done comments on Spotify for a long time, but we've had to approve them, and we weren't able to reply to them. So it was it was often just like a, love this episode Oh, yeah. Or, I think x about y, which we love, but now you can like, now they're approved by default, which is is great.

So they go out right away. So if if as soon as we release an episode, we got thousands of people listening to it. It's nice to see what people are talking about.

We also can reply now, which is great, because often people are saying, like, what was that thing that you mentioned? Yeah.

X, y, and z. And it's nice just to be able to type it in rather than me like, I don't know who you are, Danny.

I have no way to contact you.

Yeah. Just yeah. Yeah. Definitely feels like you're just tossing comments down the hole, and now now we can actually respond. Cool. So, definitely, leave us a comment on,

on this one, please. We, if you're listening on Spotify, we'd love to see how many people are are are reaching this. But, actually, I guess Wes know how many people are reaching this far, but,

yeah, leave us a comment. We know. We're watching you. We're watching you listen to the podcast.

We're not. Cool. Alright. Yeah. That's all oh, no.

Shick Shick Picks? Yes. Shick Picks. Shick Picks and Shameless Plugs. I have a Shick Pick for us today.

One of my the 1st video games that I got when I maybe not one of the first ones, but for the Wes, I don't remember when we got it or how.

But it was Dragon Warrior, and it was the first one. And, man, I, as a child, did not really understand. I thought the game was cool. The music brings back so much nostalgia, and I would, basically, I would go to out of the little village. I would fight some, villains and I would, you know, win and whatever. And then I would go a little bit too far and then I would die and then I would say, I have no idea what I'm doing here. I did not understand how to play the game. But, eventually, later on in life, I went back and I played it again. And I you know, after you learn how these games RPGs work, I beat it. Well, Dragon Quest 3, it was called Dragon Warrior in the States, but it's Dragon Quest in in Japan. And Dragon Quest 3 was just released in this really incredible remake, just very recently. And I I it's like an HD remake, and it's so cool Wes. They combine, like, pixel art with depth three d and lighting effects and all this stuff. So it feels like this old school, new school approach. Octopath Traveler and some other games have taken this approach. But it feels so cool in practice in terms of just aesthetics. And, man, this game rules. It it's like bringing me back to childhood in a certain way. I never got to play Dragon Quest 3 before, and it's a long game. It's really super good. It's a great remake on top of, it doesn't feel like an, a game from, I believe, the nineties.

19 or no. Not yeah. 1988.

Is that when it was initially released? Holy cow. Holy.

Yeah. So it doesn't feel like you came for 1988.

Yeah.

Sick. Sick. Sick. I am going to sick pick this shirt I'm wearing.

I've said in the past, I am a I will do anything for a T shirt. They these Wes code kinda oh, I I should move my my thing.

Wes code is a developer focused T shirt company, and they sent me this. And they are some of the nicest T shirts I've ever worn. They're really heavyweight, kinda oversized look.

Yeah. You can see on the on the back, it's, check it out. Dresscode.dev.

I gotta get out of them. Yeah. They got some some really cool stuff. Yeah. They said they send you one as well, so hit them up because

they've got some some pretty cool stuff that they Yeah. They're working on. I love following them on Instagram. They're one of my favorite follows because they do release cool stuff all the time. Awesome.

Shameless plugs. What do we wanna plug right now?

Let's plug the ESLint YouTube channel. As always, youtube.comforward/atsyntaxfm on YouTube.

We're releasing all kinds of stuff and we'll have a little bit of an announcement here about some stuff we're gonna be doing on YouTube in the very next episode.

So we're gonna be. We have been, but we're gonna continue to be more and more active on YouTube, folks. So, if you wanna make sure you're getting all the fun stuff that we're doing, which by all means, there's gonna be a lot of fun stuff, then, yeah, check us out on YouTube.

Buckle up. Alright. Thanks, everybody. Catch you later. Peace.