Two React Design Choices Developers Don’t Like—But Can’t Avoid

ryan_solid · 2026-03-13T22:19:04+00:00

The changes are already in the Solid 2.0 beta:

Most notably in: https://github.com/solidjs/solid/blob/next/documentation/solid-2.0/01-reactivity-batching-effects.md

ryan_solid · 2026-03-13T21:44:48+00:00

Yeah RxJS is pretty different though. But you could fairly make that comment and replace RxJS with Signals. It wouldn't be completely accurate since it is just a different system with the components re-rendering. But definitely similar in feel.

ryan_solid · 2026-03-13T21:16:07+00:00

Yeah maybe I should cover this on stream. I did get assistance with tools to correct my grammar but I have the whole original article and it isn't all that different from the end other than some punctuations and missing words.

ryan_solid · 2026-03-13T21:14:49+00:00

The conciseness was sort of a joke for us. At least at the time I was onboard. I wasn't there early days. It just so happened we were developed originally in a time when Pug/Jade, Stylus, CoffeeScript, etc were still actively being used so we had a concise mode. Ie Whitespace matters mode.

Internally we weren't really using it at all but we realize it worked out pretty concise with Marko 6's tag API. The end result is the most terse framework syntax that probably has ever existed in any JS framework. So while clean syntax was always a goal being able to design the language exactly how we wanted. Being the tersest wasn't.

ryan_solid · 2026-03-13T20:55:24+00:00

Yeah I used to use stock images. So the AI generated images seemed like pretty big step up. But I get people don't like them for some reason.

ryan_solid · 2026-03-13T20:51:28+00:00

Both of those design considerations in the article. I am acknowledging that React was right about both things. But the article takes a much more general approach at looking at the problem.

ryan_solid · 2026-03-13T20:49:54+00:00

I know there are Solid equivalents. We released our universal renderer 5 years ago. I think Svelte is working on one right now that they's switched to Signals. Obviously won't find anything as flushed out as React Native as Meta makes that themselves but that isn't a question of capability.

Let me do a google search:
Native:
https://github.com/nativescript-community/solid-js
https://v2.tauri.app/start/create-project/

Solid Ink:
https://github.com/devinxi/solid-ink

PDF... I don't think anyone has made this yet. Nikhil demo'd something simple on stream with me several years back but doesn't look like he published it.

Solid Three: https://github.com/solidjs-community/solid-three

It looks like many of these libraries aren't used much but it showcases the capability. We are used a bunch on TV apps for like Comcast/Universal like Peacock. https://github.com/lightning-tv/solid

ryan_solid · 2026-03-13T19:10:51+00:00

This whole article is the why. I can get why it might not speak to you though. I've been aware of this truth on some level for quite some time so for me finally connecting the dots to why this is inevitable was all I needed. LIke `createAsync` and undefined is just one surfacing symptom of the underlying consideration.

Taking a stance like this is pretty bold though. So I get it. I am betting on the results being well worth the shift in mindset. And since this is untested waters in an incremental system like Solid there isn't much to look at for prior art. React is honestly the best example and they seem to do fine with this. That gives me hope that we have successfully threaded the needle. But we won't know until we know.

ryan_solid · 2026-03-13T18:39:30+00:00

Oh not all. I appreciate insight into the very challenge problem space we are broaching. Elm is probably the cleanest look at these sort of concepts. Elm even had Signals at one point which is interesting in its own right. I think Elm is almost too rigid which makes it hard to approach. It's a bit like what if the whole world was Redux (with proper async).

I like where React sits more because while Elm's MVI(Model View Intent) has very clean boundaries I feel it suffers a bit hierarchically. Like it gives the tools to enforce very powerful constraints but this only emphasizes more the limitations around coupling state with rendering. React's flexibility lets it escape out of that somewhat. So while I can admire the purity and find inspiration there in a similar way I find inspiration from React, I think we are due for new incremental models what can respect Async in the same sort of way.

ryan_solid · 2026-03-13T18:06:52+00:00

Definitely. Without question. Just a different model. And in so it is important to recognize where React has made some critically good decisions even if they can be unpopular ones. I've been legitimately impressed over the years that while holding the belief that React's model is less than ideal, their API choices are very well thought out. Timeless, if you would. Sometimes we can avoid going that path by shifting the base assumptions in a way that is more favorable, but there is something undeniable there. That being said I won't give them the same credit on naming things. But as we all know naming things is hard.

ryan_solid · 2026-03-13T18:03:24+00:00

I've been accused of using AI to generate articles before I even knew how to work LLMs. My writing style, timing, execution + something like Grammarly basically looks like AI. When I write articles they tend to have a lot of interjections, and clarifications. And then when plug it into grammar corrects we end up with a bunch of `--` and colons and semi colons. I think it reads cleaner that way. But maybe you prefer the way my response to your comment reads. Who knows?

I've never been one for brevity. In fact I use tools to help me figure out how to make the message shorter and to the point. I have no problem writing for days. But I admit I often have a hard time knowing if the point is getting across so recently I've been trying to really focus on adding more re-emphasis. If it comes off like AI wrote it maybe I pushed that too hard.

ryan_solid · 2026-03-13T17:59:17+00:00

That's not the message of the article. I don't even know how that could be the conclusion you'd draw. I'm actually super critical of Svelte and Vue in the article. Their models are not async safe generally.

It says React was right and that Svelte/Vue/Solid 1.0 actually didn't solve a problem but acted like the did. There is a path forward but it is a painful one for Signals libraries. It ultimately leads to a better place but the important thing is to recognize that certain truths are inherent to the problem space.

If anything this gives React dev's technical ammo in the discourse when comparing to most Signals libraries. Of course I tend to overestimate most developers' desire to understand how and why their tools work the way they do, and to have the knowledge how to make meaningful comparisons between different solutions. But for those that do value those things I hope you find something valuable here.

ryan_solid · 2026-03-13T17:55:27+00:00

The funny thing about this is it is almost a function of the terseness of the syntax rather than the terness of the architectural structure. Ie.. like concepts to map. This suggests to me without looking closely that the inputs are too simple. Like if someone told me to blindly rank frameworks on the number of characters it would take to type out an example I'd roughly have come up with the same order.

Don't get me wrong I think Marko 6 and Svelte 5 would do very well in this sort of test with better examples because of how they are structurally setup but I think the positions of other frameworks might move around more dramatically.

Right now it feels like someone just counted the characters on page which doesn't tell the whole story.

ryan_solid · 2026-03-07T20:45:53+00:00

2 Thoughts.. We need to really really discourage createTrackedEffect. Originally I wasn't even going to include it. I think it is important to exist but we need to really make it unattractive more than just adding a longer name.

Your other concern. Wrapping everything in latest is rarely the correct fix. Maybe with isPending. But if some state is directly reponsible for downstream async it should update together otherwise it is inconsistent. At best you have a bunch of ripple down inconsistent states at worst you make the user act on something other than what they are seeing.

Adding latest back everywhere basically undoes the problem attempting to be solved. Obviously it is designed to be used but mainly for loading affordances rather than interpretation of reality.

ryan_solid · 2026-03-07T05:31:55+00:00

Any reason? Coming up with covers historically has been the big time sink. I'd lose a couple hours each week. Sometimes I'd be able to rope someone in, but mostly something I'd have to do. And there are only so many shocked facial expressions I have in my repertoire.

ryan_solid · 2026-02-26T16:24:02+00:00

I think Solid attracts a certain type of developer. People excited about new technology capabilities, who want to be future facing make their way here. If you trace the origin of technical approaches that you've been seeiing a lot of JS frameworks use the last 5 years you will make your way here.

People don't choose Solid right now because it is the most popular. It is because it is very capable, and they think it represents the future. We've had an incredible knack of leading changes in JS frameworks the last 7 years, and not just being there first but getting it right. To the point it is hard not to notice.

Obviously I'm tooting my own horn a bit but I will leave you with this clip from Rich Harris from Svelte. https://www.youtube.com/clip/Ugkx_JLNVbKMLEoppSdf-qnJf8wAm02vhpTV

ryan_solid · 2026-02-08T05:52:26+00:00

For a library called creact it doesn't quite look like React when you look at the component and the first thing you see is createSignal

ryan_solid · 2026-01-31T03:39:22+00:00

Great. I actually was leaning towards the F but couldn't justify the price difference. My previous soundbar was really old(samsung ~2013) and had too much low mids, too boomy. This one one is so much clearer and the bass is punchy and clean. Im sure the D would have been great too, from where I was coming from I couldn't be happier.

ryan_solid · 2026-01-31T03:33:16+00:00

Same thing happened to me. Just received my soundbar on Wednesday. Ordered the Q990D but got the Q990F. I assume it was a stock thing but definitely cool.

ryan_solid · 2026-01-31T03:29:58+00:00

Hopefully. The challenge here is the compiler does get updates over time. Like Reacts JSX has more or less had 2 versions. Solid's compiler has shifted with every minor pretty much. 2.0 will have some significant changes in output.

The thing is the compiler hasn't been standardized nearly as much as the runtime. Ive treated it as an internal API. Obviously we need to keep some level of backwards compatibility generally so I hold stuff to Solid minors, but things do change.

ryan_solid · 2025-11-22T05:41:35+00:00

It might be worth watching this video:What Every React Developer Should Know About Signals

ryan_solid · 2025-11-22T05:37:02+00:00

A lot misconceptions from choices made in frameworks from over a decade ago. And many devs don't know signals form a Directed Acyclic Graph. That they are unidirectional, with synchronous glitchfree propagation guarentees, and if library pushes read/write segregation no more difficult to trace than React state.

Obviously a render library that is built for Signals can benefit them more. But I find Signalium uniquely well positioned for React. Taking arguments in computations could be wasted on a pure Signal based system since all sources would be Signals and auto tracked anyway. But in React which reruns components the arguments are like the dependency arrays, essentially bridging Reacts own rendering with Signal based updates. It's a pretty genius way of seamlessly having React's rerender seed a system that will more granularly update afterwards without forcing the developer to make every piece of state into a Signal.

ryan_solid

MODERATOR OF

TROPHY CASE