Svelte 5 Is A Triumph
ฝัง
- เผยแพร่เมื่อ 11 ก.ค. 2024
- This video is a comparison of the changes between Svelte 4 and Svelte 5.
🔴 Patreon: / joyofcode
𝕏 Twitter: / joyofcodedev
💬 Discord: / discord
🔥 Uses: www.joyofcode.xyz/uses
🔗 Examples: component-party.dev/?f=svelte...
🔗 Svelte 5 Docs: svelte-5-preview.vercel.app/d...
🔗 Is Svelte 5 Ready Yet?: svelte-5-preview.vercel.app/s...
🔗 Svelte Summit: www.sveltesummit.com/2024/spring
🔖 Timestamps
0:00 Intro
0:22 Reactivity
2:26 Computed State
3:22 Effects
4:18 Abstracting Logic
8:46 Templating
9:01 Events
9:53 Referencing The DOM
10:44 Conditionals
11:14 Lifecycle
12:14 Props
13:02 Sending Events
14:04 Slots
15:13 Context
17:06 Binding Form Input Values
17:52 Initializing Svelte
18:34 Fetching Data
21:03 SvelteKit
21:17 When Is Svelte 5 Going To Be Released?
21:53 Outro
#joyofcode #sveltekit #svelte
It seems that Svelte is becoming a lot less...well, svelte.
At the first glance - maybe. But it still has a lot of compiled syntax which we all love in Svelte + new syntax is definitely more robust and allows for big performance and DX improvements
@@DEVDerr I don't think I see a single person saying that it improves DX.
@@CyrilCommando Currently im migrating most of my Svelte < 5 projects to v5. Yes, it can be said that it is a little more strange to do things. But now that I've worked with v5 for a couple of months. I can say with complete confidence that the DX has been improved. Yes I know, it's weird to say this with how beautiful Svelte was before this change. But believe me. Optimization, control and flexibility have taken 20 steps forward compared to the previous version
Svelte 5 is basically an admission that S4 was never really a compiler that understood your code but just a regex parser or some similarly stupid processing logic. S5 is one step forward in flexibility and three steps back in usability.
Well put
I just don't understand. I have a massive project where I have literally zero issues with the current Svelte, so I'm not sure what problems are being solved by doing a complete pivot with the design like this. I hope I'm wrong about this because I switched from React to Svelte to get away from this paradigm.
Try it and if you hate it I'm going to eat my shoe.
@@JoyofCodeDevbonkers I'm going bald over this 😂
They literally fixed Svelte with this update you should look more into reactivity.
Yeah I don't get it either, I dropped vue for svelte for no other reason then to get away from the endless $ref statements, now it seems as to have gone full circle back to what all the other frameworks use.
@@JoyofCodeDev that's the thing. On a big project, making a switch is prohibitively expensive. There are a lot of braking changes and as far as I understand you either use runes or new syntax but not both in the same project. I wouldn't update to V5 and would just stick with V4 if that's the case.
Im sorry i dont really see it yet. There were never any problems with onMount and onDestory, they were well named and really intuitive, the $effect is not for me. The context example is really not much different, the only difference is really writable vs $state, and then mixed in some getters and setters....
main thing is performance
I just started learning Svelte and looks like 5 is what makes me sold. already i can tell you it improves my experience. just wish it would be released soon so we can ship production
@@jeffreysmith9837 simplicity > performance , it's already much better than many other frameworks performance wise.
This is what I expect when Runes is release, the comparison between the old version. Thank you for making it crystal clear!
Thank you for the breakdown! It confirms that I don't like Svelte 5, haha. Svelte was SIMPLE, with an understandable syntax, now it becomes obscure.
Exactly!! I left away ReactJS so long time ago because Svelte... Now, I'm thinking to get back again! What a sadnesss thing!
What's the point of this? You could have used writable() and derived() in components before, and they do the same as $state() without muddying the waters with implicit getters and setters.
Getters and setters are a trap, they fool us into thinking we're simply accessing memory, but instead they're running a new function adding more overhead.
Creating a new object for every piece of state to avoid defining getters/setters is also not a good solution when GC is already a problem in JS, not to mention deep reactivity implies these objects will have to be iterated for changes, instead of a single primitive.
You won't need to use spread and cloning to get your data to update. Just modify a property of an object and Bam! the UI updates with Runes. Much nicer and more clear about what is reactive too.
The thing is functions can be inlined by the JIT, implementing similar things in the svelte compiler is not feasible.
onMount and onDestroy literally express what they do, and now instead there is a cryptic "effect".
react had the same life cycle methods, and went to useEffect.
Same happening to svelte 😅
It’s not “cryptic”, Learn To Code
i have the same thinking like you. onMount and onDestroy easy understanding than effect return. Maybe svelte not for beginer like me anymore
@@ivan.jeremic it is cryptic, it doesn't convey when it happens, an effect can happen at any time, or not at all, or anytime there's any changes, or keep happening on intervals, it's not semantically clear
effect has been a react staple term since day 1
This seems like more work for the same results imo. Writables are just too easy to work with instead of having to write your own getters and setters. Please correct me if i'm wrong
I think you skipped the part where I show that you don't.
You don't, you just have to create a new object for every piece of state, right? As if GC in JS isn't already a huge problem for performance at scale.@@JoyofCodeDev
@@laztheripperand developers still overusing spread syntax with const, these are the problems of GC in javascript and not the framework.
@@daleryanaldover6545 svelte use to mean DX. A good framework can encourage developers to write better code, and svelte use to do this.
Svelte stayed for: html is already doing stuff, no need to reinvent the wheel in JS.
Encourage plain css, vanilla html, browser api …
Now we are slowly drifting towards react syntax, but no virtual dom.
Before they will figure this was a mistake, is going to take at least a year, this translates into more hard to maintain react projects …
I'm sorry, but I barely use spread syntax, unless I actually need to make a copy of an object/array. You can .push() and then var = var; and it does the exact same without the overhead. And yes, it is in large part the fault of frameworks that encourage creating so many objects that later need to be GC'd. Same goes with array method abuse, which is a lot harder to avoid in react for example.@@daleryanaldover6545
what was wrong with on:click that they deleted the two dots and made it onclick? a very unnecessary move.
I was thinking the same, you could already pass call back functions as props, now we lose the pipe operator and the clarity that it's a native event attribute 🙄
I agree, it makes it easier to spot across other attributes, also syntax highlights make them stand out. what a downgrade
Children is now unique? What about named slots? Before it was much simpler.
you still have them; they are called snippets
I just started converting my old components over. I actually found it easy easier with snippets. You can set fallbacks, named "slots" with snippets, but you also get a nice TS experience with them.
@@specialdoom9116 understand diffrence between these two first.
Yes I don't understand why he says it's so much better, then it's nothing but more verbose.
Hey, How's and why is render() better than slots? No reason was given, if anything it looks worse since it involves more code.
I hoped there would be a snippets example so I forgot about it: svelte-5-preview.vercel.app/docs/snippets.
Killer feature - I believe this probably needs a seperate video. Great job on this one though❤@@JoyofCodeDev
It's more explicit that children elements are a prop, and lets you check their existence children and conditionally render, like in the example. I believe before using you couldn't say {#if } etc.
@@sunstryderyou can have slot fallbacks tho
@yder it is actually possible with slots, you only need to do something like the following:
{#if $$slots.default}
My element
{/if}
I hope I’m missing something here, because to me this doesn’t look like an improvement. It’s much more verbose and... what’s the trade-off?
I step beside React because I found simplicity on Svelte. But now, I am not sure if now Svelte are complicating the things like others JS libraries. I loved svelte because its naturallity with JS, HTML, and CSS..... Now, I am not sure at all!... I feel that I need to break a paradigm.... AGAIN!!!!!!
Brother, trust me. Try it first for a few days/weeks. then you will understand the reason for all these changes. v5 maintains its naturalness, a little more complicated YES but it is practically imperceptible. Give v5 a chance or two and then make your decisions
As a Lead Angular developer who've been using Svelte for creating a landing to our main app I can say that I will miss the old syntax. This is the one thing which is very simple and it was one of the reasons why we chose Svelte for this task. Now I find Angular's approach to deal with signals more convenient than the Svelte's one. It feels more comprehensive as for me.
P.S. And yes, all of this refactoring in near future... Gorgeous.
I'm so tired of the JS ecosystem. 10 years doing this, I haven't used the same techniques and tools on any project. I really thought Svelte was breaking the cycle.
Is not the change that bothers me, but idiotic change.
Signals were invented invested in 2010 by Knockout.js team
React tryied everything else.
Angular went with rxjs.
Now both are moving into signals.
Signals are great.
But the new syntax in svelte is just bad.
It will lead into verbose, matrioska code
Take {@render children()} for example. Now children expect some props…
With this syntax, people will be encouraged to write matrioska code.
was like: “ok, I need to stop adding code here and create a new file”.
Good and bad decisions are based on previous ones.
Good decisions, attracts good decisions.
Bad decisions, attracts bad decisions.
I hope when svelte 5 releases you'll go over a few more of these examples in depth like some of your other videos for those of us who aren't JS pros and more hobbyists... that's always my biggest concern when these packages get major changes
look how they massacred my boy
I'd like to see a practical example of runes in action. Say, a shopping cart or something, rather than just a counter.
I used Svelte 4 for a lot of projects, the last one is a custom CRM for an international logistic company, so I'm talking as an experienced developer not a youtube tutorial maker.
I don't like Svelte 5, sad because I'm a huge fan of Svelte (the old good one) besides I script React, Vue and Alpine, but Svelte (and recently Alpine) are really enjoyable to code, at least for me.
Maybe my first reaction about the new version is visceral, but in contrast with the first time I met Svelte and instantly started to play with it, this new version makes me apathic. And the changes are massive and some of them unnecessary -once again, it's my personal opinion-, just figuring upgrade my last project (some thousands of codelines) is disturbing.
The old Svelte had its own personality, that's why a lot of developers loved him but this one is lost pretending to be at times React and others Vue.
onMount and onDestroy much clearer in meaning and use. Why make them both became $effect?
$effect is strictly more powerful. It subsumes onMount and onDestroy, and if the callback passed to $effect references state and/or reactive variables, it will fire when the latter change.
@@jub0bs that's my point. When look in the $effect you have to reason it but with onMount and onDestroy you have since it only have one purepose. I think simple is better powerfull in this case
@@tungly1558 Readability is a legitimate concern, but nothing prevents you from declaring functions with clarifying names:
function onMount() {
console.log("onMount");
return onDestroy;
}
function onDestroy() {
console.log("onDestroy");
}
$effect(onMount);
(7:03) I've been messing with making classes reactive in vue 3 and i've actually made it, but the thing is, if we are going to make watch-effects on an instance of a class that accepts reactive dependencies, there will be an infinite call.
Is there some specific handling in svelte to this or is example presented just to show possibilities?
(i don't know svelte at all, just peering and familiarizing myself with it)
9:30 I'm going to miss the old syntax, but it seems like it has a ton of advantages!
definitly
Same, I love on:click, is clear because you have the “on” the “click” not just onclick 🤣
@@diegoulloaobut this is much more leaning towards standard syntax since onclick is pretty much the right property in javascript.
One more year and you all will fall in love with React😂
@@daleryanaldover6545 this is not "vanilla Javascript land" boy, this is full fledged framework thingimagiggs, we don't have to constrain ourselves to vanilla miseries, this change is a regression
9:40 it think this also makes the client side code and compiler code simpler, i believe, before we had to have a code that handles "on:" directive, but its just the field name on the element now.
so putting a signal of a function there will just keep updating the element's onclick field when signal changes, so now you can have signal of a function as listener. and also removed the code for "on:" directive from everywhere.
In 2024 Svelte will gain 5 more job openings, lets gooo
SVELTE MENTIONED
the event dispatcher example is not equivalent, because the dispatcher allows to define the logic inside the child, that is, you can extend the clickYes and clickNo functions to do other stuff beyond just dispatching (this is what's powerful about this concept), the alternative doesn't allow that
THIS, I've been working on a big project in production with micro frontends using Svelte/Kit, did some React in the past and the moronic shoehorning of the Flux pattern down my throat is downright disgusting. It's creating the need for the HoC bullshit all over again, untiil now I could treat components as classes and do mixins at the dispatched event consumer which composed nicely segregating base behaviour with added behaviour as I deemed it, and I could Type my dispatchers nicely.
Just wrap the handler prop in another function in the child...
Call wrapper, which does whatever logic, then calls the passed function
Hi Joy, sorry if this comment is a bit out of context, but I had a project in mind but I'm having particular problems, just to make you understand, I would love to replicate your website, not all of it obviously, but the "style", I'd like to make a sort of documentation for the italian community, since I'm Italian, hence the bad english, but the point is that I followed your markdown + sveltekit tutorial but it's not turning out like I envisioned, so I was wondering if you could make a video explaining how you've built your website,specifically the blogs section, that's all, thank you for all your videos, they're really helping me a lot 😊
Many of the improvements presented make me smile. I've been working with React for quite a while and I definitely recognize some of the terms and patterns borrowed from it. It's not that the new features don't make sense. I have absolutely no problem learning more complex frameworks when it comes to performance and flexibility. The problem is that Svelte sold simplicity and now they're falling into the same zone as the competition. They're slowly moving away from what made them popular in the first place.
This looks like the reactification of svelte ... unfortunate to see
Agree! Huge fan of Svelte from the very beginning, and now it's like if I could hear the React guys saying "I told you. You can't skip the state[ ] syntax". Oh boy, they were right! :(
It's fine if you don't like it but you should learn how the tools you use work because If you knew how React works compared to other frameworks you would know how ridiculous that sounds.
@@JoyofCodeDev hahaha. Ok 🙌
Maybe you guys should realize that writing Javascript instead of $: is the correct way and other people where right, just learn javascript and stop complaining about React, this update is not a “Reactification” this is a “Javascriptization” my friend
@@ivan.jeremicyet “$:” is JavaScript , is called “label”.
This is not an update; this is a downgrade. As someone who picked Svelte for its simplicity, I’ve been developing really good websites without even considering these issues. The simplicity of Svelte always allowed me to find a way to achieve my goals. With this update, it feels like I have to change my mental model of thinking, and aesthetically, it’s not like Svelte. It’s sad to see they decided to take this path. I wonder who got into Rick’s mind. They forgot why we chose Svelte in the first place: because we hate coding, but we love building stuff.
I was gonna say same things. you read my mind.
Hate it. I was fine with the old syntax, it was way more concise.
Now its going to be depricated. I'll delay switching as long as possible.
Why do js frameworks have to reinvent themselves every few years? Why fix svelte, it wasn't broken.
You would be surprised if you tried it.
Agree. Hope we avoid "the python way" with v2.7 / v3.x
@@JoyofCodeDevdude anyone can get used to anything, this is objectively more verbose, for little benefit
@@JoyofCodeDev people say that when react comes out after angular. Now everybody hates react. people who think the latest way is the right way and the best way to do thing only find themself an idiot after sometime.
@@JoyofCodeDev Nobody is going to be surpised.. because before I saw and we surprised. but now if we saw, we hate it.
With runes svelte loses the main advantage - super concise syntax. How is this different from Vue now?
It doesn't suck. /s
Did you watch the video?
@@JoyofCodeDevno but really, how's it any different from Vue now?
@@anarcusvue this vue that, vue SFC came from svelte and signals from solid.
@@daleryanaldover6545 sure, taking inspiration is great, but that doesn't answer the question of why would Svelte be different from Vue now
Since so many people are complaining about the new syntax, cant the svelte team hide this new syntax under the hood? let name = "John" can use signals, but under the hood.
yeah.. its my actual question.. even their new syntax hide the signal. then why older syntax can't hide.
awesome and simple?! ... it's looks the opposite, miss the old syntax. God please don't let our Svelte we love to turn into "react-like" monster
This is simple, these are just javascript functions so you are telling me it is hard for you to write javascript?
@@ivan.jeremic thnx for your feedback. It doesn't matter how name it, but it looks more verbose and complex compare to Svelte4. Javascript might look more or less complex, it depends how we use it. Syntax simplicity of Svelte3/4 is a big deal, it is one of the key features for a wider adoption.
@@ivan.jeremic I think most of those comments are just people that did not actually tried it. I was kind of replused by it until I migrated a "complex" project, now I'm in love
They are taking away the "Magic" and adding the same kind of hooks as other frameworks. Now it turns out "everything" in Svelte 3 and 4 was bad/wrong But they sold it to us like it was wonderful, and now they are moving away.
11:30 I though onMount did more, are runes targeted to execution only in browser? Is onMount going to dissapear or what isgoing to be his purpouse?
It's replaced by `$effect` but yeah I think runes only work in the browser which eliminates a class of problems with SSR.
Wow! Now svelte v5 come closer to react hooks. Congratulations
I think something alike would be better
"let state count = 0";
"const derived double = count * 2";
How is worse than {@render children()} ?
And how do you pass named slots with @render then?
I guess you make diffeerent props and render each one? children is a named slot
@@SRG-Learn-Code How do you pass these props?
I don’t reali like it.
I will give it a try, and if i will not like it, I will just keep V4
Yeahh, render thing is react but worse.
I guess hiring the infernojs guy was a mistake
@@ionutale1950 It's all my fault. Sorry.
14:50 For most cases, I don't think the new `{@render children()}` will be any better or easier than slots, but it does add some flexibility.
We get snippets which we really need. Single file components suck
Since the 'let' keyword is supposed to denote mutability, I think '$state()' is nonsensical in some way. However, in the end, the idea of signals is a better approach (without being the best in my opinion). It could be nice to have : signal name = "john" instead of let name = "john"
I agree
signal name = "john" is not a valid js code
@@arshiagholami7611 I know. It's an example
@@arshiagholami7611 let name = $state("john") is not valid js code either. $state() is only valid to the svelte 5 compiler because they transform it into valid js code. signal name = "john" could be perfectly valid if the svelte team wanted to go that route. They probably went with $state() instead because it looks like a normal JavaScript function so it feels familiar to people
@@sam_sam_sam `signal name = "john"` is not valid js syntax. `let name = $state("john")` is valid js syntax.
so svelte is vue 3 now?
No, it's way better.
@@JoyofCodeDevidk man, feels like vue with extra steps
so when vue ditches virtual dom it'll be svelte?
@@MaxHDeveloping work with both. Svelte is 👑
exactly, looks like just vue with changes
I noticed derived are exemplified with const instead of let. Any reason for this? Looks "uncomfortable" as we tend to understand const as non-changing variables, I would feel more confident and without questioning myself if a derived is a let, that will be changed by someone else.
This makes Svelte much clearer IMO. I've worked on a relatively large project using Svelte 4 and many issues I had around readability and typing issues would be fixed by some of these changes. Also, before it felt too magic for me and that was pretty awkward, now it looks concise, clean and not an odd witchcraft. Also, spreading event listeners is HUGE. What I do miss is a way to do better unit tests.
Thank you so much for your Svelte work, I have learned so much from you!!!
No one will ever convince le children are better than slots. I dont mind the state and derived syntax, but this is a huge setback
was one of the most painful thing to grab for me... The logic is just wacky
can I use runes outside svelte files? for example can I import a function from svelte to be able to define state logic outside svelte files and then import that into a svelte file?
Yes. You just need to name your file ending with .svelte.js or .svelte.ts
yep! if a file ends with .svelte.js it can declare runes. It's the main reason they switched over to it.
@@tabiasgeehuman ohhhh 🙏
I think people loved Svelte for it's super short & easy syntax .. w8 does Svelte just becoming Vue3? 😅
Well I am already using Vue so no need to change 😊
How are named slots going to work in svelte 5?
I hate everything about it, might actually drop svelte
I also don't like how you keep saying "oh it's really great- something something", but you don't provide a reason or a benefit. this all seems like a regression to me
Love the video, and btw what browser are you using?
nvm just realised its brave after rewatching :P
This verbosity proves why React and Vue do what they do to know which variables are reactive and control the global state across the app.
I understand that this new syntax simplifies the Svelte compiler and we can expect better performance, but oh, boy, the dev experience just got ruined :(
Exactly Adrian.
This is exactly my thoughts.
Some are way better, but this $props() kinda sucks, hope we can still declare props with the export syntax
@@figloalds yes, export is explicit, and I think is better.
$props() creates ambiguity
@@ionutale1950 and you add typescript and it looks terrible as well
@@ionutale1950 The props rune is significantly better because it allows us to get rid of the complexity surrounding event dispatchers, it also allows wayyyy easier behaviours around rest props especially spreading props on components and elements. This was a pain in the ass before and makes it way more ergonomic especially for library authors.
hmm so it has evolved into React.......great
I don't hate any of the changes they have done. I hate how you hype up every annoying thing as improvement without any explanations
Cool it’s like Vue now.
This are huge changes to the API, I'll have to rewrite all of my apps and components! Are they backward compatibles?
I hope some translator 4->5 will exist
Yes, they are backward compatible
Yo the on:click|preventDefault is miles superior to this crap new syntax, did not like that change at all
Also dislike the $props() change, it sucks a lot
The old is significantly simpler too
Yesssssssss.
This is exactly what I don’t like.
Also $effect…
Hate it
This crap new syntax is called JavaScript and you should learn it before jumping into frameworks.
@@ivan.jeremic i don't get why you are upsed with me?
also, old syntax was JS as well
@@ivan.jeremic I know JavaScript all too well, I know the syntax and I know destructuring, and it's fucking ugly.
It also loses the ability to have optional props with a default value
@@ionutale1950 it was not it was Svelte language.
IMO there's nothing new here that you wouldn't find in any other framework that came before Svelte. I mean, Svelte's cool and all but... I see no reason why I should stop using something like Vue. There's just no advantage at all on making the switch. This all just looks like everything else we've had to learn before many times but with different syntax. The cycle never ends smh.
13:50 Okay, I see now I'm not going to miss the old syntax of events. And holly molly those props... so clean, so beautiful.
For sure $props is good ! But what is this example ? I mean, who used the eventDispatcher like this in svelte 4 ? You could do the exact same stuff, just passing the functions as props no ? I did at least (Asking for a friend)
@@thehumankinds Yea, the example is misleading. This is not a new feature in Svelte 5, I am often doing the same thing in Svelte 4.
Not to mention that this method of passing around event handlers can get really convoluted with deeply nested / sibling components...
Can we use these new syntax also in sveltekit?
You can with `npm i svelte@next`.
When you say custom stores are not necessary does that mean they will eventually be unsupported? I've been able to do some pretty clever things with custom stores. I'm still transitioning my brain around the new changes, I think it's natural for humans to resist change but from my perspective I will tend to defer to people that have probably used it in a lot more complex ways than I have and have learned where it's pitfalls are.
You have a lot of time because they're going to be deprecated in future versions.
I was asking myself today, like 3 hours ago when will svelte 5 be released as i have a couple of problems that were so hard to implement a solution for in a project im working on and i dont want to invent signals (although i have a library for them that was made sometime ago) hopefully i dont have to wait too much to be able to use them in production
A lot of people already do. 😂
@@JoyofCodeDevwas wondering about it as well, I've migrated kit a while ago. So it's safe to say I can use svelte 5 preview now?
One important thing I think missed in templating is the fact that you can now use typescript in the markup
lol does vercel sponsor this channel now? I like your vids man but how can you show examples and usage of how it’s objectively worse but then just say at the end: ah but it’s not that bad you’ll get used it and it’s just fantastic 😂
🤭🤭🤭🤭
Sniff sniff who’s there? Confirmation bias
Talking to yourself is weird.
switching back to react and next, svelte and sveltekit will die after this update, nice one svelte team!
I predict that this comment will age poorly. 😇
Nice to see Svelte becoming more like Vue 3.
$derived = computed
$state = ref / reactive
$effect = watchEffect
Do you have a video on how svelte compiler works?
i wonder if the LIGHTSWITCH puzzle from the old video is easier in svelte 5
Finally New vidéeo ❤❤❤❤❤❤
Wait do you have tab groups in firefox somehow????
I'm using Brave.
"how awesome is this guys"
What browser using on it ?
Love your videos but have one small hang up. You cover the fundamentals of understanding javascript and I absolutely love that. But when working with Svelte you often say that “it’s just javascript”. But that’s not accurate and is actually misleading because Svelte is presenting functionality, behavior and syntax that does not exist in javascript. I’m not saying that’s bad, but I think since you cover the importance of fundamentally understanding the javascript you write, it’s then equally important to be clear about how Svelte files are not “just javascript”. I think Svelte is great, but people should appreciate and understand when it isn’t javascript, and why that is actually, more often than not, a good thing.
As a vue3 enjoyer i like what im seeing, the dolar sign syntax has a few footguns for non trivial reactivity
Whats next ? Virtual dom?
Where are snippets examples?
I've only recently started using Svelte, so I'm glad this is coming in at this time.
Slots were good... 😢
is sveltekit updated to use theese changes?
You can use it with `npm i svelte@next`.
I can't express how much i'm disappointed with all these changes. Not a single new positive. Alot of syntax substitution for very little seeming benefit. The magic that made Svelte so unique in its domain is now being dissolved in favor of chewy programmatic syntax that seem to be influenced heavily by react devouts. I'm beginning my mourning 😓
Everything becomes react eventually.
You know svelte 4 is not going anywhere right?
@@mursie100 eventually it will. And the nature of the direction of Svelte 5 and its reception will dictate the trajectory for successive versions.
Class transformation seems like magic to me 😅. And callbacks as argument don't sound as web oriented as events.
Snippets are powerfull but slots are a web standard as well, which translate pretty well from a framework to another.
Both events and slots are used in vue for example and are pretty decent choices.
But Svelte is still a pleasure to work with. 💙
It's magic but not magical.
What happened with the outro?
I am more interested in React 19 now after seeing how Svelte 5 is moving away from what made itself special.
I’m excited for these changes. They address all of the pain points you end up encountering when you build anything non-trivial with Svelte.
I agree the older reassignment and quirky syntax in 4 had issues. I use React and Vue more but I really like the Runes syntax and will start using Svelte 5 when it is stable.
Same! I wasn't a fan when they announced it but after updating a project to it I'm sold!
Could anyone who tried this update elaborate on the advantages of $render over slot ? Genuinely asking
@@ReViv4LAs far as i have played with it, there is no advantage. The advantage of Svelte 5 are the Snippets that can be used with @render
@@ReViv4L render isn’t a replacement for slots. They have two different use cases. The Render API allows you to insert a snippet into a section of your view while a slot allows you to project content into the views of other components. Snippets are named pieces of your template that you define that aren’t rendered by default. Like an ng-template if you’re familiar with angular at all.
Svelte 5 looks extremely promising for large and complex applications. I am very excited for the future of Svelte! 🎉
It looks like it's maturing or getting closer to Vue now 😂
I am just learnign js and what the absolute fuck ! How am I not able to just append a value to the end of the list?! Without reinstating the whole list?! HOW AWESOME! I might as well write whole web app in C, JavaScript GOD TIER mhm
I hope you are making a slower tutorial to svelte 5 because this video is simply too fast for me who learned svelte 4 4 month ago :)
This was just a casual look comparing the features, but when it's released I'm going to make more in-depth videos. You don't have to be concerned about relearning everything because most things look the same but are easier. 😄
I love your videos but I agree that you are talking too fast to understand (technically) what you are talking about and follow the rest . I usually have to stop and rewind back several times on some of these or just slow down the play speed. ;) Thank you for your hard work.
7:50 I'm not amused by svelte making getters and setters for me. I'll know they are there and that might be a gateway drug to use Java.
☕️
@@JoyofCodeDev 🍿
@@SRG-Learn-Code 🥸
@@SRG-Learn-Code 🥸
@@FeedTheFreak 🥸
Slot is good
Why are you doing that?
The syntax for dispatching events via prop functions is not new and has always worked. It's just that since Svelte 3 we had two ways of dispatching events, and with Svelte 5 one of them is dropped.
You could always do that sure but now it's easier.
I really like that svelte is moving to signals, they just out perform every other reactivity system and are so simply to understand. But i dont understand the svelte team want to hide the signal logic. Im talking about something like `const count = $state(0)` where count will be an object with a value getter and setter. Just like vue does it. I see that its shorter to omit the .value but if you ever want to use $state inside a factory like in your counter example you need to invent some workarounds (which the svelte team did pretty good, but there still is a learning curve).
I absolutely love svelte and use it since v3 came out, but this is a thing i dont get.
It's because it can be replaced by something else.
I think this is an ergonomics vs clarity compromise. A framework, at the end of the day, is a consensus of conventions and ideas between a large community of people with diverse sensibilities. People seem to generally value visual simplicity over being detailed. I think the lack of clarity that you’re dealing with state (getters/setters/value) is a loss. But if it creates a framework that me and someone that doesn’t think like me can agree on, then we’re on to something.
I love how svelte 5 is basically implementing solidjs' signals.
Not to take anything away from Solid, signals have been around a long time. Knockoutjs made it popular.
And thats amazing. Solid copied the idea of being compiled from Svelte. Svelte took signals from knockout popularized by solid.
14:53: And named slots?
Other than render() I see no problem with Svelte 5. I think it is an upgrade but I'm going to stick with my beloved Vue till they figure things out.
I understand these decisions but they're not for me, Svelte 5 made me go to Vue3, I still use Svelte 4 for quick prototypes and simple projects
I'd suggest use runes only if needed and mostly stick to the old syntax
for example, working with arrays or using custom stores
That's going to be deprecated.
Why?
@@JoyofCodeDev sadge. I hope svelte is going in right direction with these changes
I wouldn't make this video if I didn't love the changes but that doesn't mean you have to and I'm vocal about things I don't like as an ambassador but the Svelte team is always listening and proxied state is one example that solved most problems people had with runes and paves the way for the future.
for reactivity similar little bit to qwik js, nop ?
more advanced state management cases
Literally everything is more verbose and more like react
just use react and be done with it
slow. Heavy
💔 it's evolving ....backwards.
I love when he says "how beautiful is this