Is there a release dated scheduled for Svelte 5? I'd like start to study it and use it in a project with SvelteKit, but I have doubts about if it's a good solution. Thanks.
@@JoyofCodeDev At least, can you tell me if it will be released in the first quarter? Haha. Thanks for getting back to me. I've been looking for some info, but I can't find some clue.
I like everything besides the location of where you write the snippets, on one hand it makes sense since your template language (html) is always at the same place where you expect it but the composable part of react does make the return (render) look cleaner while the snippets still make it look a bit ugly, other then that great stuff from svelte team :)
I get thay all of this features are meant to fix problems and also give more control to developers. But I have to say, a big appeal for me was that svelte was simple. Its limitations are what makes it simple. For seasoned developers and developers using svelte in large websites this is probably very helpful. For me this makes it closer in complexity to other frameworks and less unique. I still like it more, just not as much as before. I still like how it does a lot of things especially around adapting JavaScript libraries to work with svelte, and stores.
i seriously think they have just lost their WHY in copying other frameworks ( like why svelte was formed & why it was different from other Front-end frameworks ) . They have lost the magic and simplicity .
Wtf are you guys talking about. You might be fine with its limitations for your simple use case, but most people want svelte to grow beyond its limitations so it can become their main framework. Svelte simplicity didn't disappear. You can literally do everything u were just doing until now, almost the same exact way(or the same exact way even), and the only thing those updates are bringing are even more powerful tools. A framework having lots of tools doesn't make it more complex. It just has some complex tools for advanced users. The same way, react has 15 hooks, but people are pretty much fine with only useEffect, useState, useRef and useContext 99.99% of the cases.
It bugs me a bit that effect and derived values change based on things that are hidden from the user. With $ syntax, you can tell what the variables are that cause a trigger, but now there are hidden side-effects. Its like we went from dependency array, to if visible variable changes, to if anything changes including hidden variables. I don't know how much of a problem it will be in practice though.
Yep, many of these things solve the last "problem" (whcih really it just required understanding how reactivity worked in svelte and the cases when it didnt) and now creates new ones that require understanding how new reactivity works and the new cases where it causes issues, but hey now theres something to focus on in svelte6 so that we can get "super runes" to solve these "problems"
Great video! At first I was really skeptic at runes but now I see the beauty behind them... As you said all of this is still early in development, another video in depth along with core team updates would be awesome :) Cheers from Italy!
I was afraid that my nice little framework would introduce shit that would make it overly-complicated like react. Now, I'm really happy to see how powerful this design is.
The syntax for runes is a little bit rough yet, but I'm really excited for them. What I like about runes is that they unify all reactive operations and allow us to work with reactive code in .svelte and .ts/.js files interchangebly, which was kinda of a pain in the ass to do in svelte 4, specially if you have a custom svelte store with custom unsubscription logic.
Can't see myself using this. The new Syntax that just uses magic functions for everything instead of js keywords makes everything much harder to type using typescript, e.g. props; plus I liked the idea of compile time reactivity. I found it's dependency tracking quite easy to comprehend once you got the basic idea - using runes moves the dependency tracking magic from compiletime to runtime, and I haven't seen any explanation of how it's actually implemented now. The fact that svelte does much of the heavy lifting at compiletime instead of runtime is what set it apart from other frameworks, and it's only possible because svelte effectively made it's own transpiled language for writing js and html in the same file. Now they're moving stuff back from compile time to runtime which just feels opposite to the identity and purpose of svelte.
It compiles signals into the runtime afaik, so it's not really shipping a full runtime or anything. Also syntax is much less magic now and more consistent, not more magic
They aren't magic functions. Runes are compiler macros, or in other words, keywords. And they are very easy to type annotate with TS. The tracking of changes happens through JS Proxy objects (as shown by simply console logging any $state object).
@@SkyyySi fair, proxies is the obvious approach. I still don't know how typing them could be as easy as the old syntax, but I haven't looked into it further at all since the betas came out, so it's probably more usable than it initially looks. I just find it a bit sad that the solution to mediocre static/compile-time analysis is not improving the static analysis but moving parts of it to runtime. A formally complete compile-time Analysis for this is likely impossible in theory with how dynamic js is, but in practice there would have been plenty of room to improve. I still hope we will eventually see some static analysis that uses typescript types for ever greater compilation, optimization and minification.
this may be a dumb question, but i'm curious on if this has been asked before: would it be possible (svelte maintainers) to make everything "$reactive" by default using normal javascript and let the svelte compiler figure out what is or isn't?
@@JoyofCodeDev we'll just get a.i. to do it 😅 . But seriously, I wonder if it would be possible. In a perfect world wouldn't everything be reactive by default? Is there ever a scenario where we wouldn't want something reactive?? 🤔
Your videos are highly explanatory. But please the borders around your thumbnails are really confusing in terms of accessibility. Whenever I watched a video, TH-cam indicates by using a red bottom border, but with your videos, due to the borders around the thumbnail, that is not showing again.
11 หลายเดือนก่อน +1
Thanks a lot for the content, quick question about snippets, are we able to put it on a separate file and them import them? or just to be used inside the page or the component ?
I’m not sure about putting in another file and importing but the power of them isn’t shown better with this example below where you pass them to some other component (likely that’s not even from your own codebase) to use within their markup: // app.svelte import List from "./List.svelte" let newItem = `` let items = $state([`hi`]) function increment() { items = [...items, newItem] } add item
{#snippet template({item, i})} Item {i}: {item} {/snippet} // List.svelte export let items = [] export let template {#each items as item, i}
{#if !template} you didn't pass a template {:else} {@render template({item, i})} {/if}
I don’t think that’s their use case, if you’re going to extract them to a separate file it is better to just make it a component. The way I see it, this feature is kinda like having multiple “components” in the same file the same way React does
@@abno__ see my reply above yours, multiple components in the same file is nice but the more useful case is as I put an example for above… If you have (or import from another library) a component such as a “GridView” or “ListView” you can have it accept a template which is a snippet that allows the consumer of the component to pass in its own template for each item. ie: // app.svelte import List from "./List.svelte" let newItem = `` let items = $state([`hi`]) function increment() { items = [...items, newItem] } add item
{#snippet template({item, i})} Item {i}: {item} {/snippet} // List.svelte export let items = [] export let template {#each items as item, i}
{#if !template} you didn't pass a template {:else} {@render template({item, i})} {/if}
They're meant to be in the same page so you can do what React does and have small sub-components at the top that you re-use. How this replaces slots though (which you use in other files), no idea ??
I work a lot with stores in OOP with Svelte. I just can't understand how runes are making Svelte better. I feel like the actual reactivity is absolutly simple to understand. I often use the $: syntax with functions to actualy make the reactivity depends on just a few variables.
runes use signal, like solid js, vue, and qwik, not react, react useState doesnt use signal. signals can update value without rerender the entire component, so performance improvement, so you get compiler approach and signals approach.
I already love Svelte 5 and moving my private projects to it :) The most problematic for me is migrating slots to snippets. It feels as good idea, but still I do not get how can I replace "let" directive
First impressions of snippets. Well you said it in a way. When creating a component you loose context. Id say that when you create a component you separate concerns which is highly needed.Snippets encourages to make bigger components, which grows a lot of code in . More logic in html is imho not the simple way.
Stupid question, what if I want to have a computed value that's calculated when only one dependecy changes? Before I could just use what you showed (2:30), but if now dependencies are tracked automatically, if any of them updates, it will trigger the computation, which I don't want.
Looking at the docs, it says that dependencies are tracked at runtime, so even if I use a separate function with no parameters, just accessing a reactive value will make it a dependency of the $derived value.
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik. Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component. So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances.
the only Rune im not convinced by is $effect , i really like the clarity of onMount but $effect seems to be a future replacement, im getting useEffect nightmares
You don't have the same problems in Svelte because it's a compiler and you don't have to manage the dependencies. React despite the name is not even reactive but rerenders the component when something changed.
As someone who's done quite a bit of a React, the appeal of Svelte for me was the idea of using compile-time understanding of developer intention to produce highly efficient and targeted updates. I'm probably being unfair and unrealistic to expect Svelte to continue down the path of using static analysis to determine dependencies but that's the magic I was sold on. Runes may have their own magic but doesn't Svelte risk becoming just another framework like the rest?
@@JoyofCodeDev I still really want to try it, once I can have some time away from backend dev, and I'm sure I'll enjoy it. Have you seen the Skeleton UI framework on Svelte? Looks spiffy :)
Keeping consistency and heritage in programming languages is crucial. If a new version of a language greatly differs from its predecessor, it's almost like a new language, rendering millions of lines of old code unusable and necessitating extensive rewriting and updates. This is obviously because code is reusable; not every project starts from scratch. Many companies and independent developers reuse code from previous projects, making minor modifications for reuse. Major modifications due to version differences lead to significant waste, making them feel abandoned. An open-source project has two main groups: the developers and a vast number of users. Developers aim for language optimization, exceptional performance, and innovation. In contrast, users rely on the language for production and maintenance, preferring not to reinvest in learning or training, or to constantly update existing code. Clearly, their goals can be contradictory and inconsistent. A great and excellent language, over decades, must have talented developers and loyal users, not just lasting 1 or 2 years. When users feel abandoned, forced to modify existing code or relearn, they often become frustrated and shift to more stable, trustworthy languages that don't require constant relearning.
If the language stays compatible with its previous iterations these concerns are largely allayed because it's just personal preference at that point, or policy preferences if on a team. If S5, and future iterations, stays true to being a drop-in option then worrying over user abandonment is a solution looking for a problem. Svelte is also very new overall and it should be expected that things would change. Eventually S4 and below may no longer have backwards compatibility aimed at them, but I wouldn't count on that happening soon enough to have an impact. Just my 2 cents of course. EDIT: formatting
as always.. Video is awesome.. But just wondering.. We really Like Multiple slot and named slot in svelte.. is it be replaced ? and I actually didn't founnd snippet comes due to any issue of slot. yeah.. slot are really awesome.
That syntax breaks down as soon as you have any kind of mutable value (like an array or object). It also has very arbitrary borders of where it does and does not work.
Very close to Vue and almost like React. People realize that when you try to do advanced stuff you need complex code. Svelte wasn't battle tested in a scaled project so simple was enough. But now we need this and that. It's gonna get complex.
BULLSHIT... I've built 5 products each with more than 20,000 lines of code, and it works like a charm. The whole "battle tested" thing is so stupid. All the problems come from retarded programmers over-engineering shit just for the sake of it.
I had mentioned in a different comment that this is probably very helpful for seasoned devs working on large projects. The amount of control has increased. But as a learner I really liked the simplicity and limitations of svelte. It's syntax was very unique and simple. Again, maybe too simple for larger projects. But that's what attracted me to it. If someone just wanted a quick and dirty way to put a small website together I would of definitely say go for svelte. Now it really just looks line any other framework for the most part. There is no unique appeal to it. I know that for now it's backwards compatible but that won't last.
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik. Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component. So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances. Vue still creating his compiler to replace the virtual dom, svelte already has. So with svelte you get compiler approach and signals reactivity approach and more easier compared to solid js.
Great explanation in your video. However, I'm getting... maybe not Angular 1 -> 2 vibes, but definitely Vue 2 -> 3 vibes. And that's what led me to switch to Svelte in the first place!
You can pass them as props, but you can also put them directly in the content of the component and they will automatically be passed down to the component.
his example of snippets was not very clear…the snippets are awesome though and bring back passing templates to components that I missed from react: // app.svelte import List from "./List.svelte" let newItem = `` let items = $state([`hi`]) function increment() { items = [...items, newItem] } add item
{#snippet template({item, i})} Item {i}: {item} {/snippet} // List.svelte export let items = [] export let template {#each items as item, i}
{#if !template} you didn't pass a template {:else} {@render template({item, i})} {/if}
Thanks a lot. Do you plan to record a video building an app to demonstrate how this changes should be implemented? As a newbie in webdev I believe it'd be really helpful.
These additions look like they might solve a few potential problems, but part of the appeal of Svelte was always "there's a lot less ugly looking syntax to focus on than React". I'm not saying it's an easy problem to solve, but I wonder if there's a way to add some of these features in a simpler way.
I can tell you are as hesitatnt as me about some of these changes cause you intro all these obviously worse things with "this is just alpha maybe they will make it nicer in the future" or "these arent just changes for changes sake" when some of these are definitely changes for changes sake. I think you are a little too forgiving and drinking the coolaid about oh "export let" was always weird so makes sense to get rid of that...huh? Its pretty natural if you ask me and its part of learning how svelte works, just like now runes will be something you have to learn how they work, neither of them are some "natural" part of javascript already and is obvious. Same with slots being too confusing to understand so lets get rid of them, huh?? Slots are what they are and provide needed functionality. "let:var" also served what it needed to. So I don't understand brushing off all these existing things like "oh we all agreed the whole time these are weird and so makes sense to get rid of them" when those were all the sell points of why Svelte was so good and I'm sure why you started to want to use it. So this attitude of like oh we shouldn't complain and we should just 100% accept everything the wise stewards of svelte dream up because they know better then us plebs just baffles me. Any dissent about this stuff is just met with "oh well obviously you never really used svelte otherwise you'd agree with these changes" by people who just accept everything they're told is supposed to be what they will like. If you don't like something about it, then you should say so in your videos. If you don't thats fine too, but it seems you are afraid to state your opinion here.
I really hope they don't deprecate anything, as I don't find any of these updates useful. I've built 5 complex products without these features, and everything works great!
It's not just improving Svelte but paving the way for the future. The Svelte team is closing a lot of issues because runes solve many problems and edge cases that simply don't exist anymore.
If I recall correctly, they said both syntaxes will be available in Svelte 5, but they hope to deprecate the old syntax in Svelte 6 or 7 and remove it completely in one of the future versions after that.
I always wanted to see slots in React, and now I'm seeing the opposite, I always thought the best thing about slots is the `name` prop where you can add markup between children, React does not have this.
if react and vue are that much great frameworks that svelte is trying to become more like them , then we should directly use react or vue only . svelte had a special place in front end framework because its simple , does 90% of things in simple and efficient way , which other frameworks fails to do . and i am seriously amazed how some core svelte team members are so much impressed and happy by referring negatives of svelte and praising frameworks like react and vue . svelte was great seriously , now it has been ruined .
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik. Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component. So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances. Vue still developing compiler, Svelte already has.
To me it looks a whole lot like Vue. You have ref() which is now $state() and computed() which is $derived(). It seems really strange moving away something that seemed so intuitive to be more like the way Vue has been doing things for years... 🤷♂
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik. Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component. So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances. Vue still creating compiler to change their virtual dom, Svelte already has.
If you look at how React works it's not even close. Any surface-level similarities are just that. A lot of JavaScript frameworks share good ideas that converge at some point and we shouldn't discredit them based on our biases.
@@JoyofCodeDev lol. That's why I liked Solid more. And more than that, last time I tried Svelte, its composability through simple language constructs was none existent when compared to react and its TypeScript support was awful around props and state and everything tied to the library.
Simplicity is lost and Svelte becomes React :-( Ugly $props instead of the beautifully typed (albeit unconventional) let export. I don't see anything worse than passing "...rest" to components. Simple notation for reactivity "$:" will be gone :-( Snippets are a nice thing, but if something needs to be extracted, why not just create a component - like before. --- I understand and know the benefits of this news, but still, it takes Svelte on a different way.
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik. Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component. So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances.
@@doublekamui You're right. The concept is not bad at all, I was looking more at the syntax, where it seems to me that the simplicity of Svelte, which everyone loves so much, is lost a little.
The only UI system that makes sense is an event-based one. The only thing these silly JS frameworks does well is nested routing, HTMX and a touch of Hyperscript replaces 99% of the other fluff and garbage. Svelte is the best of the worst (until Solid start?!)
You are not building a video editor frontend using HTMX are you? Solid sintaks is even more difficult that svelte, with Svelte you get compiler approach and signals approach and more easier compared to Solid JS
They avoid using html tags so that It doesn't interfere with your *normal* code. Using things like is good until it isn't and you are *forced* to name things different like @render... sooo just name everything different.
@@Siroguh I wouldn't say its like image, is an actual built-in html tag. Vue templates use it for the main component template: ``` import { ref } from 'vue' const name = ref('world') Hello {{ name }} ``` In svelte this would be basically doing this: ``` import { onMount } from "svelte"; let name = "world"; let templateEl; let templateSlot; onMount(() => (templateSlot.innerHTML = templateEl.innerHTML)); Hello {name} ``` So idk, it would be interesting if they did something like "enhanced:template" or similar. (inb4 you talk about the syntax, svelte has an official actual "enhanced:img" for example, see: kit.svelte.dev/docs/images#sveltejs-enhanced-img ) ``` import { onMount } from "svelte"; let name = "world"; let hello; Hello {name} {@render hello(name)} ``` This is just an example, might not be the perfect one, but I wish we'd have something like that
The reasoning behind that is because signals are an implementation detail. You can replace signals and you wouldn't notice it because `$state` is just a compiler instruction.
![일상 속 기분 좋음 [Proto disco meme]](http://i.ytimg.com/vi/DwmEIaZ7XGQ/mqdefault.jpg)
You can try the Svelte 5 alpha today with `npm i svelte@next`.
Thats a joke 😂
Is there a release dated scheduled for Svelte 5? I'd like start to study it and use it in a project with SvelteKit, but I have doubts about if it's a good solution. Thanks.
@@r.gisbert It might not be ready until next year.
@@JoyofCodeDev At least, can you tell me if it will be released in the first quarter? Haha. Thanks for getting back to me. I've been looking for some info, but I can't find some clue.
@@r.gisbert There is no release date. 😄
I like everything besides the location of where you write the snippets, on one hand it makes sense since your template language (html) is always at the same place where you expect it but the composable part of react does make the return (render) look cleaner while the snippets still make it look a bit ugly, other then that great stuff from svelte team :)
I get thay all of this features are meant to fix problems and also give more control to developers. But I have to say, a big appeal for me was that svelte was simple. Its limitations are what makes it simple. For seasoned developers and developers using svelte in large websites this is probably very helpful. For me this makes it closer in complexity to other frameworks and less unique. I still like it more, just not as much as before. I still like how it does a lot of things especially around adapting JavaScript libraries to work with svelte, and stores.
i seriously think they have just lost their WHY in copying other frameworks ( like why svelte was formed & why it was different from other Front-end frameworks ) . They have lost the magic and simplicity .
Wtf are you guys talking about. You might be fine with its limitations for your simple use case, but most people want svelte to grow beyond its limitations so it can become their main framework.
Svelte simplicity didn't disappear. You can literally do everything u were just doing until now, almost the same exact way(or the same exact way even), and the only thing those updates are bringing are even more powerful tools.
A framework having lots of tools doesn't make it more complex. It just has some complex tools for advanced users.
The same way, react has 15 hooks, but people are pretty much fine with only useEffect, useState, useRef and useContext 99.99% of the cases.
It bugs me a bit that effect and derived values change based on things that are hidden from the user. With $ syntax, you can tell what the variables are that cause a trigger, but now there are hidden side-effects. Its like we went from dependency array, to if visible variable changes, to if anything changes including hidden variables.
I don't know how much of a problem it will be in practice though.
Yep, many of these things solve the last "problem" (whcih really it just required understanding how reactivity worked in svelte and the cases when it didnt) and now creates new ones that require understanding how new reactivity works and the new cases where it causes issues, but hey now theres something to focus on in svelte6 so that we can get "super runes" to solve these "problems"
It literally has an unique syntax for it. Is it that hard to learn a syntax and associate it with a behavior? Jeez
Great video! At first I was really skeptic at runes but now I see the beauty behind them... As you said all of this is still early in development, another video in depth along with core team updates would be awesome :) Cheers from Italy!
I was afraid that my nice little framework would introduce shit that would make it overly-complicated like react. Now, I'm really happy to see how powerful this design is.
The syntax for runes is a little bit rough yet, but I'm really excited for them. What I like about runes is that they unify all reactive operations and allow us to work with reactive code in .svelte and .ts/.js files interchangebly, which was kinda of a pain in the ass to do in svelte 4, specially if you have a custom svelte store with custom unsubscription logic.
Can't see myself using this. The new Syntax that just uses magic functions for everything instead of js keywords makes everything much harder to type using typescript, e.g. props; plus I liked the idea of compile time reactivity. I found it's dependency tracking quite easy to comprehend once you got the basic idea - using runes moves the dependency tracking magic from compiletime to runtime, and I haven't seen any explanation of how it's actually implemented now. The fact that svelte does much of the heavy lifting at compiletime instead of runtime is what set it apart from other frameworks, and it's only possible because svelte effectively made it's own transpiled language for writing js and html in the same file. Now they're moving stuff back from compile time to runtime which just feels opposite to the identity and purpose of svelte.
It compiles signals into the runtime afaik, so it's not really shipping a full runtime or anything. Also syntax is much less magic now and more consistent, not more magic
They aren't magic functions. Runes are compiler macros, or in other words, keywords. And they are very easy to type annotate with TS.
The tracking of changes happens through JS Proxy objects (as shown by simply console logging any $state object).
@@SkyyySi fair, proxies is the obvious approach. I still don't know how typing them could be as easy as the old syntax, but I haven't looked into it further at all since the betas came out, so it's probably more usable than it initially looks. I just find it a bit sad that the solution to mediocre static/compile-time analysis is not improving the static analysis but moving parts of it to runtime. A formally complete compile-time Analysis for this is likely impossible in theory with how dynamic js is, but in practice there would have been plenty of room to improve. I still hope we will eventually see some static analysis that uses typescript types for ever greater compilation, optimization and minification.
Ohhh cool! Snippets is like making smaller subcomponents in larger components in React. I like that.
Thank you to keeping us updated
this may be a dumb question, but i'm curious on if this has been asked before: would it be possible (svelte maintainers) to make everything "$reactive" by default using normal javascript and let the svelte compiler figure out what is or isn't?
I figure it's hard to optimize.
@@JoyofCodeDev we'll just get a.i. to do it 😅 . But seriously, I wonder if it would be possible. In a perfect world wouldn't everything be reactive by default? Is there ever a scenario where we wouldn't want something reactive?? 🤔
Thanks for the nice overview!
Your videos are highly explanatory.
But please the borders around your thumbnails are really confusing in terms of accessibility. Whenever I watched a video, TH-cam indicates by using a red bottom border, but with your videos, due to the borders around the thumbnail, that is not showing again.
Thanks a lot for the content, quick question about snippets, are we able to put it on a separate file and them import them? or just to be used inside the page or the component ?
I’m not sure about putting in another file and importing but the power of them isn’t shown better with this example below where you pass them to some other component (likely that’s not even from your own codebase) to use within their markup:
// app.svelte
import List from "./List.svelte"
let newItem = ``
let items = $state([`hi`])
function increment() {
items = [...items, newItem]
}
add item
{#snippet template({item, i})}
Item {i}: {item}
{/snippet}
// List.svelte
export let items = []
export let template
{#each items as item, i}
{#if !template}
you didn't pass a template
{:else}
{@render template({item, i})}
{/if}
{/each}
I don’t think that’s their use case, if you’re going to extract them to a separate file it is better to just make it a component. The way I see it, this feature is kinda like having multiple “components” in the same file the same way React does
@@abno__ see my reply above yours, multiple components in the same file is nice but the more useful case is as I put an example for above… If you have (or import from another library) a component such as a “GridView” or “ListView” you can have it accept a template which is a snippet that allows the consumer of the component to pass in its own template for each item. ie:
// app.svelte
import List from "./List.svelte"
let newItem = ``
let items = $state([`hi`])
function increment() {
items = [...items, newItem]
}
add item
{#snippet template({item, i})}
Item {i}: {item}
{/snippet}
// List.svelte
export let items = []
export let template
{#each items as item, i}
{#if !template}
you didn't pass a template
{:else}
{@render template({item, i})}
{/if}
{/each}
They're meant to be in the same page so you can do what React does and have small sub-components at the top that you re-use. How this replaces slots though (which you use in other files), no idea ??
Appreciated -- Waiting for more on Svelte!
I work a lot with stores in OOP with Svelte. I just can't understand how runes are making Svelte better. I feel like the actual reactivity is absolutly simple to understand. I often use the $: syntax with functions to actualy make the reactivity depends on just a few variables.
Current Svelte is so good. I REALLY hope they don't fuck it up by removing $: and other features.
@@ba8ei mean... They absolutely are going to remove $:... That's what the runes are for.
runes use signal, like solid js, vue, and qwik, not react, react useState doesnt use signal.
signals can update value without rerender the entire component, so performance improvement, so you get compiler approach and signals approach.
I finally changed my mind… Svelte 5 is just awesome ! Proxied state are amazing, and its event better to create reactivity in OOP.
@@doublekamui why use svelte over qwik other than for developer experience? SSR and lazy loading sure seem to solve a lot of problems. thanks
Please make detailed video on snippets
I already love Svelte 5 and moving my private projects to it :) The most problematic for me is migrating slots to snippets. It feels as good idea, but still I do not get how can I replace "let" directive
Matias a true Ambassador
thanks for the update!
First impressions of snippets. Well you said it in a way. When creating a component you loose context. Id say that when you create a component you separate concerns which is highly needed.Snippets encourages to make bigger components, which grows a lot of code in .
More logic in html is imho not the simple way.
Stupid question, what if I want to have a computed value that's calculated when only one dependecy changes?
Before I could just use what you showed (2:30), but if now dependencies are tracked automatically, if any of them updates, it will trigger the computation, which I don't want.
You can use the $derived rune.
Looking at the docs, it says that dependencies are tracked at runtime, so even if I use a separate function with no parameters, just accessing a reactive value will make it a dependency of the $derived value.
Awesome video as always!
Very excited about runes and figuring out improved pattern but I will wait until it's stable.
Is it becoming like react or am I wrong?
I fucking hope not. React is GARBAGE.
A bit more, but more like Solid, if you're looking for a closer match.
It still avoids React's inefficiencies.
@@hebestreitfan6973 Never tried Solid, I will
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik.
Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component.
So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances.
I'd like a rune for array state managment that reacts when I use array methods like push, filter and pop.
Definitely
So excited for what's coming!!!
Thank you , clear and concise
the only Rune im not convinced by is $effect , i really like the clarity of onMount but $effect seems to be a future replacement, im getting useEffect nightmares
You don't have the same problems in Svelte because it's a compiler and you don't have to manage the dependencies. React despite the name is not even reactive but rerenders the component when something changed.
Absolutely agree. Fuck anything React.
As someone who's done quite a bit of a React, the appeal of Svelte for me was the idea of using compile-time understanding of developer intention to produce highly efficient and targeted updates. I'm probably being unfair and unrealistic to expect Svelte to continue down the path of using static analysis to determine dependencies but that's the magic I was sold on.
Runes may have their own magic but doesn't Svelte risk becoming just another framework like the rest?
Reactivity is one part of the story.
@@JoyofCodeDev I still really want to try it, once I can have some time away from backend dev, and I'm sure I'll enjoy it. Have you seen the Skeleton UI framework on Svelte? Looks spiffy :)
Keeping consistency and heritage in programming languages is crucial. If a new version of a language greatly differs from its predecessor, it's almost like a new language, rendering millions of lines of old code unusable and necessitating extensive rewriting and updates. This is obviously because code is reusable; not every project starts from scratch. Many companies and independent developers reuse code from previous projects, making minor modifications for reuse. Major modifications due to version differences lead to significant waste, making them feel abandoned.
An open-source project has two main groups: the developers and a vast number of users. Developers aim for language optimization, exceptional performance, and innovation. In contrast, users rely on the language for production and maintenance, preferring not to reinvest in learning or training, or to constantly update existing code. Clearly, their goals can be contradictory and inconsistent.
A great and excellent language, over decades, must have talented developers and loyal users, not just lasting 1 or 2 years. When users feel abandoned, forced to modify existing code or relearn, they often become frustrated and shift to more stable, trustworthy languages that don't require constant relearning.
If the language stays compatible with its previous iterations these concerns are largely allayed because it's just personal preference at that point, or policy preferences if on a team. If S5, and future iterations, stays true to being a drop-in option then worrying over user abandonment is a solution looking for a problem.
Svelte is also very new overall and it should be expected that things would change. Eventually S4 and below may no longer have backwards compatibility aimed at them, but I wouldn't count on that happening soon enough to have an impact.
Just my 2 cents of course.
EDIT: formatting
And because the Svelte developers know that, they allow you to gradually adopt these changes, just leaving your existing code untouched.
Bro I don't believe this, I just started on Svelte yesterday. Haven't ever done anything frontend, besides basic html-css-js forms.
as always.. Video is awesome.. But just wondering.. We really Like Multiple slot and named slot in svelte.. is it be replaced ? and I actually didn't founnd snippet comes due to any issue of slot.
yeah.. slot are really awesome.
I'm not sure to be honest.
Nice video!
Does anyone have the link to the video where he talks about his OS and vs code setup for faster development? I cant find it anywhere
I never made such a video! 😄
Dumbing down the last bit, what is effectively inline components will save me soo many files, no longer SidebarListItem files
I've kicked all the tires and it's magical! Zero issues thus far
I hate rune's syntax 😢, I want rune's fine grained reactivity, but with the default "let x = 0" syntax
Finally found someone who agrees. I think we might be the silent majority...
They tried that and it didn't work.
Agree !!
As the creator said it's to track reactive variables with pure js syntax u need A wrapper function around that
That syntax breaks down as soon as you have any kind of mutable value (like an array or object). It also has very arbitrary borders of where it does and does not work.
This is great!!!
Im excited for these changes, i have been having issues in my application that i know will immediately be fixed by runes.
Very close to Vue and almost like React. People realize that when you try to do advanced stuff you need complex code. Svelte wasn't battle tested in a scaled project so simple was enough. But now we need this and that. It's gonna get complex.
BULLSHIT... I've built 5 products each with more than 20,000 lines of code, and it works like a charm. The whole "battle tested" thing is so stupid. All the problems come from retarded programmers over-engineering shit just for the sake of it.
I had mentioned in a different comment that this is probably very helpful for seasoned devs working on large projects. The amount of control has increased. But as a learner I really liked the simplicity and limitations of svelte. It's syntax was very unique and simple. Again, maybe too simple for larger projects. But that's what attracted me to it. If someone just wanted a quick and dirty way to put a small website together I would of definitely say go for svelte. Now it really just looks line any other framework for the most part. There is no unique appeal to it. I know that for now it's backwards compatible but that won't last.
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik.
Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component.
So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances.
Vue still creating his compiler to replace the virtual dom, svelte already has. So with svelte you get compiler approach and signals reactivity approach and more easier compared to solid js.
what font are you using? i looked into the 'uses' of your site but didn't find
I'm trying out Monaspace Neon.
Great explanation in your video. However, I'm getting... maybe not Angular 1 -> 2 vibes, but definitely Vue 2 -> 3 vibes. And that's what led me to switch to Svelte in the first place!
Can we forward the snippets to other components? 🤔
Or such cases, we then need to separate it into a new svelte file?
If I remember correctly, you can pass them as props to an other component. Though I'm not sure at all
You can pass them as props, but you can also put them directly in the content of the component and they will automatically be passed down to the component.
his example of snippets was not very clear…the snippets are awesome though and bring back passing templates to components that I missed from react:
// app.svelte
import List from "./List.svelte"
let newItem = ``
let items = $state([`hi`])
function increment() {
items = [...items, newItem]
}
add item
{#snippet template({item, i})}
Item {i}: {item}
{/snippet}
// List.svelte
export let items = []
export let template
{#each items as item, i}
{#if !template}
you didn't pass a template
{:else}
{@render template({item, i})}
{/if}
{/each}
Thanks a lot. Do you plan to record a video building an app to demonstrate how this changes should be implemented? As a newbie in webdev I believe it'd be really helpful.
Yeah! 😄
whats the name of the font your using?
I'm trying out Monaspace Neon.
how to change "on:click|self" ?
"Fine-grained reactivity as term people through around and don't know what it actually means." Now that's funny, because it's so true.
Amazing video man, I'm curious what theme is this? Looks clean
It's in the description.
seems like at the end Svelte is becoming like React or Vue
These additions look like they might solve a few potential problems, but part of the appeal of Svelte was always "there's a lot less ugly looking syntax to focus on than React". I'm not saying it's an easy problem to solve, but I wonder if there's a way to add some of these features in a simpler way.
I have an upcoming Svelte update video! 😄
I can tell you are as hesitatnt as me about some of these changes cause you intro all these obviously worse things with "this is just alpha maybe they will make it nicer in the future" or "these arent just changes for changes sake" when some of these are definitely changes for changes sake.
I think you are a little too forgiving and drinking the coolaid about oh "export let" was always weird so makes sense to get rid of that...huh? Its pretty natural if you ask me and its part of learning how svelte works, just like now runes will be something you have to learn how they work, neither of them are some "natural" part of javascript already and is obvious.
Same with slots being too confusing to understand so lets get rid of them, huh?? Slots are what they are and provide needed functionality. "let:var" also served what it needed to. So I don't understand brushing off all these existing things like "oh we all agreed the whole time these are weird and so makes sense to get rid of them" when those were all the sell points of why Svelte was so good and I'm sure why you started to want to use it.
So this attitude of like oh we shouldn't complain and we should just 100% accept everything the wise stewards of svelte dream up because they know better then us plebs just baffles me. Any dissent about this stuff is just met with "oh well obviously you never really used svelte otherwise you'd agree with these changes" by people who just accept everything they're told is supposed to be what they will like. If you don't like something about it, then you should say so in your videos. If you don't thats fine too, but it seems you are afraid to state your opinion here.
What is the name of Sscreen recorder software
I use OBS.
Thank you Very Much@@JoyofCodeDev
I really hope they don't deprecate anything, as I don't find any of these updates useful. I've built 5 complex products without these features, and everything works great!
It's not just improving Svelte but paving the way for the future. The Svelte team is closing a lot of issues because runes solve many problems and edge cases that simply don't exist anymore.
If I recall correctly, they said both syntaxes will be available in Svelte 5, but they hope to deprecate the old syntax in Svelte 6 or 7 and remove it completely in one of the future versions after that.
@@BabyPigmanRoboti think that is for the best. if people start hating new syntax, or not use it, they can just take a different approach.
Thanks
So the problem with the original reactivity is poorly written code. Yeah, why not introduce a new syntax just for that
So you never changed as a person?
@@JoyofCodeDev nope, I always been this bad of a guy 🙂
I always wanted to see slots in React, and now I'm seeing the opposite, I always thought the best thing about slots is the `name` prop where you can add markup between children, React does not have this.
snippets! finally!
Said no one ever
if react and vue are that much great frameworks that svelte is trying to become more like them , then we should directly use react or vue only .
svelte had a special place in front end framework because its simple , does 90% of things in simple and efficient way , which other frameworks fails to do .
and i am seriously amazed how some core svelte team members are so much impressed and happy by referring negatives of svelte and praising frameworks like react and vue .
svelte was great seriously , now it has been ruined .
They're nothing alike.
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik.
Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component.
So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances.
Vue still developing compiler, Svelte already has.
To me it looks a whole lot like Vue. You have ref() which is now $state() and computed() which is $derived(). It seems really strange moving away something that seemed so intuitive to be more like the way Vue has been doing things for years... 🤷♂
The reason to use Svelte over Vue or even React gets smaller and smaller
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik.
Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component.
So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances.
Vue still creating compiler to change their virtual dom, Svelte already has.
@@doublekamui omg stop commenting the same thing bot
I very excited about that snippet feature.....
Isn’t this now getting more and more like react?
If you look at how React works it's not even close. Any surface-level similarities are just that. A lot of JavaScript frameworks share good ideas that converge at some point and we shouldn't discredit them based on our biases.
This is beautiful
So they finally realised that Solid and Knockout were right.
That's what they wrote in the blog post: svelte.dev/blog/runes.
@@JoyofCodeDev lol. That's why I liked Solid more. And more than that, last time I tried Svelte, its composability through simple language constructs was none existent when compared to react and its TypeScript support was awful around props and state and everything tied to the library.
Svelte and Vue are 🔥
Simplicity is lost and Svelte becomes React :-(
Ugly $props instead of the beautifully typed (albeit unconventional) let export. I don't see anything worse than passing "...rest" to components.
Simple notation for reactivity "$:" will be gone :-(
Snippets are a nice thing, but if something needs to be extracted, why not just create a component - like before.
---
I understand and know the benefits of this news, but still, it takes Svelte on a different way.
That is different from React useState, React useState doesn't use signals. The signal concept was popularized by SolidJS, then adopted by various frameworks, including Vue, Svelte, Qwik.
Signals can prevent the entire re-rendering of components, offering fantastic performance benefits by updating values without re-rendering the entire component.
So, it's worth considering this advantage in performance. So, delve into the concepts first, not just concluding similarities based on external appearances.
@@doublekamui You're right. The concept is not bad at all, I was looking more at the syntax, where it seems to me that the simplicity of Svelte, which everyone loves so much, is lost a little.
Cool)
The only UI system that makes sense is an event-based one. The only thing these silly JS frameworks does well is nested routing, HTMX and a touch of Hyperscript replaces 99% of the other fluff and garbage. Svelte is the best of the worst (until Solid start?!)
You are not building a video editor frontend using HTMX are you?
Solid sintaks is even more difficult that svelte, with Svelte you get compiler approach and signals approach and more easier compared to Solid JS
Version 5 is getting better and better and better
React 19: we introducing compile-time reactivity
You jest but React is working on a compiler.
@@JoyofCodeDev jsx is just a different syntax basically
Svelte is runed... 😔
As long as they don't remove current functionalities, they can add all the bullshit they want.
I wish they’d use the html tag instead of more custom markup
They avoid using html tags so that It doesn't interfere with your *normal* code.
Using things like is good until it isn't and you are *forced* to name things different like @render... sooo just name everything different.
@@Siroguh I wouldn't say its like image, is an actual built-in html tag.
Vue templates use it for the main component template:
```
import { ref } from 'vue'
const name = ref('world')
Hello {{ name }}
```
In svelte this would be basically doing this:
```
import { onMount } from "svelte";
let name = "world";
let templateEl;
let templateSlot;
onMount(() => (templateSlot.innerHTML = templateEl.innerHTML));
Hello {name}
```
So idk, it would be interesting if they did something like "enhanced:template" or similar.
(inb4 you talk about the syntax, svelte has an official actual "enhanced:img" for example, see: kit.svelte.dev/docs/images#sveltejs-enhanced-img )
```
import { onMount } from "svelte";
let name = "world";
let hello;
Hello {name}
{@render hello(name)}
```
This is just an example, might not be the perfect one, but I wish we'd have something like that
It's becoming more like react
I fucking hope not...
Personally, i prefer a next nuxt svelte react preact vue node bun deno fresh prisma astro flutter javascript typescript jsx tsx ts js php html htmx stack
I’m glad it’s so easy for beginners, especially with everything updating and changing all the time
I also use that stack ☺
At this point svelte got the best out of vue while being more succint
Amazing changes, but I really hope they start calling it Signals like everyone else
The reasoning behind that is because signals are an implementation detail. You can replace signals and you wouldn't notice it because `$state` is just a compiler instruction.
runes sounds nicer than signal. 🙂
Svolid