Refreshing take. I'm still on the fence, but it does feel like they are throwing the baby out with the bathwater. Svelte is the most loved framework, so fracturing the DX like this is a bold move...
I understand the need for this, but at the same time, I'd rather have a way to opt out reactivity instead of this secondary way to declare reactivity. It looks like janky Vue or React ,and completely undermines everything I liked about writing Svelte to begin with. I get that most of what I want to do will continue to work, but it plays at a fear I have had since the "+page" change in SvelteKit - big changes that I'm not really onboard with can and do happen in the Svelte ecosystem. I think I'm back to the Vue and Nuxt team for the foreseeable future...
@@ReddSpark svelte is more becoming more like solid, not react. the mental model is completely different. the dx is still dead simple. there's only slightly more mental overhead that gives us more control which is a good thing. this change was needed to create more svelte jobs because svelte 4 did not scale.
I've been coding in Svelte for years and hardly ever bumped into any reactivity problems. Runes feel like an attempt to solve a few edge cases at the expense of the simplicity I use 99% of the times.
Agree, I'm not a pro, coding for fun/side projects and svelte was amazing. it's not rocket science, but it adds complexity that I didnt have to worry about to get started before. I mean I just commented my variables, that worked.
I appreciate this take, I think a lot of people agree, but it's difficult to voice a negative/dissenting opinion when you also want to show appreciation to the amazing maintainers. Glad you made the case for simplicity, I'd hate for Svelte to lose the character of DX that attracted me to the project initially.
I *think* I prefer the old way so it would be nice if the old way was still the default and if you need the precision of signals you can use the runes...
I had the same exact take! I'm glad i'm not alone in this haha. I understand the problem they are trying to fix with these new runes (which are basically hooks) but I loved how the old logics worked in svelte. Now i just feel like we're gonna be writting React with a different syntax. They are trying to solve the same problems that react had a couple years ago with the same solution that react had a couples years ago. I feel like js frameworks should try to propose different solutions to a problem instead of all slowly becoming the same.
The semantics are very different to react, and look more like solid or preact signals. The point is to have a reactivity primitive (sort of like how Vue 3 revamped its reactivity system) if you want to define your own store-like objects, not that you need to use runes yourself everywhere.
3:52 in what way reactivity of svelte is similar to react? we have no component re renders, and also you can define and initialize runes outside component.
I'm mainly talking about surface level similarities in v5, not how it works under the hood. On the surface needing to use $state feels like using the useState hook in React or the ref / reactive composition functions in Vue. It is something extra we have to look at in the code when ultimately we just want a reactive variable. I know that inside of components, $state will work like it does today, but once we start creating state outside of components, we will need getters / setters (like signals in Solid) or refs (like in Vue). The code goes from simple variable assignments to needing to call getter / setter functions or using .value everywhere we need some reactive state. My argument is that most new developers to Svelte will see the surface similarities to what they are used to in React / Vue / Solid and DX will be less of a reason to switch to Svelte.
@@CodingGarden one way or another they would lose adoption, because over time those new developers would learn that having more magic and less control is not always such a great thing. it was a gimmick that wouldn't have lasted the test of time. i think svelte is still much simpler than vue with this change, and sveltekit in particular is far nicer to use than nuxt.
I only wish they made this call before v1 so we dont have to see multiple ways to do same thing moving forward. I do think it was odd having diff syntax in stores vs components like u dont call get(some_var) in a .svelte and I think this will make my code way better by creating these composition like vue 3 funcs and just calling methods on it. I like the idea of exposing funcs to app not variables so i can control ability. Similar to how i do my backend exposing funcs rather than row-line security which makes no sense to me why pushed so hard cause seams impractical beyond todo apps I hope it gets released soon!
They could just fix the old stuffs where if a variable is referenced somewhere it will be a reactive variable, else it would be just normal variable. Also the $: could be fixed without the $effect. I believe if you have to change something just change the hidden layers, don't change things which are people used to and lot of projects are dependent to. Because the end result is just compiled JS.
I can't disagree, I feel the same, although "old style" svelte is not going to disappear. I guess for basic pages you won't notice, and for those cases where you need a complex solution now you have it. I think sites don't need runes, apps might.
thinking react projects and devs will switch to svelte because of similar look is stupid imo. People who are comfortable with what they use will keep using it and rest won't. Making svelte more like everyone else will just make it that and nothing more. Instead of fixing that api if there is an issue, leaving it behind and making a new one is more weird. You don't import any of these runes. You don't call your states as function as you do with Solid. This is still weird for other frameworks and it will be a bigger issue for a react dev to not import but able to use something. They will still complain that this is magic and I want to see the code in plain js, then write more jsx.
Also now that i know of its existance and my full willingness to use it yet not actually being released im like ah do i want to build that thing now since when they release ill likely redo it again
I guess they got to the point where they found it too difficult to make the Svelte compiler smart enough to unambiguously understand developer intentions, and so derive accurate and performant code. As a fairly experienced React dev, who's planning to jump ship to Svelte because it looked like a breath of fresh air, it's kind of disappointing.
Svelte used to work like magic because of the compiler, so they've used the word "runes" to invoke the idea of magic whilst, in reality, moving away from the actual magic and towards the declarative.
runes still need work and the API design isn't complete yet. This means conversations like this will hopefully lead to a better DX in the final product. Right now it seems like DX outside of components is improved while DX inside components will be slightly degraded. There are also issues of reactivity tracking in nested objects / arrays that need to be fixed and conversations about which extra utility functions will ship in v5. These are all conversations where the resulting answers / solutions could either help or hurt DX as well. github.com/sveltejs/svelte/issues/9240 github.com/sveltejs/svelte/issues/9249 github.com/sveltejs/svelte/issues/9237 github.com/sveltejs/svelte/issues/9248
This is quite unfortunate. I started using svelte because it was the framework that was closest to vanilla JS. At least for now the old way still works, but if it ever gets deprecated I will start looking for the next svelte.
reactivity is such an over-intellectualized term in modern front end it's becoming quite cringe. just leave vanilla js as is or use WASM or another language
Refreshing take. I'm still on the fence, but it does feel like they are throwing the baby out with the bathwater. Svelte is the most loved framework, so fracturing the DX like this is a bold move...
I understand the need for this, but at the same time, I'd rather have a way to opt out reactivity instead of this secondary way to declare reactivity. It looks like janky Vue or React ,and completely undermines everything I liked about writing Svelte to begin with. I get that most of what I want to do will continue to work, but it plays at a fear I have had since the "+page" change in SvelteKit - big changes that I'm not really onboard with can and do happen in the Svelte ecosystem. I think I'm back to the Vue and Nuxt team for the foreseeable future...
Rich posted a follow up video recently explaining more about the thinking behind Runes.
If Svelte is becoming more Reactlike, and React where all the jobs are, then why not learn React?
Because React is exactly like React. In fact, it's the most like React of all the frameworks.@@ReddSpark
@@ReddSpark svelte is more becoming more like solid, not react. the mental model is completely different. the dx is still dead simple. there's only slightly more mental overhead that gives us more control which is a good thing. this change was needed to create more svelte jobs because svelte 4 did not scale.
I've been coding in Svelte for years and hardly ever bumped into any reactivity problems. Runes feel like an attempt to solve a few edge cases at the expense of the simplicity I use 99% of the times.
Love your take! 😄
Agree, I'm not a pro, coding for fun/side projects and svelte was amazing. it's not rocket science, but it adds complexity that I didnt have to worry about to get started before. I mean I just commented my variables, that worked.
Totally agree with your thoughts on this. I wouldn't mind so much but I i do expect our beloved syntax will be deprecated at some point 😢
I appreciate this take, I think a lot of people agree, but it's difficult to voice a negative/dissenting opinion when you also want to show appreciation to the amazing maintainers. Glad you made the case for simplicity, I'd hate for Svelte to lose the character of DX that attracted me to the project initially.
I *think* I prefer the old way so it would be nice if the old way was still the default and if you need the precision of signals you can use the runes...
I think the tradeoffs are still a net positive but the point regarding derived taking in an expression could be weird at first
I had the same exact take! I'm glad i'm not alone in this haha. I understand the problem they are trying to fix with these new runes (which are basically hooks) but I loved how the old logics worked in svelte. Now i just feel like we're gonna be writting React with a different syntax. They are trying to solve the same problems that react had a couple years ago with the same solution that react had a couples years ago. I feel like js frameworks should try to propose different solutions to a problem instead of all slowly becoming the same.
The semantics are very different to react, and look more like solid or preact signals.
The point is to have a reactivity primitive (sort of like how Vue 3 revamped its reactivity system) if you want to define your own store-like objects, not that you need to use runes yourself everywhere.
3:52 in what way reactivity of svelte is similar to react? we have no component re renders, and also you can define and initialize runes outside component.
I'm mainly talking about surface level similarities in v5, not how it works under the hood. On the surface needing to use $state feels like using the useState hook in React or the ref / reactive composition functions in Vue. It is something extra we have to look at in the code when ultimately we just want a reactive variable.
I know that inside of components, $state will work like it does today, but once we start creating state outside of components, we will need getters / setters (like signals in Solid) or refs (like in Vue). The code goes from simple variable assignments to needing to call getter / setter functions or using .value everywhere we need some reactive state.
My argument is that most new developers to Svelte will see the surface similarities to what they are used to in React / Vue / Solid and DX will be less of a reason to switch to Svelte.
@@CodingGarden one way or another they would lose adoption, because over time those new developers would learn that having more magic and less control is not always such a great thing. it was a gimmick that wouldn't have lasted the test of time. i think svelte is still much simpler than vue with this change, and sveltekit in particular is far nicer to use than nuxt.
Maybe something like a script tag property to indicate that variables in the given script are computed/reactive may have been a bit cleaner
I only wish they made this call before v1 so we dont have to see multiple ways to do same thing moving forward.
I do think it was odd having diff syntax in stores vs components like u dont call get(some_var) in a .svelte and I think this will make my code way better by creating these composition like vue 3 funcs and just calling methods on it.
I like the idea of exposing funcs to app not variables so i can control ability. Similar to how i do my backend exposing funcs rather than row-line security which makes no sense to me why pushed so hard cause seams impractical beyond todo apps
I hope it gets released soon!
Good perspective. Interesting watch.
They could just fix the old stuffs where if a variable is referenced somewhere it will be a reactive variable, else it would be just normal variable. Also the $: could be fixed without the $effect. I believe if you have to change something just change the hidden layers, don't change things which are people used to and lot of projects are dependent to. Because the end result is just compiled JS.
I can't disagree, I feel the same, although "old style" svelte is not going to disappear. I guess for basic pages you won't notice, and for those cases where you need a complex solution now you have it. I think sites don't need runes, apps might.
I like that thumbnail btw i clicked instantly
Rich was nerd sniped into implementing signals, making React the only non-signal web framework left
i agree with your view, maybe svelte team can't do besthing like before. They can't keep simple of svelte.
thinking react projects and devs will switch to svelte because of similar look is stupid imo. People who are comfortable with what they use will keep using it and rest won't. Making svelte more like everyone else will just make it that and nothing more. Instead of fixing that api if there is an issue, leaving it behind and making a new one is more weird. You don't import any of these runes. You don't call your states as function as you do with Solid. This is still weird for other frameworks and it will be a bigger issue for a react dev to not import but able to use something. They will still complain that this is magic and I want to see the code in plain js, then write more jsx.
Runes are the new hooks😊
Also now that i know of its existance and my full willingness to use it yet not actually being released im like ah do i want to build that thing now since when they release ill likely redo it again
I Love Rich I Love Svelte
Svelte is still GOAT
I guess they got to the point where they found it too difficult to make the Svelte compiler smart enough to unambiguously understand developer intentions, and so derive accurate and performant code. As a fairly experienced React dev, who's planning to jump ship to Svelte because it looked like a breath of fresh air, it's kind of disappointing.
Runes is a dumb name
Svelte used to work like magic because of the compiler, so they've used the word "runes" to invoke the idea of magic whilst, in reality, moving away from the actual magic and towards the declarative.
I hope Svelte team, don't hear you all, because this runes Will improve the DX in larger projects, and improve the compiled projects performance
runes still need work and the API design isn't complete yet. This means conversations like this will hopefully lead to a better DX in the final product.
Right now it seems like DX outside of components is improved while DX inside components will be slightly degraded.
There are also issues of reactivity tracking in nested objects / arrays that need to be fixed and conversations about which extra utility functions will ship in v5. These are all conversations where the resulting answers / solutions could either help or hurt DX as well.
github.com/sveltejs/svelte/issues/9240
github.com/sveltejs/svelte/issues/9249
github.com/sveltejs/svelte/issues/9237
github.com/sveltejs/svelte/issues/9248
This is quite unfortunate. I started using svelte because it was the framework that was closest to vanilla JS. At least for now the old way still works, but if it ever gets deprecated I will start looking for the next svelte.
Second!
First!
reactivity is such an over-intellectualized term in modern front end it's becoming quite cringe. just leave vanilla js as is or use WASM or another language
Svelte is dead to me. absolutely pointless. these frameworks are an absolute waste of time. just use proxies in vanilla js