> I like Svelte more than React (its store management)

It's great that there are alternatives to React, and that they do some things better than it. But what I find is that most large, complex applications I've worked on are not in particular hindered by the choice of React as a technology. It does vary from project to project too, of course - some applications will benefit more from some kind of well designed central state management solution.

Jotai, mentioned briefly in the article, may not be built in but is as intuitive as signals get and isn’t even tied to React as of later versions.

I’ve very rarely met a state management problem in clientside state management where neither tanstack query (for io related state) nor jotai (for everything else) are the best answer technically speaking. The rare exceptions are usually best served by xstate if you want to model things with FSMs or with zustand if you actually need a reducer pattern. There’s a tiny niche where redux makes sense (you want to log all state transitions or use rewind or are heavily leaning on its devtools) but it was the first to get popular and retains relevance due to the fact that everyone has used it.

You can go a long way with useContext and useReducer/useState but few would opt for alternatives if jotai came batteries included with react.

I think this might be true short term, but long term it means Svelte has more room to evolve with the web and with JavaScript itself, since fewer users means more room to move fast and break things, like Zig can and does. And Zig isn't dead.

This gives me a little encouragement for my personal web reactivity project. I'm confident I came up with a reactivity model that's technically innovative, which does and is what I always wanted React to do and be. But being so late to the game, my hypothetical framework has no chance to gain traction. I say hypothetical because I haven't even started making it yet. It would be built on the Ref class[1] that came out of my experimental work on os.90s.dev, but only last night did I finally get around to experimenting with using it with HTML[2].

The concept is to have JSX transform to allowing attributes to be given MaybeRefs and if its a ref then watch it and set the attr to the value, and just return the HTMLElement itself. This should be a good enough foundation to build an entire reactive framework around.

Having almost no users is a blessing, because it gives me the complete freedom to experiment with this relatively slowly. The time between creating refs and stabilizing them was a few months. The time between stabilizing them and using them in that experiment was another month. It'll probably be another month before I get a functioning non-trivial app working with it. And another few months before it's cleaned up enough to be both generic and convenient.

Maybe this should have been a blog post. I never know.

[1]: https://90s.dev/guides/refs.html

[2]: https://github.com/sdegutis/bubbles/commit/cde2bea973b22538f...

Pinia is so low ceremony and "just works"; it makes state management concerns practically disappear.

svelte has earned it's place and the more people use it - the better. I couldn't find a reason to switch, same with ember in early days, same with any handlebars go/php/rust etc. We live in the era when it's enough to learn one UI framework and just ship things.

Good post though, I wish it had more examples so

There’s an arcane layer of $yntax to mediate and a lot of flexibility and intuition is lost as a result.

“When to use stores

Prior to Svelte 5, stores were the go-to solution for creating cross-component reactive states or extracting logic. With runes, these use cases have greatly diminished.

when extracting logic, it’s better to take advantage of runes’ universal reactivity: You can use runes outside the top level of components and even place them into JavaScript or TypeScript files (using a .svelte.js or .svelte.ts file ending) when creating shared state, you can create a $state object containing the values you need and then manipulate said state state.svelte

export const userState = $state({ name: 'name', /* ... */ }); App

<script lang="ts"> import { userState } from './state.svelte.js'; </script>

<p>User name: {userState.name}</p> <button onclick={() => { userState.name = 'new name'; }}> change name </button>

Stores are still a good solution when you have complex asynchronous data streams or it’s important to have more manual control over updating values or listening to changes. If you’re familiar with RxJs and want to reuse that knowledge, the $ also comes in handy for you.”

https://svelte.dev/docs/svelte/stores#When-to-use-stores

This is described in the Solid documentation: https://docs.solidjs.com/configuration/typescript#control-fl...

In my experience with data-binding, these instances of disabling the typesystem accumulated, and became a frequent source of bugs.

So even though I hope for Signals to catch on, I believe the best way of connection to them will still be React:

  function Output({ userSignal }) {
    const user = useSignal(userSignal)
    if (!user) return <span>No user found</span>
    return <span>{user.firstName} {user.lastName}</span> /* TypeScript knows that user must be defined */
  }