Svelte documentation is really great and easy to understand, but man. It's even better when i watch your videos, they're even better than the Svelte docs. From what i learned, slots are easy for easy and simple things, but get really mind bending when things start to get complex. Snippets on the other hand are easy to code in most of the situations i can think of.
Thanks for sharing 🙌 I haven’t worked too closely with Svelte5, but my general impression of it is that it seems more complex than Svelte4. I think this is really just a reflection of how Svelte wants to solve more complex problems, and trying to make inherently complicated problems simple doesn’t come without compromises. For example, a noticeable friction point with Svelte4 is that you had to be aware of how reactivity could be denoted in multiple ways - stores with dollar signs, reactive labels, and local component variables. It’s easy enough to distinguish and organize in small projects, but it personally made organization and separation of concerns much more complex in large projects. e.g. should I bind to a store or a local variable, should I prop drill bindings or just use a shared store, should I use flux instead of binding altogether, etc? Runes addressed the problem above very elegantly because it effectively answered the questions above with “it can be reactive if it’s $state.” I think many viewed it as a “useState” equivalent without understanding the problems that arose from the originally “simpler” model of reactivity.
I have not watch this video yet, but gonna put thumbs up, just because I know how good your content is. I kind of want to rename it from Joy of Code to Joy of Svelte 😄 Jokes aside, thank you!
Actually the slots refactor was quite mind-bending to me. So instead of using the let:row, you know create snippets in the parent, and render the snippets in the previously slot component... We still need to rely on IDE hints to know which inner snippets _should_ be defined when consuming the component, and what happens when they're not? Will {@render row(item)} give a type error / crash if not defined? 🤔
No offense to the people in this comment section but I don't think they ship svelte with any level of complexity if they think this is unnecessary. is great but these changes are a huge help for defining edge case render scenarios (that currently look gross and anti-pattern). This just another tool in the toolbox that all of your favourite component/design library creators will love. The best part is that it's opt-in. If you don't want snippets you can just ignore them :D
Exactly! I don't know what these guys are waffling about, as you said it's literally an opt-in feature. They can simply ignore it if they don't want to use it
I have used svelte 5 fulltime for the past 6 months, snippets sucks ass, I avoid them like the plauge. The Svelte community has just turned into a massive cope with Svelte 5. Svelte 5's reactivity model is much better than Svelte 4, but the syntax just sucks balls
I ship lots of Svelte, much more complex than todos and counters -- and Svelte 5 is a step backwards with runes. It is antithetical to why people would pickup Svelte in the first place. The reasons and advantages you got from using Svelte over something like React/Vue have all but disappeared. At this point, why are you not just using React? Bunch of boilerplate, same concepts/mechanisms for props and reactivity, and Svelte's community and ecosystem are much smaller. JSX still sucks but then you can use Vue. All of these things are NOT opt-in, and the "old ways" will become older and older to the point where they are obsolete in Svelte 6.
@@NickPoulos true, i get why you might prefer Svelte 4 if you prefer the Vue method of doing things. My main problem with Svelte 4 is readability and onboarding at scale. I like the route they've taken of clearly defining declarations, which makes code review and test writing 100% easier for me. It's also reduced a lot of my component code which I'm happy about.
Honestly. This is great. Slots are cool, we can say easy, but this is even better. I would like to see projects that people built with svelte who are not excited about svelte 5 / runes, especially the - you didnt have to learn svelte, now you do crowd. Wtf... You had to learn svelte when you eent beyond simple counter example. I do aswell have some "isues" with new APIs, but remember, you can still use the old stuff with svelte 5
IMHO Svelte is losing the “it just feels natural” feeling that you got, for example, when using I was hoping this video to change my mind but it just made me more confident of my stance in favor of Svelte 4. Svelte 5 is Vue. Might make more sense, but you need to put more boilerplate and concepts that just make it less fun to work with
curious how is `` more natural than `{@render children()}`? not only do you live in the age of autocomplete but the upside is more than worth a couple of extra characters - the more people use Svelte and provide feedback makes it easier to know what to focus on and improve
@@JoyofCodeDev is simpler because it just looks like an html element. Like put this here and then something renders. {@render children()} makes it more ambiguous because what now you have to understand what @render does, when it does it, and what children() does, when it gets called, if it updates dynamically, etc. Before it was as if you were placing something there like a or a . Easy to understand. Now it does something. But you don't neceserily know what. You can learn, but before you didn't need to learn. It was intuitive
I see more beginners confused by `` and treating it like a black hole avoiding things like `let` because it's mind-bending but `{@render children()}` is more explicit and I would argue more intuitive if you understand functions
I think the changes are inspired by React. In Svelte 5, using {@render} and {#snippet}, you can pass them as props or treat them just like variables in JavaScript easily. But yeah, they should've kept the native for those people who don't need it.
Do i have to manually type all the props to not get errors when using snippets? Example: type Props = { route: string; children: Snippet; content: Snippet; }
If you were to compare React to Linux, Svelte woud be MacOS - Gets out of your way so you can do your job instead of fixing some niche and random issues. Now it's becoming Windows 11...
I’m an unreal engine programmer. I build the engine from source, with 120GB debug symbols and it’s all just there. it has a DX Ilthat I love and cherish… and Rich Harris is probably the only one in the web domain who, I think, has a similar engine/plugins/game-project mindset which is simply fun and productive to work with. Svelte is Debian. It’s solid, it’s got everything you need, it’s lean as fuck
@davidjacobs7966 I love SFCs, but snippets still have a use when you repeat a pattern within a component. Does it really need to be a whole new component just to avoid repeating myself in the markup? I'd argue there's a decent amount of code repetition when the code gets over-fractured as well.
@@jamesmoynihan948 Moving away doesn't mean worsening the matters. That's a good thing if runes are solving inconsistency issues. But, my theory is, many people, chose Svelte due to simplicity. And let x = 10 is simplicity, and export let y in component is also a simplicity. a question, when talking about larger applications, what number of loc defines "larger application"?
@@JoyofCodeDev if something works well, use it or copy it for your integration. Developers copy from each other and library/framework authors do the same. If it solves problems and provides good abstraction or ergonomics, why not?
@@m_raez I don't think JOC is saying anything that would disagree with you tbh. I agree though. Copy the best things, learn their patterns, improve your own thinking for free essentially?
Hm... I'm not really convinced. Making new components is just good project hygiene tbh. I'll have to test it to see where I have a use case for that. That said, the experience looks great if there's a good use case for them Oh, generic! Now, I see. That's game changing!
I personally dont like snippets I like more the lets put it into its separate component type of stuff. If I use component on multiple places lets put it into /components if I use It only in specific page I put it next to +page.svelte inside _components. The code is so much clearer to read the less lines of code it has. I am that guy who does like if all code lines of a file fits into his view 0 +/-125 lines of code.
This concept seems "alright" to me. I think the problem is that developers loved the allure of a straight-forward framework like Svelte. The problem is, for more complex use cases it wasn't as simple. Now that it's becoming more flexible to accommodate the complex use cases (such as UI libraries), it's losing the appeal of being a "straight-forward" framework.
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
This was crazy. I learned something new every single second.
Svelte documentation is really great and easy to understand, but man. It's even better when i watch your videos, they're even better than the Svelte docs.
From what i learned, slots are easy for easy and simple things, but get really mind bending when things start to get complex.
Snippets on the other hand are easy to code in most of the situations i can think of.
Thanks for sharing 🙌
I haven’t worked too closely with Svelte5, but my general impression of it is that it seems more complex than Svelte4.
I think this is really just a reflection of how Svelte wants to solve more complex problems, and trying to make inherently complicated problems simple doesn’t come without compromises.
For example, a noticeable friction point with Svelte4 is that you had to be aware of how reactivity could be denoted in multiple ways - stores with dollar signs, reactive labels, and local component variables. It’s easy enough to distinguish and organize in small projects, but it personally made organization and separation of concerns much more complex in large projects. e.g. should I bind to a store or a local variable, should I prop drill bindings or just use a shared store, should I use flux instead of binding altogether, etc?
Runes addressed the problem above very elegantly because it effectively answered the questions above with “it can be reactive if it’s $state.” I think many viewed it as a “useState” equivalent without understanding the problems that arose from the originally “simpler” model of reactivity.
This is a big step ahead for Svelte
17:12 sorry WHAT? GENERICS??
I'm in tears, this is amazing, thank you so much Svelte 5
It's also available in Svelte 4
Generics in Vue too 😊
Love snippets! I needed something like this few times already in the past.
I have not watch this video yet, but gonna put thumbs up, just because I know how good your content is. I kind of want to rename it from Joy of Code to Joy of Svelte 😄 Jokes aside, thank you!
Thanks! That was super Easy Peasy Lemon Squeezy 😁
Actually the slots refactor was quite mind-bending to me. So instead of using the let:row, you know create snippets in the parent, and render the snippets in the previously slot component... We still need to rely on IDE hints to know which inner snippets _should_ be defined when consuming the component, and what happens when they're not? Will {@render row(item)} give a type error / crash if not defined? 🤔
No offense to the people in this comment section but I don't think they ship svelte with any level of complexity if they think this is unnecessary. is great but these changes are a huge help for defining edge case render scenarios (that currently look gross and anti-pattern). This just another tool in the toolbox that all of your favourite component/design library creators will love. The best part is that it's opt-in. If you don't want snippets you can just ignore them :D
Exactly! I don't know what these guys are waffling about, as you said it's literally an opt-in feature. They can simply ignore it if they don't want to use it
I have used svelte 5 fulltime for the past 6 months, snippets sucks ass, I avoid them like the plauge. The Svelte community has just turned into a massive cope with Svelte 5. Svelte 5's reactivity model is much better than Svelte 4, but the syntax just sucks balls
I ship lots of Svelte, much more complex than todos and counters -- and Svelte 5 is a step backwards with runes. It is antithetical to why people would pickup Svelte in the first place. The reasons and advantages you got from using Svelte over something like React/Vue have all but disappeared. At this point, why are you not just using React? Bunch of boilerplate, same concepts/mechanisms for props and reactivity, and Svelte's community and ecosystem are much smaller. JSX still sucks but then you can use Vue.
All of these things are NOT opt-in, and the "old ways" will become older and older to the point where they are obsolete in Svelte 6.
@@NickPoulos true, i get why you might prefer Svelte 4 if you prefer the Vue method of doing things. My main problem with Svelte 4 is readability and onboarding at scale. I like the route they've taken of clearly defining declarations, which makes code review and test writing 100% easier for me. It's also reduced a lot of my component code which I'm happy about.
Slot is still used for layouts correct? Where you aren't importing a snippet, just leaving the slot open to children?
LOL Patrick Bateman 😂
You are a genius!
Impressive
super useful, thanks
Amazing.
This just doesn't look like svelte....
@@nathnaelgetachew7379 noob developers always say that. Its very common
🎉🎉🎉 waiting for svelte 5 migration!!!!
Honestly. This is great. Slots are cool, we can say easy, but this is even better. I would like to see projects that people built with svelte who are not excited about svelte 5 / runes, especially the - you didnt have to learn svelte, now you do crowd. Wtf... You had to learn svelte when you eent beyond simple counter example. I do aswell have some "isues" with new APIs, but remember, you can still use the old stuff with svelte 5
Quite clean!
Thank you!
you're welcome 😄
IMHO Svelte is losing the “it just feels natural” feeling that you got, for example, when using
I was hoping this video to change my mind but it just made me more confident of my stance in favor of Svelte 4. Svelte 5 is Vue. Might make more sense, but you need to put more boilerplate and concepts that just make it less fun to work with
curious how is `` more natural than `{@render children()}`? not only do you live in the age of autocomplete but the upside is more than worth a couple of extra characters - the more people use Svelte and provide feedback makes it easier to know what to focus on and improve
@@JoyofCodeDev is simpler because it just looks like an html element.
Like put this here and then something renders.
{@render children()} makes it more ambiguous because what now you have to understand what @render does, when it does it, and what children() does, when it gets called, if it updates dynamically, etc.
Before it was as if you were placing something there like a or a . Easy to understand.
Now it does something. But you don't neceserily know what.
You can learn, but before you didn't need to learn. It was intuitive
I see more beginners confused by `` and treating it like a black hole avoiding things like `let` because it's mind-bending but `{@render children()}` is more explicit and I would argue more intuitive if you understand functions
@@JoyofCodeDev you have a point there. However I wouldn’t know how to do binding using render functions
I think the changes are inspired by React. In Svelte 5, using {@render} and {#snippet}, you can pass them as props or treat them just like variables in JavaScript easily.
But yeah, they should've kept the native for those people who don't need it.
Do i have to manually type all the props to not get errors when using snippets?
Example:
type Props = {
route: string;
children: Snippet;
content: Snippet;
}
you can do `let props = $props()` so TypeScript won't bother you if you don't care about types
If you were to compare React to Linux, Svelte woud be MacOS - Gets out of your way so you can do your job instead of fixing some niche and random issues. Now it's becoming Windows 11...
idk
I’m an unreal engine programmer. I build the engine from source, with 120GB debug symbols and it’s all just there. it has a DX Ilthat I love and cherish… and Rich Harris is probably the only one in the web domain who, I think, has a similar engine/plugins/game-project mindset which is simply fun and productive to work with. Svelte is Debian. It’s solid, it’s got everything you need, it’s lean as fuck
@@sadunozer2241 It was.
I don't understand some devs' arguments against a single component per file. That's supposed to be the essence of component-oriented programming. 😅
the real power is providing your own render function
@davidjacobs7966 I love SFCs, but snippets still have a use when you repeat a pattern within a component. Does it really need to be a whole new component just to avoid repeating myself in the markup? I'd argue there's a decent amount of code repetition when the code gets over-fractured as well.
I might be wrong, but I feel like Svelte is moving away from what it made Svelte 😥
you're wrong 😄
no one holds you back from using the old versions of svelte, if they work for you then use them without hesitations
What specifically do you think is worse or missing? For me, runes and snippets solve a lot of pain points that arise when building a larger app.
@@JoyofCodeDev 😎 😎 you're {#probably right}🤣
@@jamesmoynihan948 Moving away doesn't mean worsening the matters. That's a good thing if runes are solving inconsistency issues.
But, my theory is, many people, chose Svelte due to simplicity. And
let x = 10 is simplicity, and export let y in component is also a simplicity.
a question, when talking about larger applications, what number of loc defines "larger application"?
Is this the solution for layout name slot?
let's see paul allen's snippet
What code editor is this ??
In svelte 5 just the slot-children is different else everything is same as vue 😅
I find this amusing because the future of Vue (Vapor) looks more like Svelte
@@JoyofCodeDev if something works well, use it or copy it for your integration. Developers copy from each other and library/framework authors do the same. If it solves problems and provides good abstraction or ergonomics, why not?
@@m_raez I don't think JOC is saying anything that would disagree with you tbh. I agree though. Copy the best things, learn their patterns, improve your own thinking for free essentially?
everyone wins
You didn't know? React/Vue/Svelte are all just merging into one big ball of the same features with slightly different syntax now!
Coming from react js world i feel like i came out of a cave era
Hm... I'm not really convinced. Making new components is just good project hygiene tbh. I'll have to test it to see where I have a use case for that.
That said, the experience looks great if there's a good use case for them
Oh, generic! Now, I see. That's game changing!
Yeah... I won't be using svelte 5.... It's too weird for me.
so we're 50% there on the way to make react
"That's 'bone.' Unfortunately, it's not a named color in CSS."
Lower case boom 🥹
why have a footer tag in snippet and around the render also one? That's result a footer tag in footer tag..
simple mistake
@@JoyofCodeDev ah, ok, thank you for clarification :)
Lol snippets are awful 😂 sorry
createRawSnippets looks rather similar to Vue's defineComponent to create Components in JS/TS without SFC-files.
one step closer to having a custom renderer 🔥
ezy pezy lemon squezy
5 lemon squeeze so far... my ears are bleeding 😂.. great content though.
🍋
@@JoyofCodeDev thank you for your video i also meant to write 🙌
This isn't what makes Svelte promising.
I personally dont like snippets I like more the lets put it into its separate component type of stuff. If I use component on multiple places lets put it into /components if I use It only in specific page I put it next to +page.svelte inside _components. The code is so much clearer to read the less lines of code it has. I am that guy who does like if all code lines of a file fits into his view 0 +/-125 lines of code.
TIL Svelte 5 supports generics, very cool
it also has native TypeScript support
Yeah this was a surprise. Does this mean i don’t need to define a type prop for my components anymore? 🤯
This concept seems "alright" to me. I think the problem is that developers loved the allure of a straight-forward framework like Svelte. The problem is, for more complex use cases it wasn't as simple. Now that it's becoming more flexible to accommodate the complex use cases (such as UI libraries), it's losing the appeal of being a "straight-forward" framework.
balanced take
Easy peasy lemon squeezy. Please, do not repeat it so many times!
that's going to be easy peasy lemon squeezy
when is ready Svelte 5?
I predict the release at next Svelte Summit 🔮
@@JoyofCodeDev Mission Failed
don't wait until svelte 5, try out the pre-release, it's not going to change a lot
Ugly. If you want to use nested component outside of the component, pull out the component is clear way to reuse.
svelte 5 continues to disapoint me
heyy, why?
@@ok-alarm because snippets suck
@@ok-alarm slot was so much easier. Now I have to do children() and other stuff like that.
The beuty of svelte was it's simplicity.
I think using children() is nicer because you have an unified way to get the child elements in your component in js and html
you can mix them together if you want