26 ms·

Ya I knew Svelte took a wrong turn when it went from var foo = "something" foo = "something else" -> ui updates to: $state('hello') Runes and other nonsens

Ya I knew Svelte took a wrong turn when it went from var foo = "something" foo = "something else" -> ui updates to: $state('hello') Runes and other nonsense immediately made me turn off Svelte. Even Vue sort of moved away and started looking like React. I think there is an opportunity now for another new framework which goes back to simplicity which Vue and Svelte tried to do. Mithril really was as close to perfection as one can get.

ChocolateGod 2y ago
I disagree, yes it feels less VanillaJS-ey but having unwanted reactivity made Svelte annoying at times and caused reactivity loops that just made code ugly to avoid. Anyway, if you don't want it like that you can continue to use the old system.
deleted 2y ago
[deleted]
recursive 2y ago
Interesting. The new Svelte seems clearer to me. In fact, Svelte seems to be moving toward vue to me, and away from react. That is components have stable identities and each piece of state has a subscriber list, which may directly update a DOM element or another piece of state. None of which requires re-"rendering".
- dapperdrake 2y ago
  At what point will they reach SQLite?
  - recursive 2y ago
    I don't understand this at all. There's no plans to support a query language. Scalar values can exist. Heterogeneous lists can exist. The use case is explicitly tightly coupled to a UI layer. What would it mean to reach SQLite?
mgrandl 2y ago
As somebody who maintains a very large Svelte app and upgraded from 4 to 5, I couldn’t be happier with the changes. For simple components the old approach was just fine, but the larger the codebase gets the harder it gets to work with.
- terminalbraid 2y ago
  I appreciate someone working on a sizable codebase to put in their opinion. Too often it's just feedback on their experience with a Hello World analog and it's easy to get hyperbolic opinions off of that.
  - ihateolives 2y ago
    Yes, but not everybody builds the next social network or complex commercial app with 50 pages and 150 forms. It used to be that svelte was the perfect choice to build simple spa fronts to backend services, there already was react for complex applications. Now we have 2 additional reacts with svelte and vue and no mainstream simple framework for smaller stuff. Why does everybody feel they need to build eventually the same thing, but slightly different?
- bangaladore 2y ago
  My opinion exactly. Svelte 4 is simple in a single component. Svelte 5 needs a bit more boilerplate. Svelte 4 was always very confusing in multi component/files workflows, especially when working with .ts/.js files. Svelte 5 is way better in this regard. I'd pay the "slightly more boilerplate" price every day.
Muromec 2y ago
>Even Vue sort of moved away and started looking like React. Did it? Vue has composables that look kinda like react hooks syntaxically, but aren't the same thing at all, they are just better scoped mixins.
sensanaty 2y ago
Vue moved the exact opposite way, and in fact Svelte moved more towards Vue 3 and its composables/CompositionAPI.
npn 2y ago
To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. Without svelte 4 compatibility, you can just replace `$state` with `$`, `$derived` with `$$` or even some simpler mechanisms. Heck, I have vague intuition that we can reuse the `$: ` statements someway too, and still keep the new deep reactivity feature. Might be svelte 6 will give us the proper answer. Or some newer fancy framework will take the hint and do it sooner.
- bangaladore 2y ago
  > To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. The way the compatibility works is by seemingly identifying the file and either treating it in legacy mode or runes mode. I don't think what you are suggesting would have blocked them from doing what they are doing now.
  - npn 2y ago
    It does thought. You can't assign new meaning to $ and $$ and expect that it works flawlessly with magic statements and the stores. At the very least the conversion between the versions will be very messy and error prones, especially using the migration tools. Not to mention the designs of runes was still unstable back then. Heck even now it is still very awkward to use runes with sveltekit. You need $state and $effect everywhere for the page data.
forvelin 2y ago
why mithril.js was though ? it is still a solid choice.

ChocolateGod 2y ago

I disagree, yes it feels less VanillaJS-ey but having unwanted reactivity made Svelte annoying at times and caused reactivity loops that just made code ugly to avoid. Anyway, if you don't want it like that you can continue to use the old system.

deleted 2y ago

[deleted]

recursive 2y ago

Interesting. The new Svelte seems clearer to me. In fact, Svelte seems to be moving toward vue to me, and away from react. That is components have stable identities and each piece of state has a subscriber list, which may directly update a DOM element or another piece of state. None of which requires re-"rendering".

dapperdrake 2y ago
At what point will they reach SQLite?
- recursive 2y ago
  I don't understand this at all. There's no plans to support a query language. Scalar values can exist. Heterogeneous lists can exist. The use case is explicitly tightly coupled to a UI layer. What would it mean to reach SQLite?

mgrandl 2y ago

As somebody who maintains a very large Svelte app and upgraded from 4 to 5, I couldn’t be happier with the changes. For simple components the old approach was just fine, but the larger the codebase gets the harder it gets to work with.

terminalbraid 2y ago
I appreciate someone working on a sizable codebase to put in their opinion. Too often it's just feedback on their experience with a Hello World analog and it's easy to get hyperbolic opinions off of that.
- ihateolives 2y ago
  Yes, but not everybody builds the next social network or complex commercial app with 50 pages and 150 forms. It used to be that svelte was the perfect choice to build simple spa fronts to backend services, there already was react for complex applications. Now we have 2 additional reacts with svelte and vue and no mainstream simple framework for smaller stuff. Why does everybody feel they need to build eventually the same thing, but slightly different?
bangaladore 2y ago
My opinion exactly. Svelte 4 is simple in a single component. Svelte 5 needs a bit more boilerplate. Svelte 4 was always very confusing in multi component/files workflows, especially when working with .ts/.js files. Svelte 5 is way better in this regard. I'd pay the "slightly more boilerplate" price every day.

Muromec 2y ago

>Even Vue sort of moved away and started looking like React. Did it? Vue has composables that look kinda like react hooks syntaxically, but aren't the same thing at all, they are just better scoped mixins.

sensanaty 2y ago

Vue moved the exact opposite way, and in fact Svelte moved more towards Vue 3 and its composables/CompositionAPI.

npn 2y ago

To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. Without svelte 4 compatibility, you can just replace `$state` with `$`, `$derived` with `$$` or even some simpler mechanisms. Heck, I have vague intuition that we can reuse the `$: ` statements someway too, and still keep the new deep reactivity feature. Might be svelte 6 will give us the proper answer. Or some newer fancy framework will take the hint and do it sooner.

bangaladore 2y ago
> To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. The way the compatibility works is by seemingly identifying the file and either treating it in legacy mode or runes mode. I don't think what you are suggesting would have blocked them from doing what they are doing now.
- npn 2y ago
  It does thought. You can't assign new meaning to $ and $$ and expect that it works flawlessly with magic statements and the stores. At the very least the conversion between the versions will be very messy and error prones, especially using the migration tools. Not to mention the designs of runes was still unstable back then. Heck even now it is still very awkward to use runes with sveltekit. You need $state and $effect everywhere for the page data.

forvelin 2y ago

why mithril.js was though ? it is still a solid choice.