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.

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?

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.

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 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

https://github.com/solidjs/solid/discussions/2425

I personally am becoming dissolutioned with React because of this, as a former strong advocate.

Next.js and Remix - or whatever the hell it's called this week - are both over-engineered messes.

Yes, I'm aware that I don't have to use them, but they are where the momentum and energy of the community is being spent in recent years. And I do want a monolithic framework, I just want one that focuses on simplicity and ease of development rather than one designed to funnel me into using Vercel.

If I want to make an Erlang or Rust based system that emits RSC-compatible updates (which itself is an undefined statement) in real time, say - there's no way to do that without either having a JS layer as a separate microservice, or calling the code from JS in some way.

The PHP analogy is very much earned, in my view. It doesn't make it a bad choice for all projects, but it will tend to isolate the ecosystem from new directions.

[1] https://overreacted.io/jsx-over-the-wire/#server-and-client-...

Why? React core has been exactly the same as it was ten years ago. Building a React SPA has not changed significantly, other than the growth in third-party libraries that complement the Core.

Recent developments in React has been about enabling its usage in wider problem domains, but not at the detriment of its previous use cases, so why would that affect you?

> Portions of the react community are excited about how it's starting to feel more like PHP with the movement towards server actions in "client" code etc

Solidstart definitely pushes you to use their magic server functions. I used them at first - but increasingly I've been moving back to writing a normal, real REST interface on the server side. It still works fine, its just a few more lines of code to do it yourself. The biggest benefit is that I can control my HTTP verbs and headers. This lets me set up caching correctly, both in the browser and any intermediate caches.

> Things like Vue/Svelte where they mash together css and js in the same file if you want kind of turns me off.

Solidjs doesn't mash css and JS together. You usually use normal, real CSS or CSS modules. Eg:

    import styles from './style.module.css'

    function BannerComponent {
      return <div style={styles.bannerBar}>Banner</div>
    }

Reading that post the other day and seeing modern terminology being applied to old backend rendering was quite the experience. "Imagine on initial page load it returns the complete screen UI with all props and components already hydrated".

I remember those days but I remember some of the bad as well. I really started to hate that every UI change in the template/HTML meant changing the page controller to handle the new data. I specifically remember wanting some technology that allowed the UI to dictate what data it needed.

The pendulum swings though and it seems we are reversing course lately. Perhaps we land on a solid middle ground finally.

  const Button = styled.button<{ $primary?: boolean; }>`
    /* Adapt the colors based on primary prop */
    background: ${props => props.$primary ? "#BF4F74" : "white"};
    color: ${props => props.$primary ? "white" : "#BF4F74"};
    ...
  `;

  render(
    <div>
      <Button>Normal</Button>
      <Button $primary>Primary</Button>
    </div>
  );

Is that project even maintained still? GitHub looks...quiet.

https://krausest.github.io/js-framework-benchmark/current.ht...

Things the same as React in Solid: function-based components with hooks, JSX, overall "JS-first" (vs Vue which I'd describe as "HTML first")

Things different from React in Solid: "signals" instead of state (observer pattern), built-in components for rendering control flow (<Show />, <For />, etc), direct manipulation of the DOM. All these differences combine to the overall main difference, which is that React kinda revolves around an immutable re-render cycle where a function is re-run in its entirety to create a new vDOM representation each time, while Solid renders a component once then only selectively re-reruns parts of the component / mutates the DOM.

So I'd say pretty much the only similarity between Vue and Solid (contrasted with React) is the built-in components for control flow. Everything else is the same differences or similarities that Vue has with React.

Vue uses single-file components, SolidJS uses JSX. That has a surprisingly large influence on how you develop with the frameworks, because it's a lot easier to create new components if those components are just regular Javascript functions, as opposed to being new files with boilerplate. But the boilerplate also provides some standardisation which might be useful for larger teams.

Vue has a much larger ecosystem. Partly that's about pre-built components and utilities, but it's easy enough to build things yourself in both frameworks, and SolidJS in particular makes it very easy to incorporate vanilla JS libraries when necessary. However, if you've got a weird setup, it's more likely that someone in the Vue ecosystem has tried out that setup before and either documented it or raised all the necessary bug tickets to get it working.

Personally, I really like SolidJS - it's pretty small, it's very simple to understand once you've got your head around signals, and it scales up well from single interactive elements on a page to complicated applications. (Specifically: one project I work on at the moment is an Excel-esque application where SolidJS handles both the UI and the underlying reactivity of the application. I have only needed to think about performance in a couple of cases, the vast majority of the time, SolidJS can handle hundreds of thousands of cells without issues.)

That said, if you're working with newer developers or on a larger team, or if you're new to web development yourself, I'd probably recommend Vue just because there's so many more resources out there for it.

Genuinely curious: why does a low number of commits, and mostly commits from one person, give you confidence to keep it around long term?

React has been around for much longer than Solid, and also much much more popular, with many more contributors. It's also the pioneer of virtual DOM reactivity, when you're a pioneer there bound to be some trial and error.

It can also be argued that SolidJS has a higher bus factor, as it's still very dependant on the creator (Ryan Carniato).

Sharing my experience... A while ago, I wanted to build an app using SolidJS 1.4 but got stuck because of a list mapping bug, ie. child list not updating IIRC. I reached out to Ryan, he said that he knew about the bug and had a fix coming in the next release. I couldn't wait, so I had to port what I had to React and call it a day.

But like... can we stop having these reasonabe takes that's like "I like this better but oh no I need to remind you that in the real world it's tough until it's get real traction but I like it anyway" kind of argument?

Just say what you like and what you don't like and be done with it.

Nobody gives a damn about what you like what you don't like.

But everyone will give a damn about your opinions that consistently make their lives better.

So stop these "reasonable take" stuff ffs.

No need to trust my word, just look at the huge amount of code in JSX that the world is maintaining at the moment.

I would say the only problem is the performance cost that we have to pay for this - the shadow DOM and (as a result) the hooks mess that we have in React. But it feels more like a problem that needs to be solved in order to use the much superior way of writing code (JSX). Not the other way around (sacrifice JSX for performance)

And I get that it can be overwhelming if you still haven't made the "jump", it just doesn't sound fair to criticize something that you don't understand.

I also think that Svelte, having a compiler, seems like that it would have an edge in theory.

You can use signals and effects outside of components and it just works. You can even use a signal from the global scope within a component. Tracking of signals for effects and derived values is automatic. It looks very similar to React, but it's better in every way. Honestly the first time I'm happy with this kind of library. Don't need much more.

Edit: As for Svelte: like it too, but at least before Svelte 5 there were some footguns and differences between components and "normal" JS code. I haven't tried Svelte 5 yet, only watched some videos. From the looks of it would consider it as a good alternative.