Oh yes you said "Svelte is teaching you JavaScript" in your last video and that was absolutely spot on! This, and Rich Harris giving credit to Ryan Carniato is showing us how we really are in great hands with Svelte and its community!
I know you got a lot going on, but if you ever decide to do more YT content in a more consistent manner, I would just say everyone would be really happy about it because you can share info in a really neat and concise way. The way you explain things is just excellent.
Thanks for this. Describing $state as a primitive to build from, and that there may be ways to simplify standard coding patterns once we've all had chance to figure out what those are, should allay many fears. This whole issue of wanting to treat a $state as a value, but also a signal, always seemed to be where the awkwardness would be. Using signals is 100% the way forward though - it would take a hell of a lot more than possibly needing a small amount of extra boilerplate for me to be anything other than extremely enthusiastic with this.
I definitely think the doubters stop thinking about the implications after seeing the initial boilerplate. Maybe the mistake was making state and effect reflect react lol
Thanks for this video. I've become a big Svelte fan, and while I had some inhibitions with the runes reveal, I trust that the team will take Svelte in the right direction. This is interesting as it shows runes in a different light: as primitives that can be built upon. It also reveals a lot of why people are drawn to Svelte; the perceived simplicity and fact that "it just works". I was able to go through the tutorials quite fast, and the main times I have to refer to documentation seems to be more for SvelteKit. I do wonder if arrays or objects of $state are possible, which wouldn't be possible with the auto-inferred logic.
So, we are not becoming react, or vue, etc... we are letting you be them if you want to. I believe that people who say this takes away svelte's simplicity, and it's going in the wrong direction, haven't built a complex enough app with Svelte to see all the drawbacks of the current system. This will increase svelte market share in the long run, by a lot.
Runes are Svelte stores in disguise. writable -> $state derived -> $derived/$effect subscribe -> $derived/$effect Bringing Svelte closer to JS is what I think people are missing. Understanding JS/TS at a relatively high level, and having worked with Svelte for years, I completely understand the need - and I love this! ... Unfortunately Svelte's magic is lost. "Imperative" assignments to gain reactivity that is (compared to before). To make Runes easier to embrace, consider having `$` not only accept `.subscribe`, but also `.value`, so that `count.value` becomes `$count`. Runes are great, but we, the people, want a shorthand operand🙏 Two open questions: - Can you dig into how $state actually works behind the scenes to make things reactive, and how it differs from before? - How is the direct comparison between Svelte stores and Svelte runes?
the only hangup with your suggestion is that there would be a different syntax for accessing state between svelte components and in modules. People could opt-out with a linter but then reading svelte between projects wouldn’t be universal. It’s probably better to just accept the small boilerplate over the mental overhead
@@minnow1337 The suggestion is aimed to keep some of the flair Svelte provides with seamless reactivity. The boilerplate was what we were trying to avoid to begin with. At least with Svelte as I remember it. Your POV is naturally acknowledgeable. However, the similarities of $state and writablable means, I might literally just as well use Svelte stores, and throw runes out the window, as $state is less convenient Whatever the Svelte team does. Make it more convenient. Just like Svelte as we know it and love it today.
Hey, Rich, thanks for the explanation. There was a mistake in the first example until 2:24 - you do not actually increment the value in increment function, you have == instead of += there. But it still would not work, exactly like you said. Thanks for explaining everything in a video tho :)
Svelte had the best stores of them all as shown by Fireship. In my opinion, enforcing writable() and removing reactivity from .svelte files unless it was declared with writable() would have been the best option because the interoperability issue around .ts/.js files and .svelte files would be solved with a pattern that is already superior to ref/signals. Open to seeing how this develops either way, but what I most enjoyed about svelte was not having to .value or getCount anymore and knowing that $count meant it was a store.
After explaining the "ref" it does kind of make sense. It seem more flexible now. But now it will be kind of similar to what vue3 did with composition api. I understand the reason for the change but what would be a difference from vue then? Something that will convince to choose svelte over vue. I really hope svelte focus on best DX. Looking forward to new updates! Thank you for your hard work, i enjoyed svelte in my small projects 😊
what if counter returned () => { count, increment } at 3:02 and have const {count, increment} = counter() at 4:41 or we can do something like currying const {count, increment} = createCounter()() ?
I like the idea of frameworks becoming more agnostic to things which are ultimately opinionated. Like I can create a project using Astro, create reactive components using Svelte. And then like shown here, pick between a pattern native to Svelte, one inspired by Vue or one inspired by Solid. All of this flexibility doesn’t really seem to come at the cost of some deep integration or performance. I feel like in the last year or 2 the switching cost between web framework has become significantly smaller, and finding a pareto optimal combination of tools/frameworks/libraries has actually become plausible.
The problem is not using getters and setters, the reality is that a lot of new devs started to code directly with Frameworks, that's the problem, as soon as you introduce a bit of vanilla js they panic! :D which is sad to see. Over the years, teaching js in companies i noticed a lot how the web universe changed. I had people i teached asking me to learn React before learning JS... and this is our fault (js community) cause of the massive confusion this obsession of changing patterns and constant evolution (or involution :D) created and companies adopting it. I really love svelte and the way the v 5 works, keep it up!
Hell of a refactoring, Harris. we still remember the route changes in svelte kit, but you still keep the brand. I am also beginning to understand that this is the philosophy of svelte
I think what the community wants is just a more standardized way of doing things. i know runes are far more primitive (as in it's a primitive to build from) than vue's refs and solid's signals. yes you can make your own getter and setter, and that gives you more freedom. but too much freedom is a DX hell especially working in a cross-libraries and cross-apps setting. a standard "wrapper" from svelte to use runes from any component would be good. we need more consistency in the way of doing things
Thanks for the clarification, could be possible to compile let declaration to $state call, and reactive assigmnet compile to $effect, $derived inside the svelte file, instead of $$invalidate
My biggest issue is that it's not released with no ETA. Don't know if I should wait or continue svelting, but no one wants to write instant legacy code...
i wouldn't worry too much, svelte 4 code will continue to work for a long time, and we'll have tooling to automate as much of the conversion as possible
They didnt give an ETA, so it's not right around the corner. But they announced it, so it's not going to takes years. And the Svelte team is known to push a upcoming release confidently. So my guess is January 2024. :D
Hmm what if I like old Svelte way? I know that for now it will still be available.. But.. what if we lose that old Svelte on next versions? any plans on that or waiting for community return?
Is there a chance that after Svelte 5 comes out, the architecture of the framework will stabilize and will not be changed for the next 10 years (by architecture, I mean a complete break with the api responsible for reactivity between Svelte 4 and Svelte 5)?
I have two main questions: 1) if runes will replace stores - how subscribe can be implemented? 2) How implement derived state with complex cases, like filtering array or object? e.g. const isAdult = $derived(user.age > 18) or const onlineUsers = $derived(users.filter(user => user.online))
I got the impression it's the latter. The syntax for derived seems to want you to pretend that it's not there, even if behind the scenes it's creating a function wrapper and the () => is invisible.
$effect would be the equivalent to the subscribe function of a store. It will also allow you to subscribe to multiple stores at once. Something you would previously have to do by combining multiple stores into a derived store.
It really goes to show how good/bad reacts mental model for reactivity is. The fact that you can just return values from hooks because they always rerun is kinda nice but that is not how js works. Also rather telling that a lot over devs understand react more than they understand JS itself.
the problem is that the line between svelte and other frameworks blurs. even if not having state variables made it more difficult to debug in bigger projects, svelte's main niche was being so damn useful for those smaller projects, to the point where it could have replaced vanilla js entirely
There is essentially no change for local reactivity. The syntax is *marginally* different. That means for small applications, you'll still get an incredibly clean reactivity API that is mostly just javascript. The primatives unlocked with runes only matter for people whose application has scaled to the point where they're solving really complex problems with state and data sharing. As the video points out, taking advantage of the new functionality is meant to be the exception, not the rule.
The reason I use svelte is not because it’s capable of doing it the vue way or the solid way. I think i want svelte to have one way but it might be difficult to unify. i do not know
Hi Rich, would you explain how does the compiler handles runes given you can use them in .ts files too? The way I understand Svelte currently - you compile my .svelte files and you don't really touch my .ts files, there's "magic" with .svelte files, but my .ts files are essentially run as is. And the way I understand it, runes are not some runtime functions - they're flags for your compiler. So how do .js/.ts files fit into the picture?
Even if they're compiled, there may still be a runtime portion in order to achieve optimal performance and to handle dynamic dependencies which the compiler would otherwise struggle with.
I wonder if it would also be possible to expose some internals so that you can use some of the signals magic purely in runtime for cases where you want to maybe share the service with a react native app (just an example just one case that hit me as a possibility that could have a different team with different stack) and maybe add some binding layer where you are sharing the service layer but maybe not the build pipeline, of course that would add a little bit of overhead in some cases where the compiler might have been able to remove it but still. Still a bit uncomfortable about leaking compiler magic into js files
alright, well this was a good video but this seems a bit superfluous to the writable store, is this the $state() rune supposed to be a more concise way to make stores then for my application? honestly my only complaint is effects look too much like react's useEffect. the fact you can nest them though is nice but I'm not sure when i would use it or how it would be abused, i really like the concept of watchers from vue tbh and wished that was in svelte or something that could do object diffing. but idk
Just FYI getters/setters are NOT necessarily idempotent, since they are just functions like any other. Take this for example: const obj = { get prop() { const rand = Math.random(); if (rand < 0.5) return null; return { str: 'blah' }; } }; Accessing prop on obj could get you two different data types if called twice, but TS doesn't know that, so it incorrectly thinks you are good. Even though this is a contrived example the fact that it's possible means that it's not real type safety since you are just fooling the TS compiler in the same way you would with a non-null assertion, although in this case it's not explicit.
I like how this fits into the Svelte philosophy of just being a slight language extension to Javascript & Typescript that adds reactivity. In this case, reactive values where the compiler has more opportunities to compile away unnecessary stuff than something based on runtime diffing
7:55 - I feel like if this was emphasised a lot more, there wouldn't be so many confused people. I had to read the blog post a few times, watch this video twice, read some of the fireship X thread to finally understand what runes are trying to solve. I actually encountered the same problem in my app and ended up implementing a custom store - it just two-way binds an object to a firebase realtime db path. It will be a lot cleaner with the new syntax, but essentially the same thing.
Overall i feel that svelte got more complicated, look at the todos example at 7:27, this is telling me that now there's a separation between the "serializable JSON representation of the state" and the "reactive version of it", in order to make an array received from an API "reactive" we now need to convert it and replace every property with getter and setters that point to $states, and even if we create a recursive utility function you still to do something like "makeReactive(fetchedData)", the alternative is that you set the whole object in the state and you replace it all with the react way "data.value = {...data.value, foo: { ...data.value.foo, bar: newBar}}" or "data.value.bar= mewBar; obj.value = data.value".
How would you do it before the change? Why wouldn't you keep doing it after these new primitives are added if you felt that way worked better? I think Rich is very clear in why these new primitives are added, and it's about being able to add reactivity outside of component files.
@@Mankepanke because in a svelte file you have to choose either to activate the "runes" mode or old-school reavtivity (that means everything in the root component scope is reactive). Currently you can just assign the result of the fetch to a variable in the component and if you change anything inside it the reactivity will trigger.
yeah that's how vue does it and it's really annoying, also typesaftey is a big pain because it can get lost when passing through a rewrite function like that.
@@Александр-ч4п5ъ i mean from within effect or other code that tracks dependencies in runtime. Eg log counter 2 current value when counter 1 updates, but not when counter 2 does.
hi i have read the github about how svelte is a language and kinda replaces js. are you planning on doing something similar to phoenix and drop js mostly?
Great video, I’m familiar with getters and setters. But personally, if a store would have been used, no getters would be necessary 🧐 it was enough to understand that a store was an object and would always result in a call by reference. Maybe the compiler could add automagically a getter if it’s a state? 🤔
@flalspspsl6858 the store has a get method? O.o I just know about “get” from “svelte/stores” which does a subscribe and unsubscribe immediately after. Which is fine, since the subscribe method is called by reference and will always present the actual data, not stagnant data (like with runes if a getter is ommited).
In my fantasy dreams (hey, I'm a geek), I dream of a world where Rich and Ryan get together and create a "greatest hits" framework that isn't necessarily backwards-compatible (but could have a migration layer) like SolidSvelte 6 or something like that. (I know, supporters of both frameworks would probably revolt, I'm looking at the future only. And I've already ported things from Svelte to Solid and Solid to Svelte so I'd do it one more time for SolidSvelte (stupid name but you get the idea).
The Svelte creator to TH-cam content creator arc is something I was not expecting but I'm here for it.
Oh yes you said "Svelte is teaching you JavaScript" in your last video and that was absolutely spot on! This, and Rich Harris giving credit to Ryan Carniato is showing us how we really are in great hands with Svelte and its community!
love you channel dude
i did learn everything about steven from joyOfCode, awesome.
"how awesome is that?" Cheers, mate!
looking forward for more videos from you man, you're Awesome!
Applause for making the video, taking the feedback, building in the open and just making a great tool!
I know you got a lot going on, but if you ever decide to do more YT content in a more consistent manner, I would just say everyone would be really happy about it because you can share info in a really neat and concise way. The way you explain things is just excellent.
Thanks for this. Describing $state as a primitive to build from, and that there may be ways to simplify standard coding patterns once we've all had chance to figure out what those are, should allay many fears. This whole issue of wanting to treat a $state as a value, but also a signal, always seemed to be where the awkwardness would be. Using signals is 100% the way forward though - it would take a hell of a lot more than possibly needing a small amount of extra boilerplate for me to be anything other than extremely enthusiastic with this.
I definitely think the doubters stop thinking about the implications after seeing the initial boilerplate. Maybe the mistake was making state and effect reflect react lol
I fundamentally misunderstood how the runes worked originally. This is a great explanation. They seem to be a lot smarter than I originally thought
This was helpful, thanks.
You should make videos more regularly, Rich, by the way. Lots of people would be interested.
I’m in. Thank you Rich. Still waiting for an update to Ractive.
Kidding of course. That’s where I got on this train and really glad I did!
You need to share more in video, your presentations are always unique! 👏
My only concern at this point is the use of light theme for demoing things 😭
Otherwise, runes API is so neat and flexible
thanks for the video and hope to see more content like this from you Rich, appreciate all the work you do
Thank you Rich. If anything I am just learning more about JS :)
Thanks for this, really cleared most of confusion
Thanks for clearing this up, Rich! Love the new changes!
Thanks for this video. I've become a big Svelte fan, and while I had some inhibitions with the runes reveal, I trust that the team will take Svelte in the right direction.
This is interesting as it shows runes in a different light: as primitives that can be built upon.
It also reveals a lot of why people are drawn to Svelte; the perceived simplicity and fact that "it just works". I was able to go through the tutorials quite fast, and the main times I have to refer to documentation seems to be more for SvelteKit.
I do wonder if arrays or objects of $state are possible, which wouldn't be possible with the auto-inferred logic.
This was very helpful to get a better picture of the new stuff. Thanks Rich.
Incredible teacher and innovator!
this was sooooo much better in getting an understanding of Runes,
You are truly amazing bro
thank you for the video and for svelte as well
Great examples Rich! Love these explanations!
So, we are not becoming react, or vue, etc... we are letting you be them if you want to.
I believe that people who say this takes away svelte's simplicity, and it's going in the wrong direction, haven't built a complex enough app with Svelte to see all the drawbacks of the current system.
This will increase svelte market share in the long run, by a lot.
If people are building apps where they want simple reactivity without inches of boilerplate, why would they care about Svelte's market share?
Amazing, Thank you Rich ❤
Runes are Svelte stores in disguise.
writable -> $state
derived -> $derived/$effect
subscribe -> $derived/$effect
Bringing Svelte closer to JS is what I think people are missing. Understanding JS/TS at a relatively high level, and having worked with Svelte for years, I completely understand the need - and I love this!
... Unfortunately Svelte's magic is lost. "Imperative" assignments to gain reactivity that is (compared to before).
To make Runes easier to embrace, consider having `$` not only accept `.subscribe`, but also `.value`, so that `count.value` becomes `$count`. Runes are great, but we, the people, want a shorthand operand🙏
Two open questions:
- Can you dig into how $state actually works behind the scenes to make things reactive, and how it differs from before?
- How is the direct comparison between Svelte stores and Svelte runes?
the only hangup with your suggestion is that there would be a different syntax for accessing state between svelte components and in modules. People could opt-out with a linter but then reading svelte between projects wouldn’t be universal. It’s probably better to just accept the small boilerplate over the mental overhead
@@minnow1337 The suggestion is aimed to keep some of the flair Svelte provides with seamless reactivity.
The boilerplate was what we were trying to avoid to begin with. At least with Svelte as I remember it.
Your POV is naturally acknowledgeable.
However, the similarities of $state and writablable means, I might literally just as well use Svelte stores, and throw runes out the window, as $state is less convenient
Whatever the Svelte team does. Make it more convenient. Just like Svelte as we know it and love it today.
These are exactly my questions!
Hey, Rich, thanks for the explanation. There was a mistake in the first example until 2:24 - you do not actually increment the value in increment function, you have == instead of += there. But it still would not work, exactly like you said. Thanks for explaining everything in a video tho :)
I don't see it, there is always += there, never ==. Maybe on a smaller screen it appears as ==? I don't know.
rich, you are a massive inspiration to me. thank you.
Svelte had the best stores of them all as shown by Fireship. In my opinion, enforcing writable() and removing reactivity from .svelte files unless it was declared with writable() would have been the best option because the interoperability issue around .ts/.js files and .svelte files would be solved with a pattern that is already superior to ref/signals. Open to seeing how this develops either way, but what I most enjoyed about svelte was not having to .value or getCount anymore and knowing that $count meant it was a store.
After explaining the "ref" it does kind of make sense. It seem more flexible now. But now it will be kind of similar to what vue3 did with composition api. I understand the reason for the change but what would be a difference from vue then? Something that will convince to choose svelte over vue. I really hope svelte focus on best DX.
Looking forward to new updates!
Thank you for your hard work, i enjoyed svelte in my small projects 😊
Svelte and Vue are still very different. Svelte is compiled to vanilla is and Vue as of today still requires the Vue runtime to run.
@@soundrightmusic compiled and blah blah is not DX, svelte 4 has best DX
what if counter returned () => { count, increment } at 3:02 and have const {count, increment} = counter() at 4:41 or we can do something like currying const {count, increment} = createCounter()() ?
This was super helpful, thank you for posting. Subscribing immediately, hoping for more of this in the future. Cheers
Hey chill out man you’re gonna kill my channel if you keep posting content like this 😂
Hey, nice to see you here!
Although I really love svelte stores and I have formed a relationship with them, but being able to do reactive values like this is just *shefs kiss*
Thanks for clearing some of that stuff up.
I like the idea of frameworks becoming more agnostic to things which are ultimately opinionated. Like I can create a project using Astro, create reactive components using Svelte. And then like shown here, pick between a pattern native to Svelte, one inspired by Vue or one inspired by Solid.
All of this flexibility doesn’t really seem to come at the cost of some deep integration or performance. I feel like in the last year or 2 the switching cost between web framework has become significantly smaller, and finding a pareto optimal combination of tools/frameworks/libraries has actually become plausible.
Thanks for explaining the getters & setters, my vote is the ref vue way added to svelte please! 💜
This clears up a lot of things. Thanks!
Getter and setter are in Js since ES5, many OO languages have them. No need to panic, they are useful. 👍
@@mikeontheboxDid you not see the video? `const counter = ref(0)` and you're done.
You're good at this youtube thing. You should do it some more :D
The problem is not using getters and setters, the reality is that a lot of new devs started to code directly with Frameworks, that's the problem, as soon as you introduce a bit of vanilla js they panic! :D which is sad to see. Over the years, teaching js in companies i noticed a lot how the web universe changed. I had people i teached asking me to learn React before learning JS... and this is our fault (js community) cause of the massive confusion this obsession of changing patterns and constant evolution (or involution :D) created and companies adopting it. I really love svelte and the way the v 5 works, keep it up!
Cant wait for more videos! And thanks Rich as always for making Web development better!
Great stuff, Rich!
That's awesome! This runes will make Svelte much more viable to me, probably a very good alternative to Vue. Gonna look for that
Hell of a refactoring, Harris. we still remember the route changes in svelte kit, but you still keep the brand. I am also beginning to understand that this is the philosophy of svelte
Thanks for this awesome video! 👏
Good video Rich!
I'd like to see a comparison between store(writable) and runes way, to see the benefits.
I think what the community wants is just a more standardized way of doing things. i know runes are far more primitive (as in it's a primitive to build from) than vue's refs and solid's signals. yes you can make your own getter and setter, and that gives you more freedom. but too much freedom is a DX hell especially working in a cross-libraries and cross-apps setting. a standard "wrapper" from svelte to use runes from any component would be good. we need more consistency in the way of doing things
Still, I appreciate the amazing work! thanks for trying to clear up!
6:40 "ain't nobody got time 4 that" - Rich Harris 2023
Thanks for the clarification, could be possible to compile let declaration to $state call, and reactive assigmnet compile to $effect, $derived inside the svelte file, instead of $$invalidate
I wonder what the old style code will compile to when used with the new Svelte 5 engine.
My biggest issue is that it's not released with no ETA. Don't know if I should wait or continue svelting, but no one wants to write instant legacy code...
i wouldn't worry too much, svelte 4 code will continue to work for a long time, and we'll have tooling to automate as much of the conversion as possible
They didnt give an ETA, so it's not right around the corner. But they announced it, so it's not going to takes years. And the Svelte team is known to push a upcoming release confidently. So my guess is January 2024. :D
rich harris you tube channel official no way
My favorite new channel. I forgive you for stealing from that all the frameworks!
Thanks Rich.
great explanation!
Hmm what if I like old Svelte way? I know that for now it will still be available.. But.. what if we lose that old Svelte on next versions? any plans on that or waiting for community return?
Definitely just hit the subscribe button before watching the video.
Awesome Video!
Is there a chance that after Svelte 5 comes out, the architecture of the framework will stabilize and will not be changed for the next 10 years (by architecture, I mean a complete break with the api responsible for reactivity between Svelte 4 and Svelte 5)?
I have two main questions:
1) if runes will replace stores - how subscribe can be implemented?
2) How implement derived state with complex cases, like filtering array or object?
e.g.
const isAdult = $derived(user.age > 18)
or
const onlineUsers = $derived(users.filter(user => user.online))
I got the impression it's the latter. The syntax for derived seems to want you to pretend that it's not there, even if behind the scenes it's creating a function wrapper and the () => is invisible.
$effect would be the equivalent to the subscribe function of a store. It will also allow you to subscribe to multiple stores at once. Something you would previously have to do by combining multiple stores into a derived store.
It really goes to show how good/bad reacts mental model for reactivity is. The fact that you can just return values from hooks because they always rerun is kinda nice but that is not how js works. Also rather telling that a lot over devs understand react more than they understand JS itself.
I Just Love u and i Love Svelte
the problem is that the line between svelte and other frameworks blurs. even if not having state variables made it more difficult to debug in bigger projects, svelte's main niche was being so damn useful for those smaller projects, to the point where it could have replaced vanilla js entirely
There is essentially no change for local reactivity. The syntax is *marginally* different. That means for small applications, you'll still get an incredibly clean reactivity API that is mostly just javascript. The primatives unlocked with runes only matter for people whose application has scaled to the point where they're solving really complex problems with state and data sharing. As the video points out, taking advantage of the new functionality is meant to be the exception, not the rule.
The solid influence is noticeable but why should that be a bad thing!?
Does this change bring in the same pitfalls that Vue 2's reactivity system was subject to?
The reason I use svelte is not because it’s capable of doing it the vue way or the solid way.
I think i want svelte to have one way but it might be difficult to unify. i do not know
Hi Rich, would you explain how does the compiler handles runes given you can use them in .ts files too? The way I understand Svelte currently - you compile my .svelte files and you don't really touch my .ts files, there's "magic" with .svelte files, but my .ts files are essentially run as is.
And the way I understand it, runes are not some runtime functions - they're flags for your compiler. So how do .js/.ts files fit into the picture?
By using $state, $effect compiler know that this file must be compiled by svelte
It's type of macro
Even if they're compiled, there may still be a runtime portion in order to achieve optimal performance and to handle dynamic dependencies which the compiler would otherwise struggle with.
I wonder if it would also be possible to expose some internals so that you can use some of the signals magic purely in runtime for cases where you want to maybe share the service with a react native app (just an example just one case that hit me as a possibility that could have a different team with different stack) and maybe add some binding layer where you are sharing the service layer but maybe not the build pipeline, of course that would add a little bit of overhead in some cases where the compiler might have been able to remove it but still. Still a bit uncomfortable about leaking compiler magic into js files
alright, well this was a good video but this seems a bit superfluous to the writable store, is this the $state() rune supposed to be a more concise way to make stores then for my application?
honestly my only complaint is effects look too much like react's useEffect. the fact you can nest them though is nice but I'm not sure when i would use it or how it would be abused, i really like the concept of watchers from vue tbh and wished that was in svelte or something that could do object diffing. but idk
we are so back !!
Rich you are the GOAT
Should've done this as the first demo. The initial demo pissed me off
Just FYI getters/setters are NOT necessarily idempotent, since they are just functions like any other. Take this for example:
const obj = {
get prop() {
const rand = Math.random();
if (rand < 0.5) return null;
return { str: 'blah' };
}
};
Accessing prop on obj could get you two different data types if called twice, but TS doesn't know that, so it incorrectly thinks you are good. Even though this is a contrived example the fact that it's possible means that it's not real type safety since you are just fooling the TS compiler in the same way you would with a non-null assertion, although in this case it's not explicit.
actually just a very good tutorial
Still not sold, what's wrong with stores again?
I like how this fits into the Svelte philosophy of just being a slight language extension to Javascript & Typescript that adds reactivity. In this case, reactive values where the compiler has more opportunities to compile away unnecessary stuff than something based on runtime diffing
Ryan Carniatio speaks
Framework leaders: "write that down, write that down"
7:55 - I feel like if this was emphasised a lot more, there wouldn't be so many confused people. I had to read the blog post a few times, watch this video twice, read some of the fireship X thread to finally understand what runes are trying to solve. I actually encountered the same problem in my app and ended up implementing a custom store - it just two-way binds an object to a firebase realtime db path. It will be a lot cleaner with the new syntax, but essentially the same thing.
Overall i feel that svelte got more complicated, look at the todos example at 7:27, this is telling me that now there's a separation between the "serializable JSON representation of the state" and the "reactive version of it", in order to make an array received from an API "reactive" we now need to convert it and replace every property with getter and setters that point to $states, and even if we create a recursive utility function you still to do something like "makeReactive(fetchedData)", the alternative is that you set the whole object in the state and you replace it all with the react way "data.value = {...data.value, foo: { ...data.value.foo, bar: newBar}}" or "data.value.bar= mewBar; obj.value = data.value".
How would you do it before the change? Why wouldn't you keep doing it after these new primitives are added if you felt that way worked better? I think Rich is very clear in why these new primitives are added, and it's about being able to add reactivity outside of component files.
@@Mankepanke because in a svelte file you have to choose either to activate the "runes" mode or old-school reavtivity (that means everything in the root component scope is reactive). Currently you can just assign the result of the fetch to a variable in the component and if you change anything inside it the reactivity will trigger.
yeah that's how vue does it and it's really annoying, also typesaftey is a big pain because it can get lost when passing through a rewrite function like that.
How do i peek state value without it being registered as a dependency?
Just like an ordinary variable
let variable = $state(0)
variable = variable + 1
//etc
{variable}
@@Александр-ч4п5ъ i mean from within effect or other code that tracks dependencies in runtime. Eg log counter 2 current value when counter 1 updates, but not when counter 2 does.
@@xazzzi There is an `untrack` function, look it up in the docs
Can you compare Svelte 5 runes with Preact Signal?
Great video!
So basically the mission didn't work out. Very sad. I guess we just cannot have nice things in the JS hell.
Love svelte❤
hi i have read the github about how svelte is a language and kinda replaces js.
are you planning on doing something similar to phoenix and drop js mostly?
Great video, I’m familiar with getters and setters. But personally, if a store would have been used, no getters would be necessary 🧐 it was enough to understand that a store was an object and would always result in a call by reference. Maybe the compiler could add automagically a getter if it’s a state? 🤔
@flalspspsl6858 the store has a get method? O.o
I just know about “get” from “svelte/stores” which does a subscribe and unsubscribe immediately after.
Which is fine, since the subscribe method is called by reference and will always present the actual data, not stagnant data (like with runes if a getter is ommited).
Don't quite get why derived needs to be set manually and can't get "derived" automatically.
A getter in this context is kind of like javascript's alternative to references.
Your implementation of createSignal actually didn't update the counter: 10:37
What's the correct version?
Just keep watching, literally 5 seconds later it's demonstrated it works: 10:42
In my fantasy dreams (hey, I'm a geek), I dream of a world where Rich and Ryan get together and create a "greatest hits" framework that isn't necessarily backwards-compatible (but could have a migration layer) like SolidSvelte 6 or something like that. (I know, supporters of both frameworks would probably revolt, I'm looking at the future only. And I've already ported things from Svelte to Solid and Solid to Svelte so I'd do it one more time for SolidSvelte (stupid name but you get the idea).
Okay so can I use it? :P
That is soooo coool!
"seen people produce interesting abstractions like deeply nested reactive objects" ooh i wonder who
😁
🚀
It is really sad to see code being molded by TypeScript inability to narrow certain branches...
Just waiting for shadcn on svelete and will switch to svelte.
Great
❤
I don't want to write runes :( I want runes to be baked in in let count = 0;
How do you create a rune outside of a .svelte file then?
Ain't nobody got time for that...!
After React, learning Svelte 4 was fun. After seeing Svelte 5 runes, Lavaral looks joyful to learn. Svelte 5 runed Svelte experience.
now rune makes way more sense!
Fireship's comment still has a point. (Albeit, everything Rich said is true)