Hacker News Reader

Comment by mightyham | Hacker News Reader

Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future.

This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points of Solid's design. I've never run into a real world scenario where delaying computations seemed like an optimal way of solving a given problem.

View on HN

I'm curious which part of laziness are you concerned with? Is it delayed execution in events? It is just most lazy things run almost immediately during creation anyway, and on update everything is scheduled anyway. The only lazy thing we are looking at is memo's which while impactful isn't that different as the creation code runs. I guess the push/pull propagation is harder to follow on update then simple multi queue but in complex cases we'd have a bunch of queue recursion that wasn't simple either.

Wow, I never imagined you would respond to my comment, a little embarrassed ngl :D

I understand that under the hood Solid's reactive system is not quite simple; though, the mental model needed to use it, is very simple, which I greatly appreciate when building complex application logic on top of it. That's really my main concern: that one-way "push" semantics are easy to follow and think about, and adding new mechanics complicates that picture. It seems deceptive that what presents itself, at least conceptually, as just a value access, might now cause arbitrary code execution (another way of putting this is that it feels like it violates the principle of least astonishment).

As I mentioned before, I also haven't run into situations in practice where lazy memos seem like a desirable behavior. If I initialize a derived value, it's because I plan to use it. If some computation needs to be "delayed", I place it inside an if statement with a reactive condition, for instance, createMemo(() => shouldCompute() ? computeValue() : undefined).

All that's said, you've done a fantastic job with Solid. I hope you continue to innovate and prove my objections misguided.

I'll admit that hearing that "laziness" was something being explored for Solid 2.0 also made me uneasy. Like the OP, in my case I know it's because I'm worried that it will complicate working with Solid state in the same way that React's "concurrent mode" complicates working with React state. Really, I just hate React's "concurrent mode" and I really like the simplicity of working with Solidjs' state by comparison (if Solidjs has a similar concept to concurrent mode I haven't run into it yet).

All of this is to say that my own worries aren't based on any concrete objections, but a general fear of change since I like the current approach (and haven't run into any performance issues with it). Also, without knowing exactly what you plan on changing, the idea of introducing "laziness" seams like it could be a euphemism for "async" which feels like it would definitely make things more complex. Anyway, reading your comment makes me hopeful that my ambiguous unease is misplaced.

React has lived long enough to become the villain, and it's way too entrenched. It was certainly a very important step forwards in webdev, but it now probably has more gotchas than vanilla JS does.

I think it's just the lifecycle of craftsman tooling in general.

When everyone has experience with a tool, everyone can enumerate its downsides in unison, but we can't do that with new/alternative tools.

Whether we confuse that for the new tool having no drawbacks, or we're just tired of dealing with the trade-offs of the old tool, or we're just curious about different solutions, we get a drive to try out new things.

React always had gotchas, but the question is how tolerable are those gotchas compared to the gotchas of what you were doing before. And how tolerable are Solid's gotchas going to be once you discover them. Sometimes it's a better set of gotchas and sometimes it isn't.

Very balanced response, but in my case it's less about gotchas and more about APIs. I just think other frameworks have more intuitive APIs than react. Maybe this falls in the same category as a gotcha, but I feel it's a little different.

One of the best responses I have read on this topic. Thank you

It's also easy to confuse problems that arise from failing to adequately manage the gotchas with problems inherent in the tool itself. There's a subtle distinction there that's easy to miss, especially for those with a blame-the-system sort of attitude (which I don't entirely fault).

One company I worked for had a very slow frontend. It was common there to blame the slowness on React. "React is just kind of slow."

Another company I worked for had a much larger React-based frontend, and it was fast-loading and snappy by comparison.

The difference is that the second company had much more well-established good practices in its design system, the codebase, the enforced lint checks, and the general knowledge of its engineers. They avoided performance traps that caused multiple renders of things. (The first company's frontend would render a given screen 12+ times for some state changes.)

> The first company's frontend would render a given screen 12+ times for some state changes

Might just be me, but it feels like a good framework/library would put in a lot of work to avoid or at least alert about these kinds of issues so they can’t stay very long without being fixed.

I’ve seen the same in React (even infinite render loops which couldn’t be ignored and had to be fixed) and to a lesser degree with the likes of Vue as well.

I’m not sure what’s missing but having a tool that is easy to use in the wrong way doesn’t inspire confidence.

It's not that it's way too entrenched, it's just that people grew tired of constantly shifting frontend frameworks. Personally: I really didn't care who "won" that war, I just wanted to have a sane well-supported default without having to learn a new pattern every year to store page state or update an icon.

> I've never run into a real world scenario where delaying computations seemed like an optimal way of solving a given problem.

And even when it might be, Solid has always exposed fairly low level reactive primitives for those who want more control. Hopefully if laziness is added, it's in the form of new optional primitives.

> Having used Solid on a largish web product for over a year

I am curious about your experience in this regard. I've been aware of Solid for quite a while (and plenty of other non-React alternatives that on paper seem "nicer") but the problem I usually quickly run into after exceeding the complexity of a contrived demo app is the ecosystem not yet having a number of components, library wrappers, integrations, etc. that I use all the time.

Have you found the Solid ecosystem sufficient for whatever your needs are, is it fundamentally easier with Solid to integrate things that don't exist yet, or did you go into it less spoiled/tainted as I by reliance on React's ecosystem?

Not op, but I converted an online card game etg.dek.im from React to Solid. What helped is that I don't use any of other React libraries

Used to use redux, got rid of it. Used to use react-spring, got rid of it

I've found the ecosystem to be perfectly serviceable for every complex piece of functionality I needed to bring in: remote state, forms, tables, and routing, come to mind. Complex state management can easily be handled using the library's standard reactive primitives and the community "solid primitives" project has a ton of well made utilities so you don't have to reinvent the wheel for common use cases.

I'm not going to sugar coat it though, SolidJS is not necessarily a batteries included ecosystem. There is a severe lack of components/component libraries. Luckily integrating vanilla (or "headless") JS libs is dead simple once you have enough experience.

Cool. I am a bit of a minimalist (one reason I've never felt the most comfortable with React compared to some other things) and equally not interested in bloat and differing opinions/principles from using component libraries for everything (and I almost never use them for UI) but, yeah, I also don't want to have to write my own high-performance basics. A few years ago when using Vue for something, I had to detour a lot to writing things like virtual list components because at the time they were not available. (I see Solid has a few of those.) Not ideal for a tiny team or as a solo dev trying to make a dent in something in my off hours

> Luckily integrating vanilla (or "headless") JS libs is dead simple once you have enough experience.

Good to know. I expect to need to write my own wrappers for certain things that are more niche, but some frameworks definitely make it easier than others, and I do tire of wrapping the same 153 events and properties and such for some component yet again when [framework of the month] has an annoying way of doing this

For what it's worth, ecosystem is a valid concern, esp compared to React, and esp if dealing with more niche features. Even for something fairly generic like Virtual List implementations. Virtual Lists do exist for solid (specifically tanstack is the most fully-featured, albeit under-documented), they aren't as battle-hardened or as well-documented as their react counterparts. Specifically, I have thought about digging into VirtualList internals, because of a couple issues that I haven't seen in some other framework impls (granted, of most the complex generic ui components, virtual-list is literally the one issue I had with ecosystem).

Also, you'll definitely start seeing edges faster. Things like touch event libraries, animation libraries, maplibre/dataviz/etc. I'd say that the solid ecosystem is at the point where you'll see 1-2 libraries for most things, but if those libraries aren't quite right for you, you can very quickly find yourself digging deeper than you'd like.

That being said, as parent stated, integrating vanilla libs isn't so hard. And also, there is a... solid... amount of people building headless libraries specifically for the ecosystem, which are quite useful (For example, I recently came across https://corvu.dev, which I've started integrating here and there). What I mean to say is less that solid has a poor ecosystem, and more that there isn't the infinite easy-access vibe-code-able pop-in-lib-to-solve-your-problem ecosystem of react.

Even with the shallow ecosystem, solidjs has been quite enjoyable to me. Also, in the two years I've been using it, I think I've built up enough of my own personal ecosystem that I don't really need to reach towards external dependencies all that much, which feels very nice.

The SolidJS ecosystem is smaller but generally has more high quality libraries and more integrated.

Take a look at Solid Primitives: https://primitives.solidjs.community/

I've used Solid Primitives and white it's great, unfortunately it seems pretty dead. None of the primitives is "4 Accepted/Shipped" and many aren't even "3 Pre-shipping (final effort)".

Is laziness intended to offer primitives for suspended UIs?

I haven’t used Solid for a while and can’t recall if there’s a Suspense counterpart already. If not, this seems like a reasonable feature to add. It’s a familiar and pretty intuitive convention

Looking for this? https://docs.solidjs.com/reference/components/suspense

Ha! I’ve used this, too. I guess I’ve reached the senility phase of my mid life. Thanks for pointing me to that

React is, I am convinced, the new Struts only client side.

Struts was SSR before we needed a term for SSR. It had low productivity so it looked like it was doing well in the industry because there were so goddamned many jobs. But if you asked people you really couldn’t find many that loved it, and if they did it was a sign that maybe their judgment wasn’t that great, and you were going to be disappointed if you asked follow-up questions about what else they thought was a good idea.

It was killed by JSTL, which was one of the first templating systems to get away from <% > syntax.

I'm using SolidJS for Infumap (https://github.com/infumap/infumap), which is getting pretty big.

Two main comments that come to mind:

Because the state -> DOM mapping is non-trivial for my application, I ended up writing my own virtual DOM diffing code, a primary facet of React. I appreciate the ease of being able to circumvent this where it's not necessary and performance considerations dominate, though I admit i've not felt the need to do it anywhere yet.

The AI training data set for React is much larger. The models seem to do fine with SolidJS, though I suspect there is meaningful benefit to using React from this point of view.

Overall, I'm happy with where I'm at and I prefer the SolidJS way of thinking, though if I were to do it all over again, I'd probably just go with React for the above two reasons.

I was not expecting to loose karma for this comment!

I have a couple of years familiarity with SolidJS and thought the two key insights that came to mind from building a large project in it would have positive value.

Apparently not!

Reply on news.ycombinator.com