Ryan Carniato
@ryansolid.bsky.social
got signals?
https://www.youtube.com/@ryansolid
https://dev.to/ryansolid
@solidjs.com @sentry.io
previously: @netlify.com @markojs.com
https://www.youtube.com/@ryansolid
https://dev.to/ryansolid
@solidjs.com @sentry.io
previously: @netlify.com @markojs.com
I've noticed this trend is just about being a year or 2 behind but the later you come the harder it is to be at the same place at the same time milestones. Like Vue 3 years in looked a lot different than Svelte, and Svelte 3 years in looked a lot different than Solid 3 years in etc..
November 12, 2025 at 11:04 PM
I've noticed this trend is just about being a year or 2 behind but the later you come the harder it is to be at the same place at the same time milestones. Like Vue 3 years in looked a lot different than Svelte, and Svelte 3 years in looked a lot different than Solid 3 years in etc..
Yeah it continues down the line. I guess it's part of the inverse introduction issue. Like the later the framework is introduced the harder to get any sort of traction. Like Qwik and Ripple have it worse than us (if not for their creators having built other frameworks).
November 12, 2025 at 11:04 PM
Yeah it continues down the line. I guess it's part of the inverse introduction issue. Like the later the framework is introduced the harder to get any sort of traction. Like Qwik and Ripple have it worse than us (if not for their creators having built other frameworks).
Like we wrote our own deployment setup, then switched to Vinxi so we could universalize server functions. This inspired Vite to change in v6, and now there are server functions/component support core to it, so other frameworks can add those features. Now we are switching off Vinxi to pure Vite.
November 12, 2025 at 11:01 PM
Like we wrote our own deployment setup, then switched to Vinxi so we could universalize server functions. This inspired Vite to change in v6, and now there are server functions/component support core to it, so other frameworks can add those features. Now we are switching off Vinxi to pure Vite.
I was just curious. I do think with the number of times we've changed the internals there is a perception. It's just funny because we did so to support our goals. By demonstrating that caused change in the actual ecosystem that other tools can leverage when they later leverage the same features.
November 12, 2025 at 11:01 PM
I was just curious. I do think with the number of times we've changed the internals there is a perception. It's just funny because we did so to support our goals. By demonstrating that caused change in the actual ecosystem that other tools can leverage when they later leverage the same features.
This is what I was refering to: github.com/webcomponent...
GitHub - webcomponents-cg/community-protocols: Cross-component coordination protocols
Cross-component coordination protocols. Contribute to webcomponents-cg/community-protocols development by creating an account on GitHub.
github.com
November 12, 2025 at 10:50 PM
This is what I was refering to: github.com/webcomponent...
Yeah I am not sure. I know what you are talking about. Might be in the name. Like doesn't stick with people. We haven't put anything into marketing, but I can't imagine Svelte has done much. But when you look at downloads on npm, I'd say more people knew about Svelte at same thresholds.
November 12, 2025 at 10:48 PM
Yeah I am not sure. I know what you are talking about. Might be in the name. Like doesn't stick with people. We haven't put anything into marketing, but I can't imagine Svelte has done much. But when you look at downloads on npm, I'd say more people knew about Svelte at same thresholds.
Is there something you feel lacking in SolidStart? By my best estimate other frameworks keep grabbing up our features.
November 12, 2025 at 10:46 PM
Is there something you feel lacking in SolidStart? By my best estimate other frameworks keep grabbing up our features.
My writeups on the idea so far:
Designing Async First Framework
hackmd.io/@0u1u3zEAQAO...
Different Take on Async/Concurrency?
hackmd.io/@0u1u3zEAQAO...
Deferred Disposal Reactivity
hackmd.io/@0u1u3zEAQAO...
Designing Async First Framework
hackmd.io/@0u1u3zEAQAO...
Different Take on Async/Concurrency?
hackmd.io/@0u1u3zEAQAO...
Deferred Disposal Reactivity
hackmd.io/@0u1u3zEAQAO...
November 7, 2025 at 11:13 PM
My writeups on the idea so far:
Designing Async First Framework
hackmd.io/@0u1u3zEAQAO...
Different Take on Async/Concurrency?
hackmd.io/@0u1u3zEAQAO...
Deferred Disposal Reactivity
hackmd.io/@0u1u3zEAQAO...
Designing Async First Framework
hackmd.io/@0u1u3zEAQAO...
Different Take on Async/Concurrency?
hackmd.io/@0u1u3zEAQAO...
Deferred Disposal Reactivity
hackmd.io/@0u1u3zEAQAO...
Every 5 seconds we navigate to the next page, loading more data. The counter continues to log from the previous page.
This is a non-visual version of this example when switching between "uno" and "dos". What's missing is no explicit Transitions.
stackblitz.com/edit/github-...
This is a non-visual version of this example when switching between "uno" and "dos". What's missing is no explicit Transitions.
stackblitz.com/edit/github-...
Solid2 Experiments Tabs - StackBlitz
Run Solid2 Experiments created by Ryansolid on StackBlitz
stackblitz.com
November 7, 2025 at 11:13 PM
Every 5 seconds we navigate to the next page, loading more data. The counter continues to log from the previous page.
This is a non-visual version of this example when switching between "uno" and "dos". What's missing is no explicit Transitions.
stackblitz.com/edit/github-...
This is a non-visual version of this example when switching between "uno" and "dos". What's missing is no explicit Transitions.
stackblitz.com/edit/github-...
No compiler. No transition wrapper. Just concurrency and async by default in a few hundred LoC. This is not the user's API. It is a proof of concept built on @milomg.bsky.social's R3, a new more performant approach to Signals, that propagate in a single pass while maintaining guarantees.
November 7, 2025 at 10:28 PM
No compiler. No transition wrapper. Just concurrency and async by default in a few hundred LoC. This is not the user's API. It is a proof of concept built on @milomg.bsky.social's R3, a new more performant approach to Signals, that propagate in a single pass while maintaining guarantees.
Two really good examples are in React:
Splitting tracking/deps from their side effect.
Not apply the value immediately after `setState`
I've always been able to argue correctness for these, but chose differently for convenience. But what happens when ambition grows and convenience turns liability.
Splitting tracking/deps from their side effect.
Not apply the value immediately after `setState`
I've always been able to argue correctness for these, but chose differently for convenience. But what happens when ambition grows and convenience turns liability.
November 7, 2025 at 8:05 PM
Two really good examples are in React:
Splitting tracking/deps from their side effect.
Not apply the value immediately after `setState`
I've always been able to argue correctness for these, but chose differently for convenience. But what happens when ambition grows and convenience turns liability.
Splitting tracking/deps from their side effect.
Not apply the value immediately after `setState`
I've always been able to argue correctness for these, but chose differently for convenience. But what happens when ambition grows and convenience turns liability.
I think implicit derivation is actually a lot easier here. If you ignore the syntax it's a bunch of assignment statements. That plays to comfort with procedural things. Old Steve Sanderson quote (Knockout.js): stackoverflow.com/a/6797091
What's the difference between Knockout.js and Rx.js?
Does anyone know the differences between RxJs and Knockout? To me on the surface they seem to be trying to solve the same problem, to build an event driven UI. But someone who has had experience ...
stackoverflow.com
November 7, 2025 at 5:32 PM
I think implicit derivation is actually a lot easier here. If you ignore the syntax it's a bunch of assignment statements. That plays to comfort with procedural things. Old Steve Sanderson quote (Knockout.js): stackoverflow.com/a/6797091
That's part of the debate. Implicit obvservation isn't a problem in React and yet that is what everyone complains about. Ironically libraries with implicit deps in effects rarely hear complaints. That aside, this debate matters a lot less when people aren't overusing effects.
November 6, 2025 at 10:25 PM
That's part of the debate. Implicit obvservation isn't a problem in React and yet that is what everyone complains about. Ironically libraries with implicit deps in effects rarely hear complaints. That aside, this debate matters a lot less when people aren't overusing effects.
Explicit vs implicit deps are a debate. But most people debating it are doing so for superficial reasons. The real problem is what you do with the effects. Writing a Signal in createEffect is only narrowly better than what happens in React and probably should be avoided most of the time.
November 6, 2025 at 9:11 PM
Explicit vs implicit deps are a debate. But most people debating it are doing so for superficial reasons. The real problem is what you do with the effects. Writing a Signal in createEffect is only narrowly better than what happens in React and probably should be avoided most of the time.
Yeah I shouldn't say no talk pre-hooks. This was like the 2016-17 conversation. Around the time React Native came out. People were hitting performance issues and coming up with solutions. Hooks were when suddenly it was everyone's consideration as a baseline.
November 6, 2025 at 8:14 PM
Yeah I shouldn't say no talk pre-hooks. This was like the 2016-17 conversation. Around the time React Native came out. People were hitting performance issues and coming up with solutions. Hooks were when suddenly it was everyone's consideration as a baseline.
Yes, but why do we reach for it to write to state when we could derive? I think about this a lot. React doesnt want you to write to a bunch of state in effects, nor does any framework. I think it starts with how we set up our state in the first place.
November 6, 2025 at 8:09 PM
Yes, but why do we reach for it to write to state when we could derive? I think about this a lot. React doesnt want you to write to a bunch of state in effects, nor does any framework. I think it starts with how we set up our state in the first place.
That is fair. Probably less React's API at the time but the language we used to describe UI. Signals back then still had computed values, but pre-hooks, no one was talking about memoization. That's the point at which dependencies become obvious. No one was paying attention to their messy state.
November 6, 2025 at 6:46 PM
That is fair. Probably less React's API at the time but the language we used to describe UI. Signals back then still had computed values, but pre-hooks, no one was talking about memoization. That's the point at which dependencies become obvious. No one was paying attention to their messy state.
If it didn't need to exist it wouldn't. But it does. It is too easy to blame `useEffect` itself to be the square hole. Yes Hammers exist. While it is easy to blame the design, what we need is to be able to identify why this happens. So we can encourage better patterns.
bsky.app/profile/seba...
bsky.app/profile/seba...
The React core team when they see devs using useEffect
November 6, 2025 at 5:31 PM
If it didn't need to exist it wouldn't. But it does. It is too easy to blame `useEffect` itself to be the square hole. Yes Hammers exist. While it is easy to blame the design, what we need is to be able to identify why this happens. So we can encourage better patterns.
bsky.app/profile/seba...
bsky.app/profile/seba...
This isn't a React only problem. Some tools better encourage derived state, but none are immune. What's scary is that some tools don't have a concept of derived state. Early React didn't, which speaks volumes to how we got here. Let's learn from this and not repeat past mistakes.
3/3
3/3
November 6, 2025 at 4:41 PM
This isn't a React only problem. Some tools better encourage derived state, but none are immune. What's scary is that some tools don't have a concept of derived state. Early React didn't, which speaks volumes to how we got here. Let's learn from this and not repeat past mistakes.
3/3
3/3
And once you start down that path it becomes harder to refactor because you can't see the dependencies. You can't just look at the data declaration and be like "oh it depends on this." You have to find all the places you write to it, what those locations depend on, and what writes to those. 2/
November 6, 2025 at 4:41 PM
And once you start down that path it becomes harder to refactor because you can't see the dependencies. You can't just look at the data declaration and be like "oh it depends on this." You have to find all the places you write to it, what those locations depend on, and what writes to those. 2/
You tend to not be like why is this running too much. It is way more common in Solid for something not to update. So instead of walking down from the write you walk up from the read. It is the exact opposite direction. Which admittedly bottom up probably is less familiar than top down.
November 4, 2025 at 5:38 PM
You tend to not be like why is this running too much. It is way more common in Solid for something not to update. So instead of walking down from the write you walk up from the read. It is the exact opposite direction. Which admittedly bottom up probably is less familiar than top down.
It is odd to think about Solid in those terms because it doesn't tend to oversubscribe. Where in React co-location decides so you always need to be aware of the components re-running. If your goal is to stop things running coarse grain is more straight-forward. But that is rarely our problem.
November 4, 2025 at 5:38 PM
It is odd to think about Solid in those terms because it doesn't tend to oversubscribe. Where in React co-location decides so you always need to be aware of the components re-running. If your goal is to stop things running coarse grain is more straight-forward. But that is rarely our problem.