15 ms·

The part of Svelte 5 which bothers me the most isn't the syntax changes for Runes, but rather the significant increase in complexity that the new API brings. T

by Ameo 2y ago

The part of Svelte 5 which bothers me the most isn't the syntax changes for Runes, but rather the significant increase in complexity that the new API brings. The `Proxy`-based state management API is a perfect example of this. The intention was to make working with mutable state like arrays feel better, but it creates this layer of added complexity under the hood with non-trivial performance and functionality implications (like the IndexedDB sync issue the author ran into). Compared to the `let x = 1` paradigm from before, we now have three different Runes for state (`$state`, `$state.raw`, and `$state.snapshot`) which you need to choose and understand the differences between. The added nuance to the way `$effect` works which is detailed in the post is in the same vein. Another issue is that stores are pretty much deprecated. I love stores because of their simplicity all the way through; you could click "go to source definition" on a `writable()` call in your text editor and read through the simple implementation in the Svelte source code. [1] You could confidently create custom stores that integrated seamlessly into Svelte's reactivity system all using plain JS; you just had to match the expected API. With hooks, that transparency is greatly reduced and all of the magic happens invisibly under the hood in the compiler. In `.svelte` files this was totally fine since it was operating within the Svelte model. But now, any random assignment to `self.foo` in a class might actually be to a reactive `$state` rune which could cause UI components to re-render elsewhere. Besides that, there are bugs when using both stores and Runes (some of which I've reported on Github [2]). Stores and Runes have slightly different reactivity models which aren't quite compatible. The response was basically a wontfix, so the expectation is that if you upgrade you go all the way. ---- I will say that I'm still a fan of Svelte and will probably keep using it as my favored UI framework despite my feelings about Svelte 5. And from other discussions I've seen on places like the Svelte subreddit, it seems that there are big parts of the community which are very happy about these changes. Maybe what some people are saying is true and that this added complexity is needed as a framework like Svelte matures in order for it to find adoption with larger teams and organizations. [1] https://github.com/sveltejs/svelte/blob/98734433376e99909fb6f2f141d9e66d0531ff4e/packages/svelte/src/store/shared/index.js#L34 https://github.com/sveltejs/svelte/blob/98734433376e99909fb6... [2] https://github.com/sveltejs/svelte/issues/11626 https://github.com/sveltejs/svelte/issues/11626

ravenstine 2y ago
That's exactly why I disagree with frontend framework fanatics. Before long, something your app was using in a legitimate way is obsolete because of someone's opinion, and you have to modify your already working code if you want to get bug fixes. We are told that frameworks save time, but do they really? Web components are supposedly not good enough or too hard to write... really? Making a router and a good-enough renderer that uses template strings and passes down state in a functional way can be accomplished in a matter of hours, or a few days if you have other things to do. The Svelte API shouldn't have changed, IMO. If you want what Runes do, then why not use React? Svelte will probably look like React in a few years, and maybe even like Backbone after that.

by Ameo 2y ago

ravenstine 2y ago

That's exactly why I disagree with frontend framework fanatics. Before long, something your app was using in a legitimate way is obsolete because of someone's opinion, and you have to modify your already working code if you want to get bug fixes. We are told that frameworks save time, but do they really? Web components are supposedly not good enough or too hard to write... really? Making a router and a good-enough renderer that uses template strings and passes down state in a functional way can be accomplished in a matter of hours, or a few days if you have other things to do. The Svelte API shouldn't have changed, IMO. If you want what Runes do, then why not use React? Svelte will probably look like React in a few years, and maybe even like Backbone after that.