as a beginner I learned a little bit of react, vue, and svelte but eventually picked svelte because it’s reactive system feels the most natural to me (and plus it’s compiled). so I’m glad I can keep using the easy basic stuff for 90% of my layouts and use runes for when I need a bit more control
For those not a fan of this: `$state` is just a compiler hint! It doesn't actually affect the value of the variable _at all._ The variable still literally equals its value. If you do `let count = $state(0)`, then `count === 0` will be true. It's the `count` variable itself that becomes reactive, not its value. If you assign its value to a different variable, its reactivity isn't copied. *I'm still not a fan of the `$state(...)` syntax because it doesn't make that clear at all.* Due to this common confusion, I think putting runes on the right-hand side of the equal sign was the wrong move, since it has nothing to do with what the variable is being set to. This would be much clearer and simpler imo: let $count = 0; Then it clearly communicates it's the variable that's reactive, not its value. And as a bonus, then dollar signs would explicitly indicate everywhere reactivity is present in your app. (But then you'd also have to think of better syntax for `$derived` which has the same problem.)
I see $state is not valuable enough right now but may be in future when they get rid of reactivity for right hand of equal sign only $state will be reactive which will improve performance as other lets will not be considered for reactivity Another thing though being to write $count will be much complicated with these reserved keywords as I think they will introduce more runes to the system
@@AShaheen92 `$derived` would need a different syntax too (which I think it should anyway). And `$effect` could just be named something else without the dollar. Either of those would apply to any future runes. The dollar's nice for clarity that it's a compiler hint, but I'd argue clarity that variables are reactive is more important. Or at least move the syntax somewhere else on the left-hand side. Like why not more labels? Labels could just as well be extended to work universally (both inside and outside `.svelte` files).
Cool name, Runes, but at first blush -- no, I haven't used it yet -- it looks like a layer of React-ish complication added on top of a *beautifully* simple and performant system. (Perhaps because it doesn't solve any problems I've encountered.)
I'm really looking forward to using those runes! I really liked the $props rune it seems so useful to create reusable and flexible components! Way better than the current prop system imo
Signal is 1st class citizen in SolidJs. Vue has a similar Signal implementation under the hood. Angular has been using RxJS /Observable for a long time for asynchronous reactivity, and recently added Signal for synchronous reactivity. They also interops, so best of both worlds. Now Svelte joins the party. It seems all frameworks are converging on the trend of fine-grain reactivity.
@@MrEnsiferum77 not all developers hate RxJS, it has its place in the ecosystem. I had to learn it for an Angular project, and ended up loving it. It unlocks a really declarative/reactive way of writing code, i.e. you "see" the dependencies of your state, its lifecycle, its side-effects, etc right at the point you "declare" that state. You no longer need to jump thru a bunch of function references to see what are the initial value of your state, what states your state depend on, what states depend on your state, its side effects ... Of course, due to its async nature, RxJS is overburdened with async-centric operators that are rarely used. I would say you'll need only 10-15% of those rxjs operators to be productive. Signal, on the other hand, is "synchronous" reactivity, with only 2-3 operators like $derived (aka computed signal), $effect, and probably $mutate. It will be much easier to use. The benefit that most people seem to be missing is that Signal should make Svelte more efficient, by using the very $effect of a Signal to surgically target the DOM node that needs to be updated, whenever that source Signal mutates. Svelte compiler will no longer need to rely on "=" overloading and "$:" blocks for compiled reactivity, addressing some edge case bugs
@@JoyofCodeDev What's the difference, observer pattern just under the hood, and miminal primitives to accomodate observable state as signals, runes or u put name u like. give me all the money in the world and I look like building something new...
Why not make the variable identifier as the reactive state declaration? Was it discussed/proposed? let $count = 0 let $derivedDouble = $count * 2 Not only does it make the code shorter, but it also makes it clear what variable is a signal or derived later in code.
Having 2 ways to write svelte apps will be a problem in short term. If this is the new way they want to go with adding more verbs, then we should get rid of old $ reactivity thing. Also I did not get the reason to have untrack for $effect or nested $effect's.
Looks like these are coming in Svelte 5, so the old system will probably be deprecated but still work. Maybe in Svelte 6+ the old reactivity system will be removed
The one thing i really didn't get, that you didn't talk about and neither did Rich Harris really, is what is the point in nesting effects? He said that it helped you to not clutter your top level, bit i suspect there is more to it than that.
Rich's video had an example of where you'd want that: when you use the outer $effect as an onMount, create a variable within it (his example had "const ctx = canvas.getContext('2d')"), and want another reactive $effect to use it. Without nesting the $effects you would need to move that variable into the parent scope of the first $effect *and* make it mutable and nullable.
Love your videos. Always covers a topic really well in a nice tempo and a happy friendly optimistic voice. 😊 This one is also good. Examples are working but imho could be much simpler to easily explain the main points of runes 🎉
Great video, I was a bit worried about the signals overhead cost in SSR, Svelte team took that into consideration and signals have no cost on server side as they don't need to be reactive
If it's not like React, it shouldn't use the same term as React. This whole thing is a big miss by the Svelte maintainers. I've never run into any of the issues brought up, so for me all I get out of this is having to write a ton more boilerplate code that makes my Svelte components look more like React components.
You have no idea how much advanced svelte stuff people are writing, if you don't have a need for it, others will. Simplifying state in a simple component without needing to reach for stores or context is a win.
@@senseicodes notice I said nothing about other people running into those issues. My entire comment is about how it makes things less simple in components that are not extremely complicated.
My mind is already racing with how much ugliness in my projects I'm going to be able to clean up. I have so many winding reactive statements and one-shot stores and `onMount`s.
i have tested the snippet on 8:00 and this break the app: Uncaught Error: ERR_SVELTE_TOO_MANY_UPDATES: Maximum update depth exceeded. This can happen when a reactive block or effect repeatedly sets a new value. Svelte limits the number of nested updates to prevent infinite loops.
would be good to know at least a release timeframe… as in, should i start a new app that would really benefit from this in v4 and refactor later or just wait?
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.
Why can't they just pack this into their compiler or make it so we don't have to repeat ourselves so much, it's so freaking verbose, annoying, confusing: `get count() { return count }, set count(value) {count = value}, get double() { return double}`
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.
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, and React (useSignal from the Preact package). 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.
@@JoyofCodeDev I’m just gonna highjack this to ask you if Svelte is ready for large production projects yet? I’ve got a codebase I have to move off Nuxt2 and I’ve been eyeballing Svelte instead but don’t want to be in the same place 3 years from now
One thing bothers me with the effect rune: if I were to use two variables, but only want to run the effect when one updates-but not the other-how can I do that? In react I would just not include it in the dependency array, but here?
Also your example has no real world use-case, if your effects uses variables it should run when any of them changes, your example is not an example for the real world, the is no situation where you want to run the effect is just one changes, you can have multiple effects for that.
Is there a release time estimate yet? Its still confusing to me but after i watch 20 videos about it and get my hands dirty with it over the next month ill have the 🤯 moment as always occurs
Well i feel a guy from reactjs will make svelte more complicated. Now svelte not simple, harder to use and learn than reactjs, maybe we should learn reactjs
This looks great, but this is basically what Vue 3 has had for a long time if I'm not mistaken. Just maybe without the effect rune. Need to double check if there's some equivalent to that.
@@alisherdotdev Well, in the video, you see Matt defining an $effect within an $effect. I assume that this means that you can have some effects that are dependent on other effects. I'm not sure what the use case for this would be, but since we're just trying to figure out what the equivalent to $effect would be in Vue, I was just trying to double check how similar watch is to $effect. Just checked right now btw, and yeah, you could also do nested watches in Vue... Definitely something to avoid in my opinion, but anyway, seems like Vue 3 had all this stuff all along, with the same precision, etc.
I dig all these improvements. tried it and looks like I am writing react, which make me vomit all night. what next, JSX coming in 6? great vid as always btw
Back in the day I looked at all those frameworks and went with Vue... seeing this here made me really happy that I apparently made the right decision back then. This reactivity system does really not look good to me.
I appreciate that there's now a consistent way to handle state, whether it's in a Svelte component or a separate file. That's a big win. However, if I'm understanding this correctly, for complex applications that have several values per $state, this is going to add a ton of boilerplate with lots of getters and setters.
Thanks, I updated my app to Svelte 5 but as soon as update a store to utilize runes the rest of the files also need to be updated you can’t mixed both.
Are there any drawbacks using the new runes compared to the let statements? Performance between these two? Are there times you would want to use the let statements instead of the new runes?
Yes. Much better. React re-renders everything like crazy by default. You need to verbose your code in React by implementing "memos" workarounds if you want to run a list with 200 component instances with sort, filter and transitions. React just fails to keep things running smoothly by default. It's the worst architecture among the biggest frameworks. However, the most used.
Don't listen to me. Just implement a simple test in React: Write a styled card component, put some transitions and try to sort and filter a list of 200 instances. "Oh, you need to use memo!". Yes! native workaround for bad architecture.
@@leopb21 I see you know nothing about how svelte lists internally work and that they are inefficient, if you would have listened to Rich Harris Runes presentation you would have heard exactly that and that Rich himself admits this. And that is exactly the problem with beginner mentality just like teenagers in their worst years they think they already know everything and no one should try explaining to them why things are how they are. I'm not even a "Only React" guy, I use many techs besides that like Solid or Vue but your dumb comment made me just sad that people like you with 0 understanding of how Frameworks work under the hood want to prove themselves here in the youtube comments.
I forgot to mention these changes aren't out yet and even when they release them it's opt-in and your Svelte components are going to work as usual.
as a beginner I learned a little bit of react, vue, and svelte but eventually picked svelte because it’s reactive system feels the most natural to me (and plus it’s compiled). so I’m glad I can keep using the easy basic stuff for 90% of my layouts and use runes for when I need a bit more control
not forever. they’ll deprecate and remove eventually :P
For those not a fan of this: `$state` is just a compiler hint! It doesn't actually affect the value of the variable _at all._ The variable still literally equals its value. If you do `let count = $state(0)`, then `count === 0` will be true. It's the `count` variable itself that becomes reactive, not its value. If you assign its value to a different variable, its reactivity isn't copied.
*I'm still not a fan of the `$state(...)` syntax because it doesn't make that clear at all.* Due to this common confusion, I think putting runes on the right-hand side of the equal sign was the wrong move, since it has nothing to do with what the variable is being set to. This would be much clearer and simpler imo:
let $count = 0;
Then it clearly communicates it's the variable that's reactive, not its value. And as a bonus, then dollar signs would explicitly indicate everywhere reactivity is present in your app. (But then you'd also have to think of better syntax for `$derived` which has the same problem.)
That's right because `$state` is not a function but a keyword.
I see $state is not valuable enough right now but may be in future when they get rid of reactivity for right hand of equal sign only $state will be reactive which will improve performance as other lets will not be considered for reactivity
Another thing though being to write $count will be much complicated with these reserved keywords as I think they will introduce more runes to the system
@@AShaheen92 `$derived` would need a different syntax too (which I think it should anyway). And `$effect` could just be named something else without the dollar. Either of those would apply to any future runes. The dollar's nice for clarity that it's a compiler hint, but I'd argue clarity that variables are reactive is more important.
Or at least move the syntax somewhere else on the left-hand side. Like why not more labels? Labels could just as well be extended to work universally (both inside and outside `.svelte` files).
@@GrantGryczanyou have good point it is matter of time to understand what is going on
This looks..... not that good
I worry that now there's a whole team working on svelte it'll get over complicated like react. Rich basically got svelte right on his own
Cool name, Runes, but at first blush -- no, I haven't used it yet -- it looks like a layer of React-ish complication added on top of a *beautifully* simple and performant system. (Perhaps because it doesn't solve any problems I've encountered.)
Reactivity in Svelte 6: import {$useState} From Svelte; const [count, setCount] = $useState(0);
😂
so true
Haha😂
Except all this gets compiled away so ;)
This is the way.
I'm really looking forward to using those runes! I really liked the $props rune it seems so useful to create reusable and flexible components! Way better than the current prop system imo
Signal is 1st class citizen in SolidJs. Vue has a similar Signal implementation under the hood.
Angular has been using RxJS /Observable for a long time for asynchronous reactivity, and recently added Signal for synchronous reactivity. They also interops, so best of both worlds.
Now Svelte joins the party. It seems all frameworks are converging on the trend of fine-grain reactivity.
This is the way.
But developers hate rxjs, how now they started loving it... or is just rxjs under the hood so now looks cool...
@@MrEnsiferum77 not all developers hate RxJS, it has its place in the ecosystem.
I had to learn it for an Angular project, and ended up loving it. It unlocks a really declarative/reactive way of writing code, i.e. you "see" the dependencies of your state, its lifecycle, its side-effects, etc right at the point you "declare" that state.
You no longer need to jump thru a bunch of function references to see what are the initial value of your state, what states your state depend on, what states depend on your state, its side effects ...
Of course, due to its async nature, RxJS is overburdened with async-centric operators that are rarely used. I would say you'll need only 10-15% of those rxjs operators to be productive.
Signal, on the other hand, is "synchronous" reactivity, with only 2-3 operators like $derived (aka computed signal), $effect, and probably $mutate. It will be much easier to use.
The benefit that most people seem to be missing is that Signal should make Svelte more efficient, by using the very $effect of a Signal to surgically target the DOM node that needs to be updated, whenever that source Signal mutates.
Svelte compiler will no longer need to rely on "=" overloading and "$:" blocks for compiled reactivity, addressing some edge case bugs
@@MrEnsiferum77 Signals are not the same as RxJS observables.
@@JoyofCodeDev What's the difference, observer pattern just under the hood, and miminal primitives to accomodate observable state as signals, runes or u put name u like. give me all the money in the world and I look like building something new...
Fantastic run-through! Super clear and a perfect balance between existing and new features.
Why not make the variable identifier as the reactive state declaration? Was it discussed/proposed?
let $count = 0
let $derivedDouble = $count * 2
Not only does it make the code shorter, but it also makes it clear what variable is a signal or derived later in code.
Having 2 ways to write svelte apps will be a problem in short term. If this is the new way they want to go with adding more verbs, then we should get rid of old $ reactivity thing. Also I did not get the reason to have untrack for $effect or nested $effect's.
that's normal for every library, not a single lib in the world can have one way forever, the only way of doing this is to not change anything.
Looks like these are coming in Svelte 5, so the old system will probably be deprecated but still work. Maybe in Svelte 6+ the old reactivity system will be removed
It's going to be removed in the future.
@@willsterjohnson they said in the FAQ that there will be warnings in 6 and removal in 7.
I agree. If they think this is the way to go, just make everybody convert to it now.
i dont get it, what's wrong with the current store system? why add unnecessary magical function
I don't care about the runes, I just care about how much faster my app is going to become now.
found the PM
Blazingly fast.
The one thing i really didn't get, that you didn't talk about and neither did Rich Harris really, is what is the point in nesting effects? He said that it helped you to not clutter your top level, bit i suspect there is more to it than that.
Rich's video had an example of where you'd want that: when you use the outer $effect as an onMount, create a variable within it (his example had "const ctx = canvas.getContext('2d')"), and want another reactive $effect to use it. Without nesting the $effects you would need to move that variable into the parent scope of the first $effect *and* make it mutable and nullable.
If i hear "how beautiful is this friends" one more time, I swear.
How beautiful is that?
Love your videos. Always covers a topic really well in a nice tempo and a happy friendly optimistic voice. 😊
This one is also good. Examples are working but imho could be much simpler to easily explain the main points of runes 🎉
Thank you! 😄
What a 5 to be alive
Thank you for creating this video! Your video gives me awsome infos!
BTW, 5:24 , I think the `const count` at 11 line shold be `counter` maybe
So svelte is closing in on classic java 1.6 or something with all these setters and getters-
That's why it's named JavaScript. 😂
Great video, I was a bit worried about the signals overhead cost in SSR,
Svelte team took that into consideration and signals have no cost on server side as they don't need to be reactive
If it's not like React, it shouldn't use the same term as React.
This whole thing is a big miss by the Svelte maintainers. I've never run into any of the issues brought up, so for me all I get out of this is having to write a ton more boilerplate code that makes my Svelte components look more like React components.
L take.
I agree. This doesn't look very intuitive.
It's good to have a universal term, that way developers don't have to memorize lots of different terms.
You have no idea how much advanced svelte stuff people are writing, if you don't have a need for it, others will. Simplifying state in a simple component without needing to reach for stores or context is a win.
@@senseicodes notice I said nothing about other people running into those issues. My entire comment is about how it makes things less simple in components that are not extremely complicated.
My mind is already racing with how much ugliness in my projects I'm going to be able to clean up. I have so many winding reactive statements and one-shot stores and `onMount`s.
I will now be able to clean up my ugly a** useEffect implementation
Meh, modern web is a massive unusable bloat, and this wont make it better
True.
This runes my day
Completely off topic:
I LOVE your video thumbnails.
Thank you! 😄
how beautiful is this friends?
It's not.
It's shit
That was a lot to take in, but I can already see how it can solve a few problems I have had for some time now.
I tried to keep it simple! 😄
quite hard to get my head round but seems legit
I still don't get effect. It also seems somewhat similar to derived except that it's for blocks of code?
It's roughly equivalent to `$:` and is used to run code whenever specific values change, or when a component is mounted to the DOM.
Very good video. Great explanation, thanks!
Thank you! 😄
You got this out faaaast!
It took me a couple of days! 😄
i have tested the snippet on 8:00 and this break the app:
Uncaught Error: ERR_SVELTE_TOO_MANY_UPDATES: Maximum update depth exceeded. This can happen when a reactive block or effect repeatedly sets a new value. Svelte limits the number of nested updates to prevent infinite loops.
In future will they depreacate stores and $: statement ? Feels that way
Yeah! 😄
by using runes, stores become optional so yeah those will be deprecated for sure.
I don't think stores will be deprecated, they are still great for storing data components can subscribe to and render.
Explained better than the docs. no cap!
great explain. loved it
it's like a global function, and we don't need to import, so it's provided by the compiler, am i right?
Yeah! 😄
would be good to know at least a release timeframe… as in, should i start a new app that would really benefit from this in v4 and refactor later or just wait?
There is none yet.
@@JoyofCodeDev 😒
Start now, refactor later.
@@senseicodes found it in the FAQ - it’s “later this year…hopefully” and a pre-release for the brave even sooner.
Awesome video!
What about the $props rune? 🤔
The `$props` rune replaces `export let` but I only wanted to talk about reactivity.
Great video!
Thank you! 😄
Finally...Svelte rocks
no - svelte is rune'd
Just realising if I haven’t yet written wrapper functions for writeable stores I’m very much a Svelte toddler 😅
I’m sold!
It's more advanced. 😄
niceeee 🔥
yes but how is it different from the 10-years-old react?
It doesn't have useFootGun()
uses signals instead of virtual DOM. if you want a comparison, it's closer to solid than react
It's named Svelte.
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.
You made this quickly
Insider knowledge. 🤫
Second! Yess sir
Why can't they just pack this into their compiler or make it so we don't have to repeat ourselves so much, it's so freaking verbose, annoying, confusing:
`get count() { return count },
set count(value) {count = value},
get double() { return double}`
They can make it simpler! 😄
Svelte 4 is awesome, svelte 5 is just becoming react 😢😢
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.
its looks like bit complicated. now its simpler
I'm glad everyone's collectively agreeing that signals are the way to go for reactivity
I do not agree.
@@brad1785 By "everyone", I mean the major frameworks. Angular is moving to signals as well.
i really dislike $ signs, it looks awful
Do you also hate `$:`?
@@JoyofCodeDev yes, but now there is more of it! lol
maybe we can use emoji for the magical looking runes
First!
Svelte ruined.. 🤦
It should have been called useState and useEffect instead of $state and $effect
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, and React (useSignal from the Preact package).
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.
This was just announced!! How did you make such a good video so fast? 😍
Great job on separating what is standard JS is what is new to Svelte
he had a beta access or something probably and was already working on a video
I'm a Svelte ambassador. 😎
@@JoyofCodeDevFlex 💪😅
@@nyashachiroro2531 💪
@@JoyofCodeDev I’m just gonna highjack this to ask you if Svelte is ready for large production projects yet? I’ve got a codebase I have to move off Nuxt2 and I’ve been eyeballing Svelte instead but don’t want to be in the same place 3 years from now
This doesn't look like we're getting more simplicity 🤔
now Solidjs looks good
why $derived and all that 😂
One thing bothers me with the effect rune: if I were to use two variables, but only want to run the effect when one updates-but not the other-how can I do that? In react I would just not include it in the dependency array, but here?
I'm curious about this as well. But doesn't the old solution($: {code()}) have this exact problem?
+++
@brandonstelog1557 no, because you would have only referenced the variables you want to react to
$: handleChange(count)
You create nested effects I guess.
Also your example has no real world use-case, if your effects uses variables it should run when any of them changes, your example is not an example for the real world, the is no situation where you want to run the effect is just one changes, you can have multiple effects for that.
Is there a release time estimate yet? Its still confusing to me but after i watch 20 videos about it and get my hands dirty with it over the next month ill have the 🤯 moment as always occurs
Not yet.
Well i feel a guy from reactjs will make svelte more complicated. Now svelte not simple, harder to use and learn than reactjs, maybe we should learn reactjs
Have you tried it?
How awesome is this 🔥
This is a bit strange, I will need more time to get rid of the old reactivity system, this is a lot of React like, and React is boring
It reminds me more of Solid and Vue because of how similar the API looks and signals are used in almost every framework but React.
5:24 i think this is supposed to be const counter =
(But doesnt hurt our understanding so its fine)
Should be illegal to post this video so early. Kinda like insider trading😏. Seriously though, great breakdown🔥
Insider knowledge. 🤫
Looks... solid. 😉
This looks great, but this is basically what Vue 3 has had for a long time if I'm not mistaken. Just maybe without the effect rune. Need to double check if there's some equivalent to that.
watch and watchEffect are the Vue equivalents:)
@@sigveha Thanks! But can you do nested watches?
@@yitzchaksviridyuk932 What you mean by nested watches?
@@alisherdotdev Well, in the video, you see Matt defining an $effect within an $effect. I assume that this means that you can have some effects that are dependent on other effects. I'm not sure what the use case for this would be, but since we're just trying to figure out what the equivalent to $effect would be in Vue, I was just trying to double check how similar watch is to $effect. Just checked right now btw, and yeah, you could also do nested watches in Vue... Definitely something to avoid in my opinion, but anyway, seems like Vue 3 had all this stuff all along, with the same precision, etc.
Amazing video! This was much better explained than the official docs and the svelte team videos!
I dig all these improvements. tried it and looks like I am writing react, which make me vomit all night. what next, JSX coming in 6? great vid as always btw
The syntax is terrible
If i wanted to use react, I would use react.
How beautiful is this, friends?
smells like react
Back in the day I looked at all those frameworks and went with Vue... seeing this here made me really happy that I apparently made the right decision back then.
This reactivity system does really not look good to me.
@@Niiju Cause it's so much magic and not Javascript at all
@@dasten123imagine thinking vanilla js is a good language 🥶🥶🥶
Svelte before was magic and not JavaScript, you Svelte devs are confused.@@dasten123
@@dasten123 signals are the most predictable, least magical form of reactivity we've got, which is why everyone's switching to them
I'm happy for you! 😄
7:44 If it's a cleanup function, why does it run every time count changes?
Svelte is getting needlessly complicated
Have you tried it?
This makes it easier instead of more complicated
I appreciate that there's now a consistent way to handle state, whether it's in a Svelte component or a separate file. That's a big win. However, if I'm understanding this correctly, for complex applications that have several values per $state, this is going to add a ton of boilerplate with lots of getters and setters.
Will there ever be a vdo without 'how beautiful is this' 😅😅
I like it tho!!!
I hope not.
as always your video and explanation are great! thanks for the great content!
Do current stores need to be rewritten using Runes and state declaration?
you can use stores but they're going to be deprecated in the future
Thanks, I updated my app to Svelte 5 but as soon as update a store to utilize runes the rest of the files also need to be updated you can’t mixed both.
Easy explaination
I escaped to sveltekit from react only for sveltekit to become react
Signals finally!
Man that was fast
Are there any drawbacks using the new runes compared to the let statements? Performance between these two? Are there times you would want to use the let statements instead of the new runes?
You don't have to think about it because signals are going to be the only reactive system.
Jesus you are fast! Rich showed it 4 hours ago and your video is already up for 45minutes 😂
I got early access.
Suppose you want to pass a parameter into increment, how would you do it?
You just pass it as a function argument.
so can I use any of these rune thingies to calc something in {#each} blocks or am I still limited to doing all this in the tag?
You use the @const to do a quick calc and your result is returned to your @const variable
@@senseicodes**impostor syndrome intensifies** 😳 thank you SO MUCH
One newbie question, can svelte do everything react or next can?
Yes. Much better. React re-renders everything like crazy by default. You need to verbose your code in React by implementing "memos" workarounds if you want to run a list with 200 component instances with sort, filter and transitions. React just fails to keep things running smoothly by default. It's the worst architecture among the biggest frameworks. However, the most used.
Don't listen to this beginner above me... react is fine and next too.
You can't go wrong picking either one.
Don't listen to me. Just implement a simple test in React: Write a styled card component, put some transitions and try to sort and filter a list of 200 instances. "Oh, you need to use memo!". Yes! native workaround for bad architecture.
@@leopb21 I see you know nothing about how svelte lists internally work and that they are inefficient, if you would have listened to Rich Harris Runes presentation you would have heard exactly that and that Rich himself admits this. And that is exactly the problem with beginner mentality just like teenagers in their worst years they think they already know everything and no one should try explaining to them why things are how they are. I'm not even a "Only React" guy, I use many techs besides that like Solid or Vue but your dumb comment made me just sad that people like you with 0 understanding of how Frameworks work under the hood want to prove themselves here in the youtube comments.
Wow, having finally been exposed to Svelte's syntax, I realized why it never took off, because it's sh*t
Thank you for your insight.
Why svelte never took off? Have you been living under a rock?