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.
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.)
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.
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?
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.
> 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
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.
Used to use redux, got rid of it. Used to use react-spring, got rid of it
Take a look at Solid Primitives: https://primitives.solidjs.community/
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.
Your "largish" could be 10000 daily active users, which is my medium, and small for someone else.
Or maybe your "largish" is 1000000 for a site with mostly static, cachable parts, but the the same people were to build the same thing for a different audience that require a lot of interactivity and things that are different to say they wouldn't make the same claims.
What are you doing and what is the HN community doing.
Sure, React has its own problems and I choose not to use it outside of my job now. But if you're to convince someone else that something is worth switching to in terms of TECHNOLOGY, we need more than feels, vibes, and anecdotes.
It's not that I think you're right or wrong. However, if you are going to go out of your way to make a technical comment to make the world better place (I hope that's what you want to do), it requires more than a 2007 effort for people who care enough to make a difference now: otherwise you're just another person defending what they like most without any real data.
Don't forget that anyone who has any real experience as a software engineer knows that every day is about making trade-offs. Think deeply about what why I say this and what this means. If you don't know why, I hope you will find out or you will stop sprouting cult-like nonsense until you know why.
When evaluating front-ends, wouldn't the concern be more "number of components active at a time", or "complexity of application state", etc?
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.
So solid didn't solve one of the biggest problems you have but you like it. It's fine that you like it and the philosophy, but can you expand on "I ended up writing my own virtual DOM diffing code, a primary facet of React"? It's like saying I like Solid but I had to roll my own on what React does best and it's not very convincing... Easy to circumvent something makes no sense when you could have chosen something else that does it out of the box?
For all we care React could solve 70% of these problems 2 years later. Or maybe another project that's entirely React compatible and perfect migration is facilitated by AI will come up.
You literally said AI is more compatible with React as a counterpoint to using Solid? I think not using something because AI is good at is a good thing for humanity, but what are you talking about in terms of an argument for Solid.
Nobody cares.
I mean well.
I don't mean to offend you and I think Infumap is cool, but I think for the reasons above you need to be more mindful about what you say. Don't try to please everyone -- most people don't care and the people who are most loyal to you don't care. Nobody cares what Infumap is built with: they care about what Infumap does for them and WHY you built it. The what is irrelevant.
Edit: Oh. All of your replies are like this. Please take a chill pill.
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!
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
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.
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.
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.
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.