Svelte is definitely going to need some higher-order functions to handle nested state. Without it, for anything more complex than a counter, state management is very heavy on the boilerplate.
Yeah, I agree. A day or two after you posted this comment, Rich made another video addressing this concern. He basically explored how other frameworks handle it and mentioned that the Svelte team will likely include some higher-order function(s) to help with this before the release.
Seems like an edge case though. If we're building something like a spreadsheet, better to just use the native DOM api and create a non-framework specific utility.
I'm curious how these code examples compare with Vue, which I've been thinking about more since reactivity has become a hot topic. I love the way this whole video was set up, not being afraid to make syntactic mistakes, and using those mistakes as a segway into the correct syntax. Genius tutorial.
I really liked the Svelte update; it simplifies a lot of things. However, when it comes to arrays and objects, it fell a bit short. I wish they would pay more attention to this aspect, especially since many times apps will consume JSON APIs that return arrays of objects, and having to use a "runify" boilerplate function is not very convenient.
My thoughts exactly. Vue has already a bigger community. So it kinda kills svelte’s purpose :/ I mean, svelte is still more intuitive in my opinion though
I don’t think the issue with the $derived was that it’s multiple lines, but that it can only take a single expression - an if statement in JS is a statement, not an expression. So your function version, a ternary, etc. would work.
Having literally never coded in svelte I actually can’t imagine what it would’ve looked like before this ( I’m so used to react and the four concepts feel very “react like” )
It's really just an established pattern for a reactive primitive called signals. React doesn't actually have this feature today, which is why you have to define a dependency array in useEffect, memoize what you can, and worry about render cycles. I get what you're saying though. You're right that the terminology _is_ reminiscent of react, but that naming comes from the reactive paradigm that predates react.
Oh of course, thanks for clarifying. I actually started development when RxJS was kind of the big thing - didn't really capture its difference / importance from React as a wee lad and just learned to use React anyways. @@kylerjohnson988
Funny that you think it's "react like" considering react doesn't have fine grained reactivity. It's actually inspired by Solidjs signals, which in turn look (superficially) like react, but actually work as you'd expect, instead of doing everything wrong like react does.
I haven't used Svelte extensively, but I like the explicitness of this because it's clear what each of these does. Also, the fact that it's not something that works only in component files, but it can work in other JS/TS files that are not single file components is great for abstracting logic. Although I do hope they come up with a solution for arrays/objects because having to use a custom function for that seems like it's not "the Svelte way" to do things. To me personally definitely better compared to magic props by using "export" keyword, using "$:" label for derived state etc.
I tried to come up with a VDOM-killer + super-reactive compiler myself. Props to Rich Harris for getting the VDOM part right. However, the reactivity DX is a much harder problem (thats why we have: PropDrilling+Memo,Context,RTK,Jotai,Valtio,Zustand,Mobx,Recoil,Zedux,LegendState). He also recently forked JS so he probably realizes that deep changes are needed to 'solve reactivity'... Using a well-known approach of signals is sort of giving up on finding the "Epic Reactivity Through Compiler Magic".
@Jack it's time for observables as native feature in Javascript, frontend frameworks gets crazy with observability, especially developers, which the same one, hate rxjs, and I don't see any difference here, besides it's better encapsulated...
I know svelte very well. I don't understand how a lot of these are necessary? $state doesn't seem like it does anything, does it save internally to the component?
Thank god I went back to using server side full stack frameworks and got off the frontend js craze, they just keep reinventing the same thing and getting nowhere. Htmx is still the most unique to come out recently as it completely changes how state is handled.
@@madipta right now it’s django since you can accomplish a lot in less time and it has sooo many things you’d want in a web framework out of the box. Admin dashboard and auto migrating databases are some of my favorite parts
@@xyangst the concept isn’t new, true but it’s implemented quite well and removes entire classes of issues with state between frontend and backend by its core architecture which is not like most frontend where they try the most to keep the state in two places.
So true! I've been trying to move away from this crazy frontend world for a while and shift towards backend development with C# .Net. I started with JavaScript in 2007 and had to deal with this madness for over 15 years. I always stayed strong, but it's starting to feel too crazy for me, especially when you keep learning the same stuff over and over again for 15 years and just end up producing HTML. It feels like a waste of life. And then there are all these JavaScript "fans" who don't know anything! It's unbearable. Frontend development has just become a madhouse.
if you watch Rich Harris video over runes, he says the team took what they liked in other software and used this to improve Svelte. This was done from feed back from users, where they found situations that became cumbersome to write, Svelte team has tried to address these with runes
They opened the pandora's box with this change, basically saying old Svelte was wrong. Now it makes you think what if they say runes were wrong too. You can't just say you were fundamentally wrong and expect people to be okay with it.
Frameworks/libraries evolve, learn from their current work and that's a good thing. If they only ever stuck to their original ideas and never improved upon them, Svelte wouldn't be what it is today. Rich Harris talks about this and how many things before Svelte 3 just weren't that great so they kinda reworked a lot of the things to make Svelte what it is today.
I disagree with saying it's wrong. Svelte 3 came out in 2019 before any of this signals stuff was propagated through the whole JS sphere. Frameworks can change over time here's nothing wrong with that.
@@danvilela Solidjs began the new wave of the signals trend way before vue, and Rich has said in his video about runes that they had solid in mInd, not vue btw :)
Hm... This implementation of runify seems to miss that a dev might want to mutate runified arrays by adding items? But going down this path leads to something like lodash/immer/ramda/rx/lenses/optics for runified things. "Every sufficiently complex frontend built with svelte 5 contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of rune-optics".
I don’t understand why these changes are needed. I am already doing all of this without Svelte 5, and I think this is just what I tried getting away from when switching to Svelte
So Svelte is getting matured. But how can i share this logics to other components? Like custom hooks (with useState, useEffect, usememo, useQuery, useAtom, etc...) in React?
This gives me some java vibes that I don't like at all. Is there a reason for not implementing $state for arrays and objets? It's taking away a lot of the simplicity and elegance of the original svelte.
@@TitoMittothe array example made me really scratch my head. If a simple array looks like that to be fully reactive, what kind of tricks are you going to need to pull to handle nontrivial real world deeply nested state?
Svelte is becoming the thing that I initially liked about Angular 1 and then when I learned React I started hating: it is too much "magic" and transpiler dependent code. The thing that all React/Solid is doing is so much straightforward and clear for me: it's pure javascript. No magic, just functions and variables.
And HTML in the middle of the code. Oh, except is not HTML. It's a weird XML dialect that is not HTML-compatible. And it mixes JS and this weird XML syntax in a file named... ".js". But that is clearly not JavaScript. But yeah, sure, JSX is just pure JavaScript.
react is not even close to "pure javascript". you should try building something from scratch without a framework. it's not a fun experience. with javascript, you need a little magic to make up for the shortcomings of the language.
I don't really like where svelte is going into... but for my luck idgaf about svelte since i dont use it at all and im not really interested, but i really liked how amazing simply it was for making alot of stuff for the development and now theyre merging some parts of react-ish and vue-ish together and it doesnt feel right... another tool being killed by the authors? we will see...
@@jherr why do you use that example? It is very bad thing to show how Svelte improves with runes. Removing that you show the potential of runes and the solution for an old problem since Svelte 3.
@@SilvestreVivo The section where I showed that was in a discussion about how a derived statement can only be on a single line and this was showing how it was compiled (which helps understand that limitation) and then showing how the compiler compiles a valid statement. I also went into the compiler output later because it's not clear if the intention is to run the transpiler on library code, and understanding the underpinnings of the reactive system and what is actually being called when you use runes, will allow potential library authors to create code that still uses the reactive state management mechanism.
Svelte 5 is about to be released. Most of the criticisms no longer apply. For example, the part about the array signals. Such videos based on an early beta should be a bit more neutral. But even though I respect Jack Herrington, he is not unbiased.
Gosh. I've never used Svelte and seeing this code I'm having a hard time understanding why it's getting such glowing reviews. Is it just good at really basic state management and that's what most of websites needs? Looks like you need to go to the documentation for any complex usecase. Woof.
From your experience, how does it compare to react? I cant make clear judgement yet, as I barely touched svelte yet, and unlike most people who praise it, so far I found react to be more developer friendly experience.
Svelte is ok, but it's more frustration than fun once you realize very few support it, whereas React and NextJS get far more love from developers. Svelte has lost most of its advantages to NextJS which has smoked the competition.
Except react hooks don't have fine grained reactivity, execute the whole thing multiple times and need to be memoized, on top of all the restrictions on placement inside components.
The array syntax with getters and setters is horrendous
Right?! I cannot use that crap 🤦🏻♂️
Svelte is definitely going to need some higher-order functions to handle nested state. Without it, for anything more complex than a counter, state management is very heavy on the boilerplate.
To be fair, they probably plan to do that already - or even to solve the underlying issues that require the boilerplate directly.
@@EpKjelltzer not necessarily. they could just give the primitives and let the community figure out how to do nested state, like preact.
Dont say those words bro. Keep the ambience clean please
Yeah, I agree. A day or two after you posted this comment, Rich made another video addressing this concern. He basically explored how other frameworks handle it and mentioned that the Svelte team will likely include some higher-order function(s) to help with this before the release.
Seems like an edge case though. If we're building something like a spreadsheet, better to just use the native DOM api and create a non-framework specific utility.
I'm curious how these code examples compare with Vue, which I've been thinking about more since reactivity has become a hot topic. I love the way this whole video was set up, not being afraid to make syntactic mistakes, and using those mistakes as a segway into the correct syntax. Genius tutorial.
I really liked the Svelte update; it simplifies a lot of things. However, when it comes to arrays and objects, it fell a bit short. I wish they would pay more attention to this aspect, especially since many times apps will consume JSON APIs that return arrays of objects, and having to use a "runify" boilerplate function is not very convenient.
reconcile in solid is a thing of pure beauty
And they did listen to feedback
Svelte 5 runes Svelte experience. Sad.
So this is becoming vue 3...Why would I use svelte over vue 3? And dont say the compiler, vue will implement something similar with vapor mode.
My thoughts exactly. Vue has already a bigger community. So it kinda kills svelte’s purpose :/ I mean, svelte is still more intuitive in my opinion though
Best explanation of Svelte Runes i have seen on the internet till now. Simply Amazing🔥💯
This was a brilliant explanation and helped me to see the benefits of runes. I would love to see more Svelte content.
I don’t think the issue with the $derived was that it’s multiple lines, but that it can only take a single expression - an if statement in JS is a statement, not an expression. So your function version, a ternary, etc. would work.
Exactly. Just like computer in all other frameworks.
Goes to show if ought to have been an expression though (like in Kotlin).
Having literally never coded in svelte I actually can’t imagine what it would’ve looked like before this ( I’m so used to react and the four concepts feel very “react like” )
It's really just an established pattern for a reactive primitive called signals. React doesn't actually have this feature today, which is why you have to define a dependency array in useEffect, memoize what you can, and worry about render cycles. I get what you're saying though. You're right that the terminology _is_ reminiscent of react, but that naming comes from the reactive paradigm that predates react.
Oh of course, thanks for clarifying. I actually started development when RxJS was kind of the big thing - didn't really capture its difference / importance from React as a wee lad and just learned to use React anyways. @@kylerjohnson988
Funny that you think it's "react like" considering react doesn't have fine grained reactivity. It's actually inspired by Solidjs signals, which in turn look (superficially) like react, but actually work as you'd expect, instead of doing everything wrong like react does.
By saying "doing everything wrong", are you largely attributing that fault to unnecessary re-renders?@@pxkqd
@@S.Rank_react_devnot just that, but they way they re-render an entire DOM tree to change one tiny part. No fine grained reactivity at all.
I haven't used Svelte extensively, but I like the explicitness of this because it's clear what each of these does. Also, the fact that it's not something that works only in component files, but it can work in other JS/TS files that are not single file components is great for abstracting logic. Although I do hope they come up with a solution for arrays/objects because having to use a custom function for that seems like it's not "the Svelte way" to do things.
To me personally definitely better compared to magic props by using "export" keyword, using "$:" label for derived state etc.
The video quality and production has improved soooo much in so little time. Great work!
I tried to come up with a VDOM-killer + super-reactive compiler myself. Props to Rich Harris for getting the VDOM part right. However, the reactivity DX is a much harder problem (thats why we have: PropDrilling+Memo,Context,RTK,Jotai,Valtio,Zustand,Mobx,Recoil,Zedux,LegendState). He also recently forked JS so he probably realizes that deep changes are needed to 'solve reactivity'... Using a well-known approach of signals is sort of giving up on finding the "Epic Reactivity Through Compiler Magic".
Yep definitely seems like the magic is getting beaten out of svelte with a stick
Svelte: not sure if it wants to be Vue or Solid … 😅
It’s vue 😂
This feels like a not as good version of vue compose API. Example runify(array) hack in svelte vs reactive(array) non hack in vue.
@Jack it's time for observables as native feature in Javascript, frontend frameworks gets crazy with observability, especially developers, which the same one, hate rxjs, and I don't see any difference here, besides it's better encapsulated...
Thanks for making runes usage more concrete through a simple but not too much complex example 🎉
I know svelte very well. I don't understand how a lot of these are necessary? $state doesn't seem like it does anything, does it save internally to the component?
Yes. It attaches state to that instance of that component.
Thank god I went back to using server side full stack frameworks and got off the frontend js craze, they just keep reinventing the same thing and getting nowhere. Htmx is still the most unique to come out recently as it completely changes how state is handled.
what is your fav stack?
@@madipta right now it’s django since you can accomplish a lot in less time and it has sooo many things you’d want in a web framework out of the box. Admin dashboard and auto migrating databases are some of my favorite parts
Htmx isnt new its like 20 years old
@@xyangst the concept isn’t new, true but it’s implemented quite well and removes entire classes of issues with state between frontend and backend by its core architecture which is not like most frontend where they try the most to keep the state in two places.
So true! I've been trying to move away from this crazy frontend world for a while and shift towards backend development with C# .Net. I started with JavaScript in 2007 and had to deal with this madness for over 15 years. I always stayed strong, but it's starting to feel too crazy for me, especially when you keep learning the same stuff over and over again for 15 years and just end up producing HTML. It feels like a waste of life. And then there are all these JavaScript "fans" who don't know anything! It's unbearable. Frontend development has just become a madhouse.
Feels very similar to signals in angular. Not sure if that's an insult or compliment.
A compliment to angular at least
I was happy with "let" actually.. and your explanation of runes made me like this syntax a bit more, but the array get/set is aweful. :/
if you watch Rich Harris video over runes, he says the team took what they liked in other software and used this to improve Svelte. This was done from feed back from users, where they found situations that became cumbersome to write, Svelte team has tried to address these with runes
They opened the pandora's box with this change, basically saying old Svelte was wrong. Now it makes you think what if they say runes were wrong too. You can't just say you were fundamentally wrong and expect people to be okay with it.
Frameworks/libraries evolve, learn from their current work and that's a good thing. If they only ever stuck to their original ideas and never improved upon them, Svelte wouldn't be what it is today. Rich Harris talks about this and how many things before Svelte 3 just weren't that great so they kinda reworked a lot of the things to make Svelte what it is today.
Technically the old stuff still stands they just introduce new ways for the compiler to see reactivity from the non svelte file
I disagree with saying it's wrong. Svelte 3 came out in 2019 before any of this signals stuff was propagated through the whole JS sphere. Frameworks can change over time here's nothing wrong with that.
More than that, they’re acknowledging that Vue was right all along! Really bad press
@@danvilela Solidjs began the new wave of the signals trend way before vue, and Rich has said in his video about runes that they had solid in mInd, not vue btw :)
Hm... This implementation of runify seems to miss that a dev might want to mutate runified arrays by adding items? But going down this path leads to something like lodash/immer/ramda/rx/lenses/optics for runified things.
"Every sufficiently complex frontend built with svelte 5 contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of rune-optics".
Lisp! ❤
I don’t understand why these changes are needed. I am already doing all of this without Svelte 5, and I think this is just what I tried getting away from when switching to Svelte
So Svelte is getting matured. But how can i share this logics to other components? Like custom hooks (with useState, useEffect, usememo, useQuery, useAtom, etc...) in React?
Extract the non framework specific business logic into a shared library then import and wrap in hooks/runes as required.
Excellent video
This gives me some java vibes that I don't like at all. Is there a reason for not implementing $state for arrays and objets? It's taking away a lot of the simplicity and elegance of the original svelte.
hexing-the-technical-interview by aphyr plays into the mythology
Just const names = runify(['John', 'Sarrah', 'Rich']) works, no need for the name props
They got me just for the name haha
I like the runes name, but LOTR reference it’s stupid
make an interview with Rich Harris. That be nice
I'm not that familiar with svelte, but this syntax looks like it has a lot of footguns that kill reactivity
Example?
You have no idea
@@TitoMittothe array example made me really scratch my head. If a simple array looks like that to be fully reactive, what kind of tricks are you going to need to pull to handle nontrivial real world deeply nested state?
@@aster_jykMaybe get familiar with svelte before making assumptions :)
The whole idea of this is to have fine grained reactivity
It's tough for me to pick up svelte as most people are still hiring and using nextjs
Svelte is becoming the thing that I initially liked about Angular 1 and then when I learned React I started hating: it is too much "magic" and transpiler dependent code. The thing that all React/Solid is doing is so much straightforward and clear for me: it's pure javascript. No magic, just functions and variables.
And HTML in the middle of the code. Oh, except is not HTML. It's a weird XML dialect that is not HTML-compatible. And it mixes JS and this weird XML syntax in a file named... ".js". But that is clearly not JavaScript. But yeah, sure, JSX is just pure JavaScript.
@@isdeonf ok, dollar sign and {template} syntax
react is not even close to "pure javascript". you should try building something from scratch without a framework. it's not a fun experience. with javascript, you need a little magic to make up for the shortcomings of the language.
I don't really like where svelte is going into... but for my luck idgaf about svelte since i dont use it at all and im not really interested, but i really liked how amazing simply it was for making alot of stuff for the development and now theyre merging some parts of react-ish and vue-ish together and it doesnt feel right... another tool being killed by the authors? we will see...
You don't need to pass count as argument in the $derive(). This is one of the improvements with runes!!
I’m not saying you do. If you use the rune it turns that code into an invocation of computed with a function that calls .get on count.
@@jherr why do you use that example? It is very bad thing to show how Svelte improves with runes. Removing that you show the potential of runes and the solution for an old problem since Svelte 3.
@@SilvestreVivo The section where I showed that was in a discussion about how a derived statement can only be on a single line and this was showing how it was compiled (which helps understand that limitation) and then showing how the compiler compiles a valid statement.
I also went into the compiler output later because it's not clear if the intention is to run the transpiler on library code, and understanding the underpinnings of the reactive system and what is actually being called when you use runes, will allow potential library authors to create code that still uses the reactive state management mechanism.
How was did done before?
Runes are awesome, haven't used them extensively but can already see their awesomeness
Svelte 5 is about to be released. Most of the criticisms no longer apply. For example, the part about the array signals. Such videos based on an early beta should be a bit more neutral. But even though I respect Jack Herrington, he is not unbiased.
Gosh. I've never used Svelte and seeing this code I'm having a hard time understanding why it's getting such glowing reviews. Is it just good at really basic state management and that's what most of websites needs? Looks like you need to go to the documentation for any complex usecase. Woof.
I mean you need to go the docs for anything complex?
I just care about the performance improvements.
Somes says "oh no react" others "oh no vue" "solid" come on!
I've been writing banking APIs for the last 3 years but I see Jack Herrington, I click. I see Runes? I click faster.
From your experience, how does it compare to react? I cant make clear judgement yet, as I barely touched svelte yet, and unlike most people who praise it, so far I found react to be more developer friendly experience.
Svelte is ok, but it's more frustration than fun once you realize very few support it, whereas React and NextJS get far more love from developers. Svelte has lost most of its advantages to NextJS which has smoked the competition.
At 3:21 that doesn't seem to be the correct JS code. Does Svelte have its own syntax or I'm missing something here?
Triples makes it safe. Triples is best.
Runes: svelte hooks
What are hooks?
@TitoMitto react's runes
Except react hooks don't have fine grained reactivity, execute the whole thing multiple times and need to be memoized, on top of all the restrictions on placement inside components.
Runes as eldenring
FIRST!
pakistnai?
@@techinsider3611 nope
Awful
This is definitely the worst Svelte 5 example on RUclips. You don't have any idea how this works!!!
Awful.
Lord of the rings reference? 🤦🏻♂️ I thought it would be some cool vikings stuff 😕
Svelte 6 - const [$state, $setState] = $useState()
That clever quip was..."borrowed"....from @tomich20's comment on Matija's Joy of Code vid, eh?
🤣