I see these changes as net positive in the long run. Especially since it sounds like performance is getting a boost as well. The $props rune isn't something I realized I needed, but it definitely clears up code clarity. The $effect runes makes people think we are going down the React useEffect route... but I didn't see a dependency array attached there waiting to obliterate performance? I'm all for removing a tiny piece of Svelte magic to improve code clarity and performance gains. Seems like a big win to me. Thanks Rich and team!
Svelte 5: Runes
221–230 of 404 posts
Re: Svelte 5: Runes
#222Perhaps I'm just the grumpy old guy that's afraid of change. But I fell in love with Svelte because it was dead simple (according to me). It was a breeze of fresh air and I felt I just program again without wiring enchantments together. I do agree that its simplicity has downsides too, so perhaps it's just nothing to be afraid of? But I can't help seeing this as ominous: > This is just the beginning though. We have a…
Agree. Svelte is a blast to write as an old grumpy backend engineer. But yes, probably just scared for nothing. Turning onMount() into $effect() is a tiny change, but this self-aware smol brained grug likes onMount() as it means something! To enable logical grouping, Svelte 5 allows us to nest the $effect()s? What does that even mean? Where am I? Nurse!
nesting means that a variable being watched in the parent scope triggers both the parent and child functions, but a change to a variable in the child's scope only triggers the child function.
Re: Svelte 5: Runes
#223Earlier quoted context omitted.
I’m still waiting for every other framework to realize that jQuery was right all along. But if these guys are only now reaching Knockout, I still have to wait for them to catch up to Backbone.js, I guess.
jQuery is not a framework by any definition of the word. It's a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation.
Library vs framework is a largely pointless distinction, IMO.
Re: Svelte 5: Runes
#224Earlier quoted context omitted.
"...isn't quite right — it would break _all_ your existing code that wasn't in .svelte files." What if it is opt-out reactivity in .svelte files and opt-in reactivity in .ts/.js files? Yeah I know it would be a bit more combersome to copy code from .svelte to .js/.ts files but I think it would be worth it
That would be a _terrible_ outcome. Things would routinely break, and code would be vastly more confusing.
I love all the changes except that single thing with let count = $state(0);
I'm just brainstorming here, but what about an optional $reactive rune where everything in that is reactive by default?
$reactive(() => { let name = 'world'; });
vs
let name = $state('world');
Re: Svelte 5: Runes
#225Earlier quoted context omitted.
> for example, TypeScript thinks `$state` and `$derived` are just the identity function That seems like a missed opportunity on Svelte’s part… but hard to fault, because TypeScript doesn’t support nominal primitive types very well. Ideally it would be something like Reactive to signal (ha) that it’s not just a plain value.
We've toyed with this idea. There's a couple of problems though. Firstly, if you have this... type Reactive = T; function $state (value: T): Reactive ...then TypeScript will 'unwrap' the type anyway, unless you do funky stuff like this... type Reactive = T & { [uniquesymbol]: any }; ...in which case things like `value += 1` will cause type errors because it coercies `value` from `Reactive ` to `number`. But it also c…
> TypeScript will 'unwrap' the type anyway, unless you do funky stuff like this […] in which case things like `value += 1` will cause type errors because it coercies `value` from `Reactive` to `number`.
Yeah. I’ve spent more time than I’d like to admit trying to find a nice solution to this, and I’ve ultimately arrived at “it needs type system support to work for the general case”. I think you can make your brand (symbol) optional to address this case, but it doesn’t address this:
> The type of `obj.message` is Reactive, but it's _not_ reactive — it's a non-reactive snapshot of the value when the object was created.
And here is the real problem: the types are right (in this case)! It’s Svelte that is wrong (in that it deviates from the JavaScript language semantics, which TypeScript has correctly modeled).
This leads to my other ultimate conclusion with nominal primitive types: most of the time you’re better off just boxing the value… unless, or until, it becomes problematic for other reasons (eg performance, which would probably be a concern here, albeit one worth testing). Boxing allows correct, refined typing; it makes semantics of the value clear. The only downside is convenience… but this sort of convenience is exactly the kind of thing people rightly judge about the JS ecosystem.
I’m not likely to use Svelte (for a variety of other reasons), so I don’t have a particular dog in this race… but I will say I find more explicit types for signals a great deal nicer to work with. Whether the explicit mechanism is a function call (like Solid) or an accessor (like many others).
Re: Svelte 5: Runes
#226Earlier quoted context omitted.
As someone who tries to limit their client-side JS usage through uBlock/uMatrix, websites that aren't just blank with JS disabled would be nice to see, which is why I like React Server Components. Of course, if it's a useful enough web app, I'll enable JS, but if someone's writing a blog, ecommerce site, or really any site that may not require a full blown SPA. Sending minimal unneeded JS to the client is best, as it…
You can also achieve this with Astro, which will render your React islands statically and also enable client-side JS for interactivity / progressive enhancement when the client has JS enabled
True, however it's wrapped up in a nice DX in NextJS. In Astro, if I have multiple components that need React interactivity, are they all separate React apps basically? Or are they the same but with different roots? In NextJS, they're the same and Next can intelligently figure out which to render server side and which to render client side.
Re: Svelte 5: Runes
#227> Like every other framework, we've come to the realisation that Knockout was right all along.
And we are back full-circle ;)
Re: Svelte 5: Runes
#228Earlier quoted context omitted.
> for example, TypeScript thinks `$state` and `$derived` are just the identity function That seems like a missed opportunity on Svelte’s part… but hard to fault, because TypeScript doesn’t support nominal primitive types very well. Ideally it would be something like Reactive to signal (ha) that it’s not just a plain value.
We've toyed with this idea. There's a couple of problems though. Firstly, if you have this... type Reactive = T; function $state (value: T): Reactive ...then TypeScript will 'unwrap' the type anyway, unless you do funky stuff like this... type Reactive = T & { [uniquesymbol]: any }; ...in which case things like `value += 1` will cause type errors because it coercies `value` from `Reactive ` to `number`. But it also c…
With Rust, mutable variables are underlined by RustAnalyzer by default - it would be really useful for reactive variables in Svelte to have a similar distinction.
Re: Svelte 5: Runes
#229Earlier quoted context omitted.
That would be a _terrible_ outcome. Things would routinely break, and code would be vastly more confusing.
I love all the changes except that single thing with let count = $state(0); I'm just brainstorming here, but what about an optional $reactive rune where everything in that is reactive by default? $reactive(() => { let name = 'world'; }); vs let name = $state('world');
Maybe reuse the $:{} here, tho that would probably be really confusing for svelte 4 developers lol
$:{ let name = 'world'; };
vs
let name = $state('world');
$: is valid javascript right? So that should also work in .js/.ts files I assume
Re: Svelte 5: Runes
#230Earlier quoted context omitted.
> I’m still waiting for every other framework to realize that jQuery was right all along. I find myself feeling this way a lot while writing front-end code. While I am primarily a back-end developer by trade, I find myself working in Vue or React quite often just to get things done and regularly come to the realization that the majority of the reactivity in the projects I am working on is either unnecessary or so sim…
We sometimes have to step back from our high tech bubble. Check out jQuery's usage on the web. The unbeatable juggernaut that React seems from up here clocks at under 5% market share. It's sobering. https://w3techs.com/technologies/overview/javascript_library
There might be a long tail phenomenon at play here. Do you have stats on number of developers using the tech or on page views for each framework?