Honestly, quite the over-engineered solution for a problem they were supposed to solve. What does svelte brings to the table with this much complexity? Speed?
Svelte 5: Runes
281–290 of 404 posts
Re: Svelte 5: Runes
#282Earlier quoted context omitted.
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
I just write my first fairly complex react app. As a mostly backend/tool Dev with good knowledge of functional programming I agree with this. I could solve almost any problem using hooks + context and memo. I briefly considered using Redux but I quickly realised that a few changes in certain components would take care of most of my state management problems
Re: Svelte 5: Runes
#283Earlier quoted context omitted.
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…
I'm replying to you, but I'm asking the room: what, if anything, stops vue3 from compiling down to pure JavaScript like svelte does and reaping the speed benefits?
I think the main thing is the existence of alternatives. Svelte is cool, but it has the key flaw that the more Svelte you write, the more compiled code appears - generally, Svelte compiles to a size somewhat larger than the original source file.
For Svelte as an "island" tool (i.e. for building islands of interactivity in otherwise static pages, like, say, graphs for the New York Times), that's not a problem, because the extra generated code is made up for by the lack of a bulky runtime dependency. But if you scale that up to complicated SPAs - which has been Vue's main stomping ground - you can end up shipping larger files with Svelte than with other small frameworks.
That said, SFCs in Vue are an ideal source for compile-time compilation, and my understanding is that they're heading more down the route of SolidJS. SolidJS has a similar goal of using a compile step for optimisation, but it leans on its signals library implementation much more heavily, which means the compiled code tends to be much smaller, but you also need to include a runtime. (In practice, there's not much size difference between Svelte and SolidJS at all, but it shows itself at the more extreme ends of very small components and very large apps.)
Vue already has a runtime that's very similar in some ways to Solid's (read: it's all signals, baby), so adopting the rendering ideas from there is an obvious next step. That should drastically speed up rendering, as well as reducing bundle sizes significantly. They've already demoed this a bit, but I think it's not fully released yet - they gave a name for the new system, but I've forgotten what it's called.
Re: Svelte 5: Runes
#284Earlier 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.
React is honestly how I used to write my code in jQuery too, for some pages that had a lot of state. Basically, just like in game dev, I had a render() function that I'd call at the end of the file that would re-render everything. The pattern itself is very easy to understand, re-rendering efficiently is the hard part, but for React users today, that's an implementation detail. Hooks are also very interesting, they'r…
Indeed, seeing hooks as closures helped me to understand how they are use for state management. It's really a "poor man's object" with all the advantages of FP in terms of reasoning about state changes, lack of side effects etc.
Re: Svelte 5: Runes
#285Earlier quoted context omitted.
I kind of feel the same. React and all the new stuff now feels like unnecessary complexity but they definitely got the initial DX right
The fact that the frameworks are converging on the same idea should suggest that it is necessary complexity in the framework for any sufficiently complex app.
Or that they are too invested to drop features in place of adding more? When this happens, incumbent frameworks appear. Svelte was one but it became just like the old ones before its prime time.
Re: Svelte 5: Runes
#286I've been trying Svelte for the last couple of months. At first the claim was that it's not complicated like React because there's a lot less concepts to learn. And it's just using basic Javascript and CSS so those skill sets are transferable to any other job. As I use it more and more, there's more and more special way of doing things I have to learn: store, reactive variable, $, $$, etc. I didn't mind, sure I'm in…
That is exactly my experience after trying svelte/sveltekit for 2 months. Loved svelte at first sight but soon their own invented complexity (and a very confusing error log) made me realize that I was changing React for something quite similar (with a bunch of different problems). In place of going back to React tho, I tried the next one in my list: Lit. No regrets, found the (powerful) simplicity I was looking for. Give it a try before getting back to React: https://lit.dev/
Re: Svelte 5: Runes
#287Earlier quoted context omitted.
Huh? It's called observable because it can be observed (that's what "-able" means). If it were actually meant to observe something (as you say), it would have been named "observer." But it's not - it's the callback that's the observer. Also observables are more like streams than arrays.
I don't think I'm entirely out of band to say there could be a better way of naming them, like why not call them SubscribableStream . Saying its an observable invokes a messy gray area in people's brains. I know this because I've had to explain observables to co-workers more times than I can count in my career (I'm a big fan of RxJS, I didn't mean what I said as a dismissal), and I like them for async work vs promise…
Because RxJS made at least one huge mistake: it made its observables lazy.
When does it start? How do you deal with oversubscription? Late starts? Double subscriptions?
On top of that streams are always a pain in the butt to debug.
The fifteen million obtuse methods/operators didn't help either (I see there are significantly fewer now).
And to remind you: it took the author of RxJava several months to understand the programming model: https://twitter.com/dmitriid/status/811561007504093184
Re: Svelte 5: Runes
#288Earlier quoted context omitted.
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…
React is the pragmatic answer. Most devs are of average talent and will hang themselves and everyone else with the stateful webs they weave. Even with careful PR reviews, these things have a way of sneaking in and becoming permanent hinderances. Performance hasn't been a dealbreaker in most JS apps for years now. What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is d…
Average devs struggle with useEffect, useCallback, useMemo and other hooks. If anything, Svelte, Solid and Vue are significantly easier.
Re: Svelte 5: Runes
#289Earlier quoted context omitted.
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
> hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex
To be fair, context is not a state management tool [0], an article by acemarke, the Redux maintainer. It does work as a dependency injection tool and for many people, that's enough, but it's not a true state management tool.
[0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
Re: Svelte 5: Runes
#290I have a complicated spaghetti object that I need to render. Given: let spaghetti = $state(uglyMess) Does `uglyMess.thingOne[1].anotherThing = { moreMess }` re-render the whole tree or just the children of `uglyMess.thingOne[1].anotherThing`?
If you created `anotherThing` as nested state, then just the children!
See this for a real example: https://svelte-5-preview.vercel.app/docs/fine-grained-reacti...
Here is the same thing in SolidJS with more explanation: https://www.solidjs.com/tutorial/stores_nested_reactivity