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.
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 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.
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.
@@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
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.
@@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
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.
@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 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
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.
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.
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 🙄
As I last checked, with the old dispatch() method, the child component doesn't need to know if the parent component listens to the event or not. With the new callback-as-prop, if the parent component does pass a callback, then the child component calls the callback, error will occur. I have to check if the callback is passed every time I need to call, such a pain in the ass.
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.
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.
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.
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.
@@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.
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
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 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
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
@@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
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....
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
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 :(
@@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.
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
@@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
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.
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.
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...
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 😊
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.
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
@@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
@@anarcus Vue is less hyped at this point. The only reason i used svelte is because it made stupid things stupid simple. Now it doesn't fulfill its original purpose. Great if it's nicer for people who creat libs, but for me svelte lost its main point.
$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);
Agree, Coverting ap from SK4 to 5, had onMount run a function, worked. Now $effect runs function twice as state involved. Easy "fix" to make it run once but why? Remember the days when infinite loops were a rare occasion. Not anymore, with $effect, very easy!
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.
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.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
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 😊
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?
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.
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 😂
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.
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.
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"
@@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
I don’t like nothing about runes I think they are taking away all the beauty of using svelte. All syntax is larger than before, all sentences looks less readable than before… Idk man…
(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)
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
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.
@@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.
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
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?
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 😓
It is true that at first glance some of the innovations look like boilerplate. But with version 5, Svelte is trying to become more attractive for larger projects with multiple developers. And after writing two medium-sized applications with Svelte 5, I can only confirm this. Although there is sometimes more source code, understanding the processes is enormously simplified.
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. 💙
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.
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.
The first example is like the delegation of a value (or an override of `assign` operator), I like this because we can use assign instead of state.set() or something like that. (but to be honest this is like vue so much lol) The biggest trouble I have encountered about `$` label is I can't create a deconstruct declaration like: `$: [left, right] = somefunc`, but if I move declaration out of it, type will not match... One of the most points why I don't like JS is too many nested brackets in it. For functional usage, Kotlin style is much much better than JS in my view. (But It's almost impossible to apply it on dynamic languages, what a pity...) I never thought I would become a conservative one day.
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
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
This is what I expect when Runes is release, the comparison between the old version. Thank you for making it crystal clear!
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.
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.
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!
How is let being reactive $ and or export let anymore understandable?
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.
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
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'm a new developer, I stopped learning React and such becuase your really not learning how to code. Your learning a framework.
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
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 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
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.
I'd like to see a practical example of runes in action. Say, a shopping cart or something, rather than just a counter.
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.
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
As I last checked, with the old dispatch() method, the child component doesn't need to know if the parent component listens to the event or not. With the new callback-as-prop, if the parent component does pass a callback, then the child component calls the callback, error will occur. I have to check if the callback is passed every time I need to call, such a pain in the ass.
I faced an issue where I couldn't preventdefault for scroll wheel with the new syntax due to passive setting.
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.
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.
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.
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.
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
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 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
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.
Whats next ? Virtual dom?
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.
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
@@DEVDerr do we have performance issues to improve something this way? Svelte's strength lies in its simplicity for the developer
In the end, they all become react
Wow! Now svelte v5 come closer to react hooks. Congratulations
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.
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
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
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...
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 😊
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.
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
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.
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.
With runes svelte loses the main advantage - super concise syntax. How is this different from Vue now?
It doesn't suck. /s
@@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
@@anarcus Vue is less hyped at this point. The only reason i used svelte is because it made stupid things stupid simple. Now it doesn't fulfill its original purpose.
Great if it's nicer for people who creat libs, but for me svelte lost its main point.
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);
Agree, Coverting ap from SK4 to 5, had onMount run a function, worked. Now $effect runs function twice as state involved. Easy "fix" to make it run once but why? Remember the days when infinite loops were a rare occasion. Not anymore, with $effect, very easy!
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”.
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
hmm so it has evolved into React.......great
In 2024 Svelte will gain 5 more job openings, lets gooo
SVELTE MENTIONED
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 😊
Cool it’s like Vue now.
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.
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
How are named slots going to work in svelte 5?
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 😂
🤭🤭🤭🤭
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.
Thank you so much for your Svelte work, I have learned so much from you!!!
Nice to see Svelte becoming more like Vue 3.
$derived = computed
$state = ref / reactive
$effect = watchEffect
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.
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.
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
I don’t like nothing about runes I think they are taking away all the beauty of using svelte. All syntax is larger than before, all sentences looks less readable than before… Idk man…
Try it before you buy it.
@@JoyofCodeDev what it means "runes enabled"? is per variable? I mean, are both ways going to coexist?
@@SRG-Learn-Codethey will coexist
Trust me, in large scale projects runes are a life saver. Building reusable components is also much easier now
You can enable it per component in the REPL.
(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)
look how they massacred my boy
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
What browser using on it ?
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 🥸
When I first learned Svelte, it was a super simple and useful solution, but now I don't like it because it's becoming more complicated.
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.
Lmao this sucks wtf ☠️☠️ they took svelte and deleted everything good about it
Sniff sniff who’s there? Confirmation bias
Talking to yourself is weird.
"how awesome is this guys"
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
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
Not one person who’s actually used svelte thinks this is a good change
I do. I use svelte for performance I don't care about syntax.
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.
@@suya1671 ohhhh 🙏
Finally New vidéeo ❤❤❤❤❤❤
One important thing I think missed in templating is the fact that you can now use typescript in the markup
Can we use these new syntax also in sveltekit?
You can with `npm i svelte@next`.
Slots were good... 😢
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 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.
You are missing the point literally.
It is true that at first glance some of the innovations look like boilerplate. But with version 5, Svelte is trying to become more attractive for larger projects with multiple developers. And after writing two medium-sized applications with Svelte 5, I can only confirm this. Although there is sometimes more source code, understanding the processes is enormously simplified.
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
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.
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.
So excited about svelte 5! awesome video bro
Do you have a video on how svelte compiler works?
I am more interested in React 19 now after seeing how Svelte 5 is moving away from what made itself special.
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.
As a vue3 enjoyer i like what im seeing, the dolar sign syntax has a few footguns for non trivial reactivity
my main question is why change the hood that everyone likes when the signals-rewrite is under the hood?
💔 it's evolving ....backwards.
Slot is good
Why are you doing that?
Where are snippets examples?
Back to vanilla react + mobx-state-tree after seeing this
The first example is like the delegation of a value (or an override of `assign` operator), I like this because we can use assign instead of state.set() or something like that. (but to be honest this is like vue so much lol)
The biggest trouble I have encountered about `$` label is I can't create a deconstruct declaration like: `$: [left, right] = somefunc`, but if I move declaration out of it, type will not match...
One of the most points why I don't like JS is too many nested brackets in it. For functional usage, Kotlin style is much much better than JS in my view. (But It's almost impossible to apply it on dynamic languages, what a pity...) I never thought I would become a conservative one day.
I don't like $props at all. If you want to safely specify the type for one of the props, you'll have to write 2x the amount of lines.
Literally everything is more verbose and more like react
just use react and be done with it
slow. Heavy
Love the video, and btw what browser are you using?
nvm just realised its brave after rewatching :P
I've only recently started using Svelte, so I'm glad this is coming in at this time.
What happened with the outro?
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. 😇
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.
Are named slots gone??
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?
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
So svelte is basically the exact same thing as cue with script setup now!! 😂😂😂
sweet summer child