The whole selling point of Svelte was that it was simple, like a breath of fresh air. You could update the state of your component just by assigning a variable. I guess this is the natural progression of web frameworks.
Svelte 5: Runes
201–210 of 404 posts
Re: Svelte 5: Runes
#202Earlier quoted context omitted.
> It's like every other framework is slowly rediscovering why React made the decisions it made. Definitely there is convergence in DX now. No need for everyone to admit one or another framework was right first or not - that is just creating antagonism or negating people lived experiences and innovation. But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte…
I think this somewhat inevitable given the flexibility of javascript. The lack of convergence on one single paradigm as a long-lasting set of best practices speaks to all of things that a web framework needs to have in order to accommodate all developers. In Svelte's case, it feels like they went as far as they could without directly addressing observables until they reached a point where it became one of the largest…
Svelte Stores are observables, just without the extra boilerplate.
Re: Svelte 5: Runes
#203One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can w…
> Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Just transpile it to let count = $state(0) under the hood? If that can work technically, instead of introducing a new rune for reactivity, why not introduce a "negative" rune to denote non-reactive statements? This way, the change wouldn't break existing code; it would be more of a progressive enhancement.
exactly my thoughts, feels like they could've kept it much simpler
Re: Svelte 5: Runes
#204Earlier quoted context omitted.
Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.
second this, plus its mature ecosystem, which is very valuable for the long term. though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.
The "ecosystem" is taking vanilla js libraries that work without modification in other frameworks and making them work with react via a wrapper. The react ecosystem is nothing.
Re: Svelte 5: Runes
#205React Hooks has its problems, but it got so many things right from the start - code written in 2018, when hooks first came out, still works today. No need to rewrite everything when a new major release comes out. That said, svelte5 does solve a lot of problems that stop me from trying it.
[dead]
Re: Svelte 5: Runes
#206What about scoped reactivity? Sometimes you need to react on some of the states not all of them. Right now we are achieving this by passing function with arguments to react on to $: but with $derived and $effect it seems to be not possible because it takes variables from every function passed. Are there any plans how to resolve this? Also nested $effect instead of onMount looks awfull and to be honest is less readabl…
You can use `untrack` [1] when you don't want to react to some state inside an effect.
You can still use `onMount`. It's not deprecated [2], although `$effect` could be used similarly going forward.
[1] https://svelte-5-preview.vercel.app/docs/functions#untrack
[2] https://svelte-5-preview.vercel.app/docs/runes#$effect-what-...
Re: Svelte 5: Runes
#207Earlier quoted context omitted.
You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying state is explicit and is the only thing that can trigger a rerender. These rerenders can only happen down from where in the tree the state change happens.
Let's be honest: the state (see what I did there?) of React state management is a dumpster fire. https://fe-tool.com/awesome-react-state-management That's an article listing the top 18 state management libraries for React. 18?!? React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about? Folks don't adopt utility libraries for things that were alread…
I’ve written a lot of react apps (first used it in a hackathon in 2014) and this list is really just fluff. hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex
I think the more glaring criticism is the lack of any unified component library. The amount of different Button implementations alone is astounding
Re: Svelte 5: Runes
#208One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can w…
We evaluated somewhere close to 50 different design ideas (seriously) before settling on this one, and what you describe was one of those ideas. But one of our goals was for you to be able to use Svelte's reactivity inside .js/.ts files, since that's one of the things people have been crying out for since we released Svelte 3. For that to work, reactivity has to be opt-in, not opt-out. And that's how it _should_ be —…
"...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
Re: Svelte 5: Runes
#209This is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like. Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the firs…
Yes, the API is very similar to Vue's. $state is ref/reactive, $derived is computed, $effect is watch/watchEffect. > why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you…
What is the difference between $derived/computed and $effect/watch?
Re: Svelte 5: Runes
#210Unless I misunderstood, Svelte 5 'runes' appears to be just 'markers' making explicit what used to be implicit with two noteworthy benefits:
- simpler compiler implementation - easier to identify moving parts
If so then the intro article needs a rewrite to be simpler without unnecessary districting details.