The Svelte creator to KZitem content creator arc is something I was not expecting but I'm here for it.
@gtnbssn
8 ай бұрын
Oh yes you said "Svelte is teaching you JavaScript" in your last video and that was absolutely spot on! This, and Rich Harris giving credit to Ryan Carniato is showing us how we really are in great hands with Svelte and its community!
@rasulturganov3421
8 ай бұрын
love you channel dude
@viniciusrangel544
8 ай бұрын
i did learn everything about steven from joyOfCode, awesome.
@bjbk6373
8 ай бұрын
"how awesome is that?" Cheers, mate!
@adimardev1550
7 ай бұрын
looking forward for more videos from you man, you're Awesome!
@thedanielfrg
8 ай бұрын
Applause for making the video, taking the feedback, building in the open and just making a great tool!
@fev4
8 ай бұрын
I know you got a lot going on, but if you ever decide to do more YT content in a more consistent manner, I would just say everyone would be really happy about it because you can share info in a really neat and concise way. The way you explain things is just excellent.
@modernkennnern
8 ай бұрын
I fundamentally misunderstood how the runes worked originally. This is a great explanation. They seem to be a lot smarter than I originally thought
@drfatbuddha
8 ай бұрын
Thanks for this. Describing $state as a primitive to build from, and that there may be ways to simplify standard coding patterns once we've all had chance to figure out what those are, should allay many fears. This whole issue of wanting to treat a $state as a value, but also a signal, always seemed to be where the awkwardness would be. Using signals is 100% the way forward though - it would take a hell of a lot more than possibly needing a small amount of extra boilerplate for me to be anything other than extremely enthusiastic with this.
@minnow1337
8 ай бұрын
I definitely think the doubters stop thinking about the implications after seeing the initial boilerplate. Maybe the mistake was making state and effect reflect react lol
@lahcencodery
8 ай бұрын
My only concern at this point is the use of light theme for demoing things 😭 Otherwise, runes API is so neat and flexible
@amirhosseinahmadi3706
8 ай бұрын
This was helpful, thanks. You should make videos more regularly, Rich, by the way. Lots of people would be interested.
@hellcar77
8 ай бұрын
Thanks for this video. I've become a big Svelte fan, and while I had some inhibitions with the runes reveal, I trust that the team will take Svelte in the right direction. This is interesting as it shows runes in a different light: as primitives that can be built upon. It also reveals a lot of why people are drawn to Svelte; the perceived simplicity and fact that "it just works". I was able to go through the tutorials quite fast, and the main times I have to refer to documentation seems to be more for SvelteKit. I do wonder if arrays or objects of $state are possible, which wouldn't be possible with the auto-inferred logic.
@justmrmendez
8 ай бұрын
So, we are not becoming react, or vue, etc... we are letting you be them if you want to. I believe that people who say this takes away svelte's simplicity, and it's going in the wrong direction, haven't built a complex enough app with Svelte to see all the drawbacks of the current system. This will increase svelte market share in the long run, by a lot.
@meepk633
8 ай бұрын
If people are building apps where they want simple reactivity without inches of boilerplate, why would they care about Svelte's market share?
@mikeonthebox
7 ай бұрын
Fix the current system, don't make the framework become Vue. What will be next JSX? Different Template system? Will still use Svelte because it has probably the best templating out there, but wont be implementing runes at all. They are pure boilerplate.
@Rhysling2
8 ай бұрын
I’m in. Thank you Rich. Still waiting for an update to Ractive. Kidding of course. That’s where I got on this train and really glad I did!
@nicedreammmm
8 ай бұрын
This was very helpful to get a better picture of the new stuff. Thanks Rich.
@abdel17
8 ай бұрын
Thanks for clearing this up, Rich! Love the new changes!
@drantunes
8 ай бұрын
You need to share more in video, your presentations are always unique! 👏
@aegif
8 ай бұрын
thanks for the video and hope to see more content like this from you Rich, appreciate all the work you do
@nourmanhjr
8 ай бұрын
I think what the community wants is just a more standardized way of doing things. i know runes are far more primitive (as in it's a primitive to build from) than vue's refs and solid's signals. yes you can make your own getter and setter, and that gives you more freedom. but too much freedom is a DX hell especially working in a cross-libraries and cross-apps setting. a standard "wrapper" from svelte to use runes from any component would be good. we need more consistency in the way of doing things
@nourmanhjr
8 ай бұрын
Still, I appreciate the amazing work! thanks for trying to clear up!
@Krzysiekoy
8 ай бұрын
Great examples Rich! Love these explanations!
@JohanRonsse
8 ай бұрын
Thank you Rich. If anything I am just learning more about JS :)
@zsmain
8 ай бұрын
Amazing, Thank you Rich ❤
@mavdotj
2 ай бұрын
Although I really love svelte stores and I have formed a relationship with them, but being able to do reactive values like this is just *shefs kiss*
@aghileslounis
8 ай бұрын
Incredible teacher and innovator!
@radomane
8 ай бұрын
I like the idea of frameworks becoming more agnostic to things which are ultimately opinionated. Like I can create a project using Astro, create reactive components using Svelte. And then like shown here, pick between a pattern native to Svelte, one inspired by Vue or one inspired by Solid. All of this flexibility doesn’t really seem to come at the cost of some deep integration or performance. I feel like in the last year or 2 the switching cost between web framework has become significantly smaller, and finding a pareto optimal combination of tools/frameworks/libraries has actually become plausible.
@zhanezar
8 ай бұрын
this was sooooo much better in getting an understanding of Runes,
@willvincentparrone3339
8 ай бұрын
This clears up a lot of things. Thanks!
@ZaffaMan91
8 ай бұрын
This was super helpful, thank you for posting. Subscribing immediately, hoping for more of this in the future. Cheers
@matanon8454
8 ай бұрын
Cant wait for more videos! And thanks Rich as always for making Web development better!
@bergerblancsuisse.
4 ай бұрын
Svelte had the best stores of them all as shown by Fireship. In my opinion, enforcing writable() and removing reactivity from .svelte files unless it was declared with writable() would have been the best option because the interoperability issue around .ts/.js files and .svelte files would be solved with a pattern that is already superior to ref/signals. Open to seeing how this develops either way, but what I most enjoyed about svelte was not having to .value or getCount anymore and knowing that $count meant it was a store.
@crab-cake
8 ай бұрын
rich, you are a massive inspiration to me. thank you.
@BogacGuven
8 ай бұрын
Getter and setter are in Js since ES5, many OO languages have them. No need to panic, they are useful. 👍
@mikeonthebox
7 ай бұрын
Svelte is a compiler, they are supposed to set getters an setters for us at build time, and not have the developers do the framework job. That's the Svelte philosophy at least since Svelte 3 was announced. "Write less code" (Get rid of it) Rich words.
@hagaiak
6 ай бұрын
@@mikeontheboxDid you not see the video? `const counter = ref(0)` and you're done.
@zukrein
8 ай бұрын
Thanks Rich.
@lucabaxter4002
5 ай бұрын
The problem is not using getters and setters, the reality is that a lot of new devs started to code directly with Frameworks, that's the problem, as soon as you introduce a bit of vanilla js they panic! :D which is sad to see. Over the years, teaching js in companies i noticed a lot how the web universe changed. I had people i teached asking me to learn React before learning JS... and this is our fault (js community) cause of the massive confusion this obsession of changing patterns and constant evolution (or involution :D) created and companies adopting it. I really love svelte and the way the v 5 works, keep it up!
@oskrm
8 ай бұрын
Great stuff, Rich!
@jayberry6557
8 ай бұрын
After explaining the "ref" it does kind of make sense. It seem more flexible now. But now it will be kind of similar to what vue3 did with composition api. I understand the reason for the change but what would be a difference from vue then? Something that will convince to choose svelte over vue. I really hope svelte focus on best DX. Looking forward to new updates! Thank you for your hard work, i enjoyed svelte in my small projects 😊
@soundrightmusic
8 ай бұрын
Svelte and Vue are still very different. Svelte is compiled to vanilla is and Vue as of today still requires the Vue runtime to run.
@SaumilShah-pn6wm
8 ай бұрын
@@soundrightmusic compiled and blah blah is not DX, svelte 4 has best DX
@flalspspsl6858
8 ай бұрын
if you see no difference idk what crack your smoking and how much of it evan gave you to say this
@mikeonthebox
7 ай бұрын
For me I would still use Svelte over Vue because I love Svelte template system and hate the Vue approach. But Runes are so "No-Svelte" that will probably never update Svelte after version 6 when they plan on deprecating reactivity by default.
@topaz-rn
8 ай бұрын
I don't want to write runes :( I want runes to be baked in in let count = 0;
@ceocheema
8 ай бұрын
Thanks for this awesome video! 👏
@GMUStudentDesign
8 ай бұрын
Thanks for explaining the getters & setters, my vote is the ref vue way added to svelte please! 💜
@bmehder
8 ай бұрын
Thanks for clearing some of that stuff up.
@ROX2
8 ай бұрын
Hell of a refactoring, Harris. we still remember the route changes in svelte kit, but you still keep the brand. I am also beginning to understand that this is the philosophy of svelte
@supbra1
8 ай бұрын
Good video Rich! I'd like to see a comparison between store(writable) and runes way, to see the benefits.
@JorgeMartinez-xb2ks
6 ай бұрын
You are truly amazing bro
@TheKingAskdoof
8 ай бұрын
That's awesome! This runes will make Svelte much more viable to me, probably a very good alternative to Vue. Gonna look for that
@swyxTV
8 ай бұрын
great explanation!
@adamtak3128
8 ай бұрын
You're good at this youtube thing. You should do it some more :D
@Huntabyte
8 ай бұрын
Hey chill out man you’re gonna kill my channel if you keep posting content like this 😂
@jaideepshekhar4621
8 ай бұрын
Hey, nice to see you here!
@JasonChannelOne
8 ай бұрын
Awesome Video!
@kyuss789
8 ай бұрын
It really goes to show how good/bad reacts mental model for reactivity is. The fact that you can just return values from hooks because they always rerun is kinda nice but that is not how js works. Also rather telling that a lot over devs understand react more than they understand JS itself.
@sikandarbhide5354
8 ай бұрын
I Just Love u and i Love Svelte
@kontent_king
21 күн бұрын
Ain't nobody got time for that...!
@SoreBrain
8 ай бұрын
My favorite new channel. I forgive you for stealing from that all the frameworks!
@cory2300
8 ай бұрын
Great video!
@urban8499
8 ай бұрын
I can’t believe this dude just causally created the best framework 😂
@boreddad420
8 ай бұрын
Rich you are the GOAT
@--Arthur
8 ай бұрын
Runes are Svelte stores in disguise. writable -> $state derived -> $derived/$effect subscribe -> $derived/$effect Bringing Svelte closer to JS is what I think people are missing. Understanding JS/TS at a relatively high level, and having worked with Svelte for years, I completely understand the need - and I love this! ... Unfortunately Svelte's magic is lost. "Imperative" assignments to gain reactivity that is (compared to before). To make Runes easier to embrace, consider having `$` not only accept `.subscribe`, but also `.value`, so that `count.value` becomes `$count`. Runes are great, but we, the people, want a shorthand operand🙏 Two open questions: - Can you dig into how $state actually works behind the scenes to make things reactive, and how it differs from before? - How is the direct comparison between Svelte stores and Svelte runes?
@minnow1337
8 ай бұрын
the only hangup with your suggestion is that there would be a different syntax for accessing state between svelte components and in modules. People could opt-out with a linter but then reading svelte between projects wouldn’t be universal. It’s probably better to just accept the small boilerplate over the mental overhead
@--Arthur
8 ай бұрын
@@minnow1337 The suggestion is aimed to keep some of the flair Svelte provides with seamless reactivity. The boilerplate was what we were trying to avoid to begin with. At least with Svelte as I remember it. Your POV is naturally acknowledgeable. However, the similarities of $state and writablable means, I might literally just as well use Svelte stores, and throw runes out the window, as $state is less convenient Whatever the Svelte team does. Make it more convenient. Just like Svelte as we know it and love it today.
@supbra1
8 ай бұрын
These are exactly my questions!
@gitgudchannel
8 ай бұрын
The solid influence is noticeable but why should that be a bad thing!?
@bribes_for_nouns
8 ай бұрын
the problem is that the line between svelte and other frameworks blurs. even if not having state variables made it more difficult to debug in bigger projects, svelte's main niche was being so damn useful for those smaller projects, to the point where it could have replaced vanilla js entirely
@jeremybuckets
8 ай бұрын
There is essentially no change for local reactivity. The syntax is *marginally* different. That means for small applications, you'll still get an incredibly clean reactivity API that is mostly just javascript. The primatives unlocked with runes only matter for people whose application has scaled to the point where they're solving really complex problems with state and data sharing. As the video points out, taking advantage of the new functionality is meant to be the exception, not the rule.
@chick1824
8 ай бұрын
Hey, Rich, thanks for the explanation. There was a mistake in the first example until 2:24 - you do not actually increment the value in increment function, you have == instead of += there. But it still would not work, exactly like you said. Thanks for explaining everything in a video tho :)
@pepkin88
5 ай бұрын
I don't see it, there is always += there, never ==. Maybe on a smaller screen it appears as ==? I don't know.
@parassharma7041
8 ай бұрын
Love svelte❤
@SeyedaMansour
8 ай бұрын
actually just a very good tutorial
@Meleeman011
8 ай бұрын
alright, well this was a good video but this seems a bit superfluous to the writable store, is this the $state() rune supposed to be a more concise way to make stores then for my application? honestly my only complaint is effects look too much like react's useEffect. the fact you can nest them though is nice but I'm not sure when i would use it or how it would be abused, i really like the concept of watchers from vue tbh and wished that was in svelte or something that could do object diffing. but idk
@salman0ansari
8 ай бұрын
we are so back !!
@dominicgerman5908
8 ай бұрын
Definitely just hit the subscribe button before watching the video.
@danvilela
8 ай бұрын
Hmm what if I like old Svelte way? I know that for now it will still be available.. But.. what if we lose that old Svelte on next versions? any plans on that or waiting for community return?
@armandsalle8447
8 ай бұрын
That is soooo coool!
@xx__xx7199
7 ай бұрын
🚀
@daviidon
8 ай бұрын
My biggest issue is that it's not released with no ETA. Don't know if I should wait or continue svelting, but no one wants to write instant legacy code...
@rich_harris
8 ай бұрын
i wouldn't worry too much, svelte 4 code will continue to work for a long time, and we'll have tooling to automate as much of the conversion as possible
@windar2390
8 ай бұрын
They didnt give an ETA, so it's not right around the corner. But they announced it, so it's not going to takes years. And the Svelte team is known to push a upcoming release confidently. So my guess is January 2024. :D
@appurist
Ай бұрын
In my fantasy dreams (hey, I'm a geek), I dream of a world where Rich and Ryan get together and create a "greatest hits" framework that isn't necessarily backwards-compatible (but could have a migration layer) like SolidSvelte 6 or something like that. (I know, supporters of both frameworks would probably revolt, I'm looking at the future only. And I've already ported things from Svelte to Solid and Solid to Svelte so I'd do it one more time for SolidSvelte (stupid name but you get the idea).
@zacontraption
8 ай бұрын
❤
@rando521
8 ай бұрын
hi i have read the github about how svelte is a language and kinda replaces js. are you planning on doing something similar to phoenix and drop js mostly?
@Voltra_
8 ай бұрын
Does this change bring in the same pitfalls that Vue 2's reactivity system was subject to?
@FireNeslo
8 ай бұрын
I wonder if it would also be possible to expose some internals so that you can use some of the signals magic purely in runtime for cases where you want to maybe share the service with a react native app (just an example just one case that hit me as a possibility that could have a different team with different stack) and maybe add some binding layer where you are sharing the service layer but maybe not the build pipeline, of course that would add a little bit of overhead in some cases where the compiler might have been able to remove it but still. Still a bit uncomfortable about leaking compiler magic into js files
@huge_letters
8 ай бұрын
Hi Rich, would you explain how does the compiler handles runes given you can use them in .ts files too? The way I understand Svelte currently - you compile my .svelte files and you don't really touch my .ts files, there's "magic" with .svelte files, but my .ts files are essentially run as is. And the way I understand it, runes are not some runtime functions - they're flags for your compiler. So how do .js/.ts files fit into the picture?
@untlsn
8 ай бұрын
By using $state, $effect compiler know that this file must be compiled by svelte It's type of macro
@simonhartley9158
8 ай бұрын
Even if they're compiled, there may still be a runtime portion in order to achieve optimal performance and to handle dynamic dependencies which the compiler would otherwise struggle with.
@mehmetedex
8 ай бұрын
Great
@Naton
8 ай бұрын
Should've done this as the first demo. The initial demo pissed me off
@theLowestPointInMyLife
8 ай бұрын
Ryan Carniatio speaks Framework leaders: "write that down, write that down"
Is there a chance that after Svelte 5 comes out, the architecture of the framework will stabilize and will not be changed for the next 10 years (by architecture, I mean a complete break with the api responsible for reactivity between Svelte 4 and Svelte 5)?
@teamaccount9320
8 ай бұрын
The reason I use svelte is not because it’s capable of doing it the vue way or the solid way. I think i want svelte to have one way but it might be difficult to unify. i do not know
@jiangdawang4790
8 ай бұрын
now rune makes way more sense!
@sandrosxila
4 ай бұрын
what if counter returned () => { count, increment } at 3:02 and have const {count, increment} = counter() at 4:41 or we can do something like currying const {count, increment} = createCounter()() ?
@VideoBunt
8 ай бұрын
I have two main questions: 1) if runes will replace stores - how subscribe can be implemented? 2) How implement derived state with complex cases, like filtering array or object? e.g. const isAdult = $derived(user.age > 18) or const onlineUsers = $derived(users.filter(user => user.online))
@simonhartley9158
8 ай бұрын
I got the impression it's the latter. The syntax for derived seems to want you to pretend that it's not there, even if behind the scenes it's creating a function wrapper and the () => is invisible.
@dminik9196
8 ай бұрын
$effect would be the equivalent to the subscribe function of a store. It will also allow you to subscribe to multiple stores at once. Something you would previously have to do by combining multiple stores into a derived store.
@BosonCollider
8 ай бұрын
I like how this fits into the Svelte philosophy of just being a slight language extension to Javascript & Typescript that adds reactivity. In this case, reactive values where the compiler has more opportunities to compile away unnecessary stuff than something based on runtime diffing
@julioburgos3962
8 ай бұрын
Thanks for the clarification, could be possible to compile let declaration to $state call, and reactive assigmnet compile to $effect, $derived inside the svelte file, instead of $$invalidate
@simonhartley9158
8 ай бұрын
I wonder what the old style code will compile to when used with the new Svelte 5 engine.
@cherubin7th
17 күн бұрын
So basically the mission didn't work out. Very sad. I guess we just cannot have nice things in the JS hell.
@Lemmy4555
8 ай бұрын
Overall i feel that svelte got more complicated, look at the todos example at 7:27, this is telling me that now there's a separation between the "serializable JSON representation of the state" and the "reactive version of it", in order to make an array received from an API "reactive" we now need to convert it and replace every property with getter and setters that point to $states, and even if we create a recursive utility function you still to do something like "makeReactive(fetchedData)", the alternative is that you set the whole object in the state and you replace it all with the react way "data.value = {...data.value, foo: { ...data.value.foo, bar: newBar}}" or "data.value.bar= mewBar; obj.value = data.value".
@Mankepanke
8 ай бұрын
How would you do it before the change? Why wouldn't you keep doing it after these new primitives are added if you felt that way worked better? I think Rich is very clear in why these new primitives are added, and it's about being able to add reactivity outside of component files.
@Lemmy4555
8 ай бұрын
@@Mankepanke because in a svelte file you have to choose either to activate the "runes" mode or old-school reavtivity (that means everything in the root component scope is reactive). Currently you can just assign the result of the fetch to a variable in the component and if you change anything inside it the reactivity will trigger.
@hahnkev
8 ай бұрын
yeah that's how vue does it and it's really annoying, also typesaftey is a big pain because it can get lost when passing through a rewrite function like that.
@lukafireman
8 ай бұрын
Fireship's comment still has a point. (Albeit, everything Rich said is true)
@DanielRios549
7 ай бұрын
Can you compare Svelte 5 runes with Preact Signal?
@TheGargalon
8 ай бұрын
7:55 - I feel like if this was emphasised a lot more, there wouldn't be so many confused people. I had to read the blog post a few times, watch this video twice, read some of the fireship X thread to finally understand what runes are trying to solve. I actually encountered the same problem in my app and ended up implementing a custom store - it just two-way binds an object to a firebase realtime db path. It will be a lot cleaner with the new syntax, but essentially the same thing.
@TheFlexy95
8 ай бұрын
Great video, I’m familiar with getters and setters. But personally, if a store would have been used, no getters would be necessary 🧐 it was enough to understand that a store was an object and would always result in a call by reference. Maybe the compiler could add automagically a getter if it’s a state? 🤔
@flalspspsl6858
8 ай бұрын
the same issues exist with stores, you never noticed the literal "get()" function it exports?
@TheFlexy95
8 ай бұрын
@@flalspspsl6858 the store has a get method? O.o I just know about “get” from “svelte/stores” which does a subscribe and unsubscribe immediately after. Which is fine, since the subscribe method is called by reference and will always present the actual data, not stagnant data (like with runes if a getter is ommited).
@omomer3506
8 ай бұрын
Yes
@zap813
14 күн бұрын
Just FYI getters/setters are NOT necessarily idempotent, since they are just functions like any other. Take this for example: const obj = { get prop() { const rand = Math.random(); if (rand < 0.5) return null; return { str: 'blah' }; } }; Accessing prop on obj could get you two different data types if called twice, but TS doesn't know that, so it incorrectly thinks you are good. Even though this is a contrived example the fact that it's possible means that it's not real type safety since you are just fooling the TS compiler in the same way you would with a non-null assertion, although in this case it's not explicit.
@MaxPicAxe
8 ай бұрын
A getter in this context is kind of like javascript's alternative to references.
@zeteya
8 ай бұрын
Still not sold, what's wrong with stores again?
@intrnl
8 ай бұрын
"seen people produce interesting abstractions like deeply nested reactive objects" ooh i wonder who
@rich_harris
8 ай бұрын
😁
@omgwat
8 ай бұрын
Okay so can I use it? :P
@ngprnk
8 ай бұрын
Just waiting for shadcn on svelete and will switch to svelte.
@mijmijrm
5 сағат бұрын
Catweasel!
@naranyala_dev
8 ай бұрын
svelte the right way
@lwinklly
8 ай бұрын
rich harris you tube channel official no way
@tom9380
8 ай бұрын
Don't quite get why derived needs to be set manually and can't get "derived" automatically.
@xazzzi
8 ай бұрын
How do i peek state value without it being registered as a dependency?
@user-lq7xz1th4x
8 ай бұрын
Just like an ordinary variable let variable = $state(0) variable = variable + 1 //etc {variable}
@xazzzi
8 ай бұрын
@@user-lq7xz1th4x i mean from within effect or other code that tracks dependencies in runtime. Eg log counter 2 current value when counter 1 updates, but not when counter 2 does.
@W4nn3
8 ай бұрын
@@xazzzi There is an `untrack` function, look it up in the docs
@windar2390
8 ай бұрын
Svelte 5 brings runes. But how we use it, is javascript and has nothing to do with Svelte 5. Got it! (hopefully^^) We just need to figure out a pattern that works for our project.
Пікірлер: 202