React doesn’t really concern itself with state management. Of course it has context, state, and props but the mental model for it predates focus on fine grained reactivity in frontends — useSyncExternalStore helps enable others to fill that void in v17+. Fine grained reactivity was notably also missed in the development of web components — only now is there a tc39 proposal for signals (in its early stages).
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.
Never heard of Signals[1] until now, thanks. But it makes me nervous with how much influence it has from React and Vue, and the way React and Vue do things. These are not the be all end all methods of reactivity, and I can't help but think if there's going to be an official language feature implemented for this, there needs to be room for other voices to be heard that have zero influence from React/Vue. Maybe there's still time since it's Stage 1.
I wouldn’t say signals is coming from React. If anything React is the latest to the party and being dragged there reluctantly by where the tech community is going. They’ve mostly been resisting the movement towards signals because it undermines a lot of the arguments they have made for their virtual dom, synthetic event system, and rerender all the things dogma. Solidjs is much much more in the signals camp. Angular, Vue, Svelte, etc also recognize the need for this sort of reactivity.
React could be argued to have abandoned the fight for being the best client side framework technically (though they have dominance pragmatically). They are really all focused on Vercel’s Nextjs/SSR/SSG/RSC stuff in recent years
Just FYI, Signals are actually derived from Observables in KnockoutJS. React was originally created as a response to the first wave of JavaScript Frameworks which heavily relied on two-way binding-- remember the whole emphasis on "unidirectional flow"?
Signals recently became more popular as people observed the performance and DX that they made possible in SolidJS.
Solid's creator, Ryan Carniato, has acted as a bit of an evangelist for them-- even working closely with the Angular team.
> The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…
What other voices would you like to get feedback from?
Most UIs I've written in my career benefit from being modeled as FSMs. While I see the value proposition of the atom-based approaches, especially for basic applications, I can't help but become a bit hesitant about their scalability long-term on large teams. Part of the reason the very dogmatic Redux approach of a event dispatching + single store of truth caught on so quickly was because a lot of us had felt the pain of two-way data binding / global state with event listeners in Angular 1. I distinctly remember the horror of debugging digest loops (scope.$$phase memories) and being completely lost in the unstructured data flow. What made for a great demo became a nightmare at scale.
There's nothing stopping people from using these atom-based libraries to build more robust abstractions, but from my professional experience I tend to just see global getters and setters with useEffects / lifecycle method of your frameworks choice as a side effect sync.
Maybe my instincts are off here though and I am overly cautious. I love XState but the learning curve is rather massive and getting buy in from other team members is hard when the DX of the atom approach is so nice.
I feel like state "management" and reactivity performance are talked about a lot, when ultimately state orchestration is where I see things fall over the most.
I haven’t ever seen issues scaling with jotai even on very large apps working with extremely complex data structures.
I’ve seen far larger messes created in redux due to tight coupling of things across large apps to a global store and the inability to work with things like Maps and Sets or other values that are not trivially JSON serializable.
In the other direction I have seen messes with observable-based state management systems where things become far more complex and too far abstracted (how often do you really care about anything other than the latest value and maybe the previous one?) or with proxy based systems that have too much fragile magic (valtio, mobx) or require wrapping your components and going all in on oop (mobx)
To me signals hit the magic spot of reactive without being overkill and keep code testable in smaller units while retaining performance benefits of surgical updates
I like xstate in theory — it’s a good way to think about complex state transitions — but in at least half of cases in practice where you aren’t interested in a derived value, someone is storing a value/ getting the latest value or toggling a boolean and it’s just such overkill for that. The reducer pattern itself doesn’t meaningfully show up much for similar reasons. The other common cases are with fetching states (idle, loading, refetching, success, error) but you often end up wanting things like cache management or maybe even optimistic updates so eventually tanstack query covers that ground better than rolling your own.
As someone who created those horrifying RxJS monstrosities, I agree with most of this, which is why I caveated my concerns. Tanstack Query simplified a lot of these issues—separating server state and caching from client side state was a huge boost. I’m mostly coming from the perspective of someone who just inherited a Jotai code base with 200+ atoms and trying to wrap my head around it. Any library poorly used can lead to a mess though, so not going to claim it’s a problem inherent to all atom based approaches.
Re: atoms + learning curve, this is why XState Store exists, which supports both XState-style state updates and atoms: https://stately.ai/docs/xstate-store
I also like the approach of Svelte, and realize that sometimes a full state machine isn't needed. I don't think that atoms should be used everywhere, since updating state freely without guardrails just leads to disaster long-term.
According to a resonating reddit comment, Svelte isn't more popular because it's simply too late; React and Vue got there early and got good enough, so Svelte can't really get as big as them.
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.
It's neither true that Svelte has few users or that we can easily break things. Tons of sites are built with Svelte like Yahoo Finance and Apple Music. Svelte 5 was the only big change in syntax in the past five years and we made sure that there's a good migration tool, etc. to minimize the amount of hardship and upgrade might cause. As a result the majority of users have already upgraded to Svelte 5.
That being said, Svelte absolutely does continue to innovate. We'll be introducing a new async primitive, RPC mechanism, etc. in the near future: https://m.youtube.com/watch?v=1dATE70wlHc
I think svelte, especially now svelte 5, will “win” because it doesn’t fight with vanilla web dev it just beautifully supplements the short comings of rolling plain html, css, js.
This is coming from someone who is no way a front end dev, but svelte 5 in particular is just so easy to get started with and has the most sane approach to reactivity and syntax compared to the other frameworks I have tried, and it seems like it is in the best position to grow with the web as well.
// Create new Ref
const r = van.state(0)
// derive functions as adapt/watch/multiplex.
// Implicitly depends on any Ref it uses and re-runs when they change.
const r2 = van.derive(() => 2 * r.val)
van.derive(() => console.log('r2 is ' + r2.val))
// Changing the value doesn't update r2 or print immediately, it schedules
// a batch update when all derives will get recomputed.
r.val = 3
// ...So 'r2 is 6' won't be printed here.
r.val++
// Refs can be used in a hyperscript-style DOM builder.
// This creates a regular HTMLElement, with a regular Text node where r2 goes,
// but it holds onto that Text node behind the scenes and automatically
// updates it when r2 changes.
const {p} = van.tags
document.appendChild(p("The value is ", r2))
I would recommend to not make a web framework with the idea of it being popular, like competitive with react. It’s much better to make a library that works with react / vue / svelte and see if that can become popular.
There are enough web frameworks. If you make a blog post where you state what limits you have with the current state of web technology, and you describe it really well, I’m sure someone will be able to point out how there is a web framework that deals with that. Or a way to implement that in current web frameworks.
> 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
That is essentially what Signals are, including directly setting .textContent when possible.
This model actually predates all of this and was used way back, in Backbone.js and other pre-react frameworks, except we didn’t have JSX or virtual DOM at the time.
I remember Backbone using two-way bindings, which I think is more complicted than what my experiment does:
const el = document.createElement(tag)
for (const [k, v] of Object.entries(attrs)) {
if (v instanceof Ref) {
el [k] = v.val
v.watch(val => el[k] = val)
}
else {
el[k] = v
}
}
You might be thinking of Knockout.js. Backbone used a manual event-driven approach where you'd wire up each component to a model/observer that you called .set(value) on. Except it was a lot more verbose, and because you'd be using chunks of string templates for rendering, it wasn't very fine grained — basically how far up the tree you added the subscriptions defined the update granularity. Most importantly, no incremental rendering or virtual DOM meant manual management for any input states, and the lack of a defined render lifecycle meant it was hard to keep track of updates and very easy to get into infinite recursion loops.
As someone else mentioned in this thread, the main innovation in the React era was actually it's sister library Flux which brought the idea of a unidirectional data flow into the picture, later inspiring Redux et al. We are now getting past the immutability detour and keeping the best of both worlds, maybe.
I think it is useful to say the blog post is using svelte 4, and the svelte 5 docs mention:
“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
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.”
I also like svelte quite a lot although I was/am genuinely a bit confused as to how to join svelte to some external [state machine / business logic]. I ended up with runes basically infecting the entire codebase, but presumably a proper boundary must be possible?
For complex things, I came up with a pattern that stores the state externally from the components in a single centralized file. So the components just become simple shells that render the state and forward events. (All the complex business logic can be tested without the DOM/headless browser.)
I call it "nation state" because it groups sets of related variables together in a scope between local and global.
I implemented the pattern with Svelte runes, but I think it could be implemented with anything; even React.
Yes this is the way to do it, global-ish state files with getters and setters. I’ll have a .svelte.ts file (or a few of them) with a typed state object, maybe a function for refreshing it or syncing it with a backend api, import the state all over the place.
Might be an anti pattern but it works really well.
I think I follow but IIRC my problem was something like that the getters and setters had to be quite "flat". if they weren't they would recursively infect everything top-down and then not work anyway because of boundaries in the deep reactivity.
Yeah sadly the stores the author talks about here aren't the right way to do things anymore in modern svelte and they're all-in on Runes.
Stores were a big part of the reason I liked svelte; they were so conceptually simple, extensible with plain JS, and made interop outside of Svelte trivial without the Svelte magic leaking out.
They're still in Svelte, but they mix poorly with runes and are basically unsupported in runes mode. I opened up a bug about store behavior not working like it used to when mixing with runes, and the response was pretty much "yeah we don't expect it to work like that anymore when runes mode is enabled".
I don't even mind the runes I just don't get the impression from the docs that anyone has a clear feeling about how to actually use them e.g. forget the toy examples, suppose an alien has given me clump of minified business logic and we have to make it work.
The problems with these examples in my opinion is they often extend extremely trivial examples of problems to large, complex applications with a lot of assumptions about the problems those large, complex applications are likely to have.
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.
> 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.
AKA, React is accidental complexity. Solving accidental complexity issues may be required some time, but more often than not, it's just something you endure as the alternative choices are not that much better.
Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).
State management and optimized DOM manipulation can be achieved with vanillajs nowadays and I'm not saying that as a purist, it is just good enough that React is not needed. To help a bit with the ergonomics, I use lit-html/uhtml for the templating but they are both based on template literals, a native JS feature.
> Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).
The essential complexity was the interactive need of your UI. Any of the current web framework can be a solution. The only reason to go for React is hireability (almost anyone knows it) and devex (so many prebuilt components). But it's not like that the others are so hard to learn and components are hard to build.
> But it's not like that components are hard to build.
I really want to like other frameworks, but if I'd have to build a MUI(x) by hand, I'll accidentally pivot our business model to "component library maker" as a result.
I think we need to be clear about what scope we are talking about. A full fledged data-heavy B2B application, or something simpler like a web shop?
Ironic that this is one case when you don't use an apostrophe to indicate the possessing entity. I suppose the rule is possessive nouns only, not pronouns.
If enough of us make this mistake then maybe the prescriptive half can drop the whole "possessive pronouns don't get an apostrophe" rule altogether :D.
The same goes for "alot", avoiding the use of "whom", and so on - I ain't gonna give up on them!
I think they've given up on this, it's ubiquitous. I've recently noticed that a CLIP model (a neural network for image understanding) gave me image descriptions using "it's" where "its" would have been correct. Hundreds of thousands of dollars to train the thing; no one noticed, no one cared ¯\_(ツ)_/¯
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 */
}
A re-render in React is not as heavy as you'd think it is. It's painting the DOM that takes resources, and people conflate the two. But if your whole component re-renders because of a change in context, yet nothing on the page changed, you will likely not notice the render even on low-end devices.
I still think Zustand is the simplest state management, while staying efficient. It's similar to the old Svelte stores. But I have used many state management tools and the re-renders were not the problem when it came to speed.
A "compiler" to solve the issues the library created, awesome. It doesn't solve many re-renders tho, as React re-render full components, not only the HTML/Text Nodes that changed.
For generic browser based application I am in favor and am using domain specific libraries like three.js and purposely made web components. For the rest modern javascript works just fine. I just do not see the value of those framework monstrosities and build processes. They might be solving some problems for companies of Meta's scale but on small dedicated teams in my opinion it is just waste of time and money for no tangible benefits.
If you're writing Svelte code today and you need shared state, I would recommend you start by looking at the Context API (https://svelte.dev/docs/svelte/context). For manual control of data updates you'll probably still want to use Stores (SvelteKit does!) but I'd start with Context first.
I had never heard of Pinia. Visited their landing page [1] and there's a button selling a course on how to use the library. There's a CTA for the course when you go to the Guide page as well. Very strange!
In 2018, I taught Vue workshops where I memorized a Vue enabled html page and went through links from the homepage. Since then, Vue took permutations of options/composition, js/ts, Vite/whatever and deferred documentation to Vue teaching sponsors.
Svelte stores just sound like adding Redux to React, which used to be in vogue then stopped being in vogue and I guess this blog post marks them being back in vogue.
The blog post compares an example using hooks to pass in a state and update function to a child component. It then compares that to a Svelte component which contains a state variable.
Those two examples aren't equivalent because any parent component wrapping the Svelte component doesn't have access to the state whilst App (in the React example) does.
For the Svelte example to be equivalent, the component would have to export the store.
A minor gripe but the hooks vs Svelte state is pretty minor issue in itself.
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.
React doesn’t really concern itself with state management. Of course it has context, state, and props but the mental model for it predates focus on fine grained reactivity in frontends — useSyncExternalStore helps enable others to fill that void in v17+. Fine grained reactivity was notably also missed in the development of web components — only now is there a tc39 proposal for signals (in its early stages).
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.
Never heard of Signals[1] until now, thanks. But it makes me nervous with how much influence it has from React and Vue, and the way React and Vue do things. These are not the be all end all methods of reactivity, and I can't help but think if there's going to be an official language feature implemented for this, there needs to be room for other voices to be heard that have zero influence from React/Vue. Maybe there's still time since it's Stage 1.
[1] https://github.com/tc39/proposal-signals
I wouldn’t say signals is coming from React. If anything React is the latest to the party and being dragged there reluctantly by where the tech community is going. They’ve mostly been resisting the movement towards signals because it undermines a lot of the arguments they have made for their virtual dom, synthetic event system, and rerender all the things dogma. Solidjs is much much more in the signals camp. Angular, Vue, Svelte, etc also recognize the need for this sort of reactivity.
React could be argued to have abandoned the fight for being the best client side framework technically (though they have dominance pragmatically). They are really all focused on Vercel’s Nextjs/SSR/SSG/RSC stuff in recent years
Also shoutout to Solid's inspiration, S.js[0].
[0]: https://github.com/adamhaile/S
I remember Signals from my actionscript days
Just FYI, Signals are actually derived from Observables in KnockoutJS. React was originally created as a response to the first wave of JavaScript Frameworks which heavily relied on two-way binding-- remember the whole emphasis on "unidirectional flow"?
Signals recently became more popular as people observed the performance and DX that they made possible in SolidJS. Solid's creator, Ryan Carniato, has acted as a bit of an evangelist for them-- even working closely with the Angular team.
Whoops, this sentence accidentally got left out as I was moving it around for formatting:
"Preact, Qwik, Svelte, and Angular all quickly followed suit and unlocked huge performance benefits."
From your own link:
> The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…
What other voices would you like to get feedback from?
Most UIs I've written in my career benefit from being modeled as FSMs. While I see the value proposition of the atom-based approaches, especially for basic applications, I can't help but become a bit hesitant about their scalability long-term on large teams. Part of the reason the very dogmatic Redux approach of a event dispatching + single store of truth caught on so quickly was because a lot of us had felt the pain of two-way data binding / global state with event listeners in Angular 1. I distinctly remember the horror of debugging digest loops (scope.$$phase memories) and being completely lost in the unstructured data flow. What made for a great demo became a nightmare at scale.
There's nothing stopping people from using these atom-based libraries to build more robust abstractions, but from my professional experience I tend to just see global getters and setters with useEffects / lifecycle method of your frameworks choice as a side effect sync.
Maybe my instincts are off here though and I am overly cautious. I love XState but the learning curve is rather massive and getting buy in from other team members is hard when the DX of the atom approach is so nice.
I feel like state "management" and reactivity performance are talked about a lot, when ultimately state orchestration is where I see things fall over the most.
I haven’t ever seen issues scaling with jotai even on very large apps working with extremely complex data structures.
I’ve seen far larger messes created in redux due to tight coupling of things across large apps to a global store and the inability to work with things like Maps and Sets or other values that are not trivially JSON serializable.
In the other direction I have seen messes with observable-based state management systems where things become far more complex and too far abstracted (how often do you really care about anything other than the latest value and maybe the previous one?) or with proxy based systems that have too much fragile magic (valtio, mobx) or require wrapping your components and going all in on oop (mobx)
To me signals hit the magic spot of reactive without being overkill and keep code testable in smaller units while retaining performance benefits of surgical updates
I like xstate in theory — it’s a good way to think about complex state transitions — but in at least half of cases in practice where you aren’t interested in a derived value, someone is storing a value/ getting the latest value or toggling a boolean and it’s just such overkill for that. The reducer pattern itself doesn’t meaningfully show up much for similar reasons. The other common cases are with fetching states (idle, loading, refetching, success, error) but you often end up wanting things like cache management or maybe even optimistic updates so eventually tanstack query covers that ground better than rolling your own.
As someone who created those horrifying RxJS monstrosities, I agree with most of this, which is why I caveated my concerns. Tanstack Query simplified a lot of these issues—separating server state and caching from client side state was a huge boost. I’m mostly coming from the perspective of someone who just inherited a Jotai code base with 200+ atoms and trying to wrap my head around it. Any library poorly used can lead to a mess though, so not going to claim it’s a problem inherent to all atom based approaches.
Re: atoms + learning curve, this is why XState Store exists, which supports both XState-style state updates and atoms: https://stately.ai/docs/xstate-store
I also like the approach of Svelte, and realize that sometimes a full state machine isn't needed. I don't think that atoms should be used everywhere, since updating state freely without guardrails just leads to disaster long-term.
Fine-grained reactivity (ie Knockout) was a thing well before React. If anything, React was a response to the deficiencies of fine-grained reactivity.
According to a resonating reddit comment, Svelte isn't more popular because it's simply too late; React and Vue got there early and got good enough, so Svelte can't really get as big as them.
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...
It's neither true that Svelte has few users or that we can easily break things. Tons of sites are built with Svelte like Yahoo Finance and Apple Music. Svelte 5 was the only big change in syntax in the past five years and we made sure that there's a good migration tool, etc. to minimize the amount of hardship and upgrade might cause. As a result the majority of users have already upgraded to Svelte 5.
That being said, Svelte absolutely does continue to innovate. We'll be introducing a new async primitive, RPC mechanism, etc. in the near future: https://m.youtube.com/watch?v=1dATE70wlHc
I think svelte, especially now svelte 5, will “win” because it doesn’t fight with vanilla web dev it just beautifully supplements the short comings of rolling plain html, css, js.
This is coming from someone who is no way a front end dev, but svelte 5 in particular is just so easy to get started with and has the most sane approach to reactivity and syntax compared to the other frameworks I have tried, and it seems like it is in the best position to grow with the web as well.
I am surrounded by geniuses.
So I will stop trying to be like them. I can't.
I'll just keep my head down and write my little apps for fun.
IIUC this is how VanJS works.
Man I don't even know why I write any code anymore. Everyone's already done everything.
I would recommend to not make a web framework with the idea of it being popular, like competitive with react. It’s much better to make a library that works with react / vue / svelte and see if that can become popular.
There are enough web frameworks. If you make a blog post where you state what limits you have with the current state of web technology, and you describe it really well, I’m sure someone will be able to point out how there is a web framework that deals with that. Or a way to implement that in current web frameworks.
> 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
That is essentially what Signals are, including directly setting .textContent when possible.
This model actually predates all of this and was used way back, in Backbone.js and other pre-react frameworks, except we didn’t have JSX or virtual DOM at the time.
I remember Backbone using two-way bindings, which I think is more complicted than what my experiment does:
You might be thinking of Knockout.js. Backbone used a manual event-driven approach where you'd wire up each component to a model/observer that you called .set(value) on. Except it was a lot more verbose, and because you'd be using chunks of string templates for rendering, it wasn't very fine grained — basically how far up the tree you added the subscriptions defined the update granularity. Most importantly, no incremental rendering or virtual DOM meant manual management for any input states, and the lack of a defined render lifecycle meant it was hard to keep track of updates and very easy to get into infinite recursion loops.
As someone else mentioned in this thread, the main innovation in the React era was actually it's sister library Flux which brought the idea of a unidirectional data flow into the picture, later inspiring Redux et al. We are now getting past the immutability detour and keeping the best of both worlds, maybe.
I think it is useful to say the blog post is using svelte 4, and the svelte 5 docs mention:
“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
I also like svelte quite a lot although I was/am genuinely a bit confused as to how to join svelte to some external [state machine / business logic]. I ended up with runes basically infecting the entire codebase, but presumably a proper boundary must be possible?
For complex things, I came up with a pattern that stores the state externally from the components in a single centralized file. So the components just become simple shells that render the state and forward events. (All the complex business logic can be tested without the DOM/headless browser.)
I call it "nation state" because it groups sets of related variables together in a scope between local and global.
I implemented the pattern with Svelte runes, but I think it could be implemented with anything; even React.
I went into more detail here (with live example/code): https://www.reddit.com/r/sveltejs/comments/1dgf8la/comment/l...
Yes this is the way to do it, global-ish state files with getters and setters. I’ll have a .svelte.ts file (or a few of them) with a typed state object, maybe a function for refreshing it or syncing it with a backend api, import the state all over the place.
Might be an anti pattern but it works really well.
I think I follow but IIRC my problem was something like that the getters and setters had to be quite "flat". if they weren't they would recursively infect everything top-down and then not work anyway because of boundaries in the deep reactivity.
> runes basically infecting the entire codebase
Yeah sadly the stores the author talks about here aren't the right way to do things anymore in modern svelte and they're all-in on Runes.
Stores were a big part of the reason I liked svelte; they were so conceptually simple, extensible with plain JS, and made interop outside of Svelte trivial without the Svelte magic leaking out.
They're still in Svelte, but they mix poorly with runes and are basically unsupported in runes mode. I opened up a bug about store behavior not working like it used to when mixing with runes, and the response was pretty much "yeah we don't expect it to work like that anymore when runes mode is enabled".
I don't even mind the runes I just don't get the impression from the docs that anyone has a clear feeling about how to actually use them e.g. forget the toy examples, suppose an alien has given me clump of minified business logic and we have to make it work.
Yeah, I try build an dashboard admin that has complex state passing into each other
and its not elegant, lets call it that way
The problems with these examples in my opinion is they often extend extremely trivial examples of problems to large, complex applications with a lot of assumptions about the problems those large, complex applications are likely to have.
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.
> 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.
AKA, React is accidental complexity. Solving accidental complexity issues may be required some time, but more often than not, it's just something you endure as the alternative choices are not that much better.
Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).
State management and optimized DOM manipulation can be achieved with vanillajs nowadays and I'm not saying that as a purist, it is just good enough that React is not needed. To help a bit with the ergonomics, I use lit-html/uhtml for the templating but they are both based on template literals, a native JS feature.
> Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).
The essential complexity was the interactive need of your UI. Any of the current web framework can be a solution. The only reason to go for React is hireability (almost anyone knows it) and devex (so many prebuilt components). But it's not like that the others are so hard to learn and components are hard to build.
I think we need to be clear about what scope we are talking about. A full fledged data-heavy B2B application, or something simpler like a web shop?
[dead]
Small critique: you probably want its (possessive of "it") in the title rather than it's ("it is") as in:
> I like Svelte more than React (its store management)
With the original title, it's perfect, but after the edits its coherence is a little fractured...
Honestly I don't love HN's title edits. Why can't we have nice blog titles that start with why?
Ironic that this is one case when you don't use an apostrophe to indicate the possessing entity. I suppose the rule is possessive nouns only, not pronouns.
Correct: when it's possessive, its form of it is its not it's.
Easy mnemomic: the apostrophe is for a missing letter, I.
as a non english native, i find it incredible how many native english speakers do this mistake
If enough of us make this mistake then maybe the prescriptive half can drop the whole "possessive pronouns don't get an apostrophe" rule altogether :D.
The same goes for "alot", avoiding the use of "whom", and so on - I ain't gonna give up on them!
I think they've given up on this, it's ubiquitous. I've recently noticed that a CLIP model (a neural network for image understanding) gave me image descriptions using "it's" where "its" would have been correct. Hundreds of thousands of dollars to train the thing; no one noticed, no one cared ¯\_(ツ)_/¯
Also `a lot` not `alot`
There's an issue when integrating Signals (or Stores) directly into templates. TypeScript becomes unable to track how bindings relate to each other.
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:
Isn't `useContext` the builtin React alternative to that issue?
Yes but they will rerender from where the context was created not where it's used, so you can get a lot of UI renders.
I think the new memo compiler address' this in the most complicated way possible.
That's simply not true.
In the above example, the Provider re-renders, but it's children remain unchanged.> Yes but they will rerender from where the context was created
Wow that's really bad and make it basically useless.
A re-render in React is not as heavy as you'd think it is. It's painting the DOM that takes resources, and people conflate the two. But if your whole component re-renders because of a change in context, yet nothing on the page changed, you will likely not notice the render even on low-end devices.
I still think Zustand is the simplest state management, while staying efficient. It's similar to the old Svelte stores. But I have used many state management tools and the re-renders were not the problem when it came to speed.
not if the compiler stops the unneeded re-renders.
A "compiler" to solve the issues the library created, awesome. It doesn't solve many re-renders tho, as React re-render full components, not only the HTML/Text Nodes that changed.
For generic browser based application I am in favor and am using domain specific libraries like three.js and purposely made web components. For the rest modern javascript works just fine. I just do not see the value of those framework monstrosities and build processes. They might be solving some problems for companies of Meta's scale but on small dedicated teams in my opinion it is just waste of time and money for no tangible benefits.
If you're writing Svelte code today and you need shared state, I would recommend you start by looking at the Context API (https://svelte.dev/docs/svelte/context). For manual control of data updates you'll probably still want to use Stores (SvelteKit does!) but I'd start with Context first.
Man people are really missing out on Vue and Pinia.
Pinia is so low ceremony and "just works"; it makes state management concerns practically disappear.
I had never heard of Pinia. Visited their landing page [1] and there's a button selling a course on how to use the library. There's a CTA for the course when you go to the Guide page as well. Very strange!
1. https://pinia.vuejs.org
In 2018, I taught Vue workshops where I memorized a Vue enabled html page and went through links from the homepage. Since then, Vue took permutations of options/composition, js/ts, Vite/whatever and deferred documentation to Vue teaching sponsors.
Try it. No course needed. Whatever you learn in the first hour scales to the 100th hour.
That's the best kind of simple.
My only gripe with Svelte is that it’s not JavaScript.
There’s an arcane layer of $yntax to mediate and a lot of flexibility and intuition is lost as a result.
You should look at solid-js in that case, tho it uses custom jsx transform
voby.js looks neat
It wasn't like this before. Try Svelte 4
Svelte stores just sound like adding Redux to React, which used to be in vogue then stopped being in vogue and I guess this blog post marks them being back in vogue.
The blog post compares an example using hooks to pass in a state and update function to a child component. It then compares that to a Svelte component which contains a state variable.
Those two examples aren't equivalent because any parent component wrapping the Svelte component doesn't have access to the state whilst App (in the React example) does.
For the Svelte example to be equivalent, the component would have to export the store.
A minor gripe but the hooks vs Svelte state is pretty minor issue in itself.
the end example is the same as zustand, no?
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
[dead]
[flagged]