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.
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
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'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.
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
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 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.
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
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.
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 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
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 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.
@@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
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.
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.
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.
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
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 😓
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.
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.
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 😊
$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!
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
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.
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
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.
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.
looks like they are trying to convert react developers. lol... trying to fix a language based on it's global state management is a mistake. Global states are always a mistake because and devs use them way to much leading to hard to debug and weird bugs.
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.
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
@@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
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.
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.
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
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.
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 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
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…
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?
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 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
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.
This video misses props with typescript, which looks terrible with svelte 5. It's more like a promotional video than a fair comparison imo. Svelte 4 is much better at its current state imo. Version 5 resolved some painpoints and ruined a lot of things, which worked fine.
I feel like this is going to be a python 2.7 event. I dont get why people are against these changes. I have coded in svelte for a year and I know the downfalls, and how signals are solving them.
Why do people hate this new syntax, yes the old syntax was more concise than runes, but it was too implicit, and the big projects showed that we needed a little more explicitness in our code, I don't see how this is compared to react, it's two very different ways of coding on the approach to reactivity (no dependency, $effect is not a function like useEffect is... ). Elegant Code IS NOT Shortcode
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.
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 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.
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
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'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.
look how they massacred my boy
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?
Lmao this sucks wtf ☠️☠️ they took svelte and deleted everything good about it
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.
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?
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.
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
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.
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
svelte 5 is shit
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”.
I FUCKING HATE IT! Why ruin a good thing... I am definitely sticking to 3... They should not deprecate the features that popularized Svelte. FFS...
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
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 😂
🤭🤭🤭🤭
hmm so it has evolved into React.......great
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.
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
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.
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
Slot is good
Why are you doing that?
This is what I expect when Runes is release, the comparison between the old version. Thank you for making it crystal clear!
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.
Literally everything is more verbose and more like react
just use react and be done with it
slow. Heavy
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.
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.
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
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.
Slots were good... 😢
I'd like to see a practical example of runes in action. Say, a shopping cart or something, rather than just a counter.
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.
"how awesome is this guys"
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 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 😊
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!
Cool it’s like Vue now.
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
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.
Sniff sniff who’s there? Confirmation bias
Talking to yourself is weird.
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
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
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.
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 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.
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
looks like they are trying to convert react developers. lol... trying to fix a language based on it's global state management is a mistake. Global states are always a mistake because and devs use them way to much leading to hard to debug and weird bugs.
Nice to see Svelte becoming more like Vue 3.
$derived = computed
$state = ref / reactive
$effect = watchEffect
Whats next ? Virtual dom?
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
Wow! Now svelte v5 come closer to react hooks. Congratulations
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.
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
In 2024 Svelte will gain 5 more job openings, lets gooo
SVELTE MENTIONED
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.
Sveltekit is a confusing mess. I’ll stick to the qwik framework.
Do it qwik. 🥁
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
💔 it's evolving ....backwards.
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.
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
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
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.
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.
So basically just use react now. At least you can get jobs
Svelte is ruined, it's one version away from implementing vDOM and just stop development and migrate to hateful react mess.
they are implementing signals so your comment makes no sense, Just because you read the words "state" & "effect" does not mean you should panic.
You are the most overpanicked comment.
Vue implemented vDOM, I experience and evidence is on my side@@erickmoya1401
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.
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 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
Thank you so much for your Svelte work, I have learned so much from you!!!
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.
Did facebook buy Svelte?
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.
Finally New vidéeo ❤❤❤❤❤❤
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 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 think svelte 4 code looks waay more better because svelte 5 looks more like magic and i dont like magics in code.
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.
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 am more interested in React 19 now after seeing how Svelte 5 is moving away from what made itself special.
This video misses props with typescript, which looks terrible with svelte 5. It's more like a promotional video than a fair comparison imo. Svelte 4 is much better at its current state imo. Version 5 resolved some painpoints and ruined a lot of things, which worked fine.
Can you explain it or send a link? I dont know what you mean.
Coming from React, Svelte5 looks more intuitive and scalabe, without React's problems.
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 🥸
I feel like this is going to be a python 2.7 event.
I dont get why people are against these changes. I have coded in svelte for a year and I know the downfalls, and how signals are solving them.
Now svelte is vue
Can we use these new syntax also in sveltekit?
You can with `npm i svelte@next`.
One important thing I think missed in templating is the fact that you can now use typescript in the markup
Why do people hate this new syntax, yes the old syntax was more concise than runes, but it was too implicit, and the big projects showed that we needed a little more explicitness in our code, I don't see how this is compared to react, it's two very different ways of coding on the approach to reactivity (no dependency, $effect is not a function like useEffect is... ). Elegant Code IS NOT Shortcode
How are named slots going to work in svelte 5?
my main question is why change the hood that everyone likes when the signals-rewrite is under the hood?
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.
Oh hey look the "so good it's not react" library is just react now.
So svelte is basically the exact same thing as cue with script setup now!! 😂😂😂
sweet summer child
Do you have a video on how svelte compiler works?
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.
Now I am thinking about react again. Svelte 5 is not good at all
Iam from angular. I think svelte 5 looks better than 4
Stranger. Here are the Hooks you forgot on your way out of React ...
So excited about svelte 5! awesome video bro