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?

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

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.

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

I have a proposal for a new approach to front-end components. Even used it at a big client in production.

Want to put it on arxiv[1] before showing it to the world, but it's largely impossible to find an endorser unless you're active in academics already.[2]

Academics in a nutshell: the largest number of papers are authored by recent graduates with little to no industry experience.

Now, remember just how clueless your recent MSc graduate was when they started their first job in your organisation? Yeah - those are the types of authors driving state-of-the-art in SE.

---------------------------------------

[1] I have my reasons. If you're an endorser for software engineering, DM me.

[2] Academic gate-keeping got stupid, then pushed past to ridiculous, and appears to be now accelerating over the madness event-horizon.

I personally found Svelte much more intuitive than React.

Code first, then markup, then style.

React I have always just found a bit confusing and annoying.

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.

https://hono.dev/docs/guides/jsx-dom ?

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.

[0] https://github.com/sveltejs/svelte/discussions/10085

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.

Edit to add: if you dislike JSX I'd guess you would probably prefer Svelte over Solid.

They are pretty close in mindset (how state works), but Svelte is more established, better polished, has better docs, with a larger community, and of course, great animation / transition support. Svelte 5 does not have dev tools at the time of this writing, just like Solid. SFC is great, Solid has no comparable offering. It also has robust error handling, better than Solid.

That said, Solid has a way better Tanstack Query implementation. (No idea why we still don't have a proper Svelte 5 version today.) It is reasonably close to React that you may feel it should be easy to switch – though that is deceptive. Most of the work is not in the templates but in how the state works, and for this reason it is easier to port Solid code to Svelte or Vue than to React. Developing in Solid is smoother, because it is not a custom template, but just TypeScript. Less concepts to learn, if you are well versed in React.

Both can be good choices for different use cases. And then sometimes React is the right choice.

Solid, Vue, Svelte all have capable SPA frameworks and component libraries

You just make whatever it is you want in HTML and make it reactive (put it in a file with the right extension and add the svelte-specific reactivity you want).

It's simple/straightforward, does exactly what you want, and instead of spending time mastering the API of some component, you mostly spend time using the HTML/JS/CSS you already know.

But, of course, there's the option you have when using a non-React library in React: on mount, you instantiate the library in a ref, and then you use effects to turn reactive state updates into library invocations.

For example, wrapping https://datatables.net/ if there were no React adapter.

I have used agGrid and eCharts with Svelte. Doesn't get any simpler. With Solid, Vue and Svelte you can integrate vanilla JS libs easily.

I tend to use Svelte without component lib or DaisyUI. After all, those libs are technical debt. Also, the native HTML 5 elements / browser APIs are pretty complete these days (dialog, popover, ...). If I was to chose one I'd probably go with Vue and PrimeVue.

The deal is that your `props` parameter is reactive. If you use `props.x`, and the value of `x` later changes, that bit of your component will update.

The catch is that you have to access it via `props` -- if you extract it, e.g. "const { x } = props", subsequent uses of `x` aren't reactive. Sometimes that's actually what you want, sometimes not.

Like you, I ended up turning lots of props into accessor functions -- `props.x()` -- so it's clear exactly when they're being used. This isn't necessary if you're careful to access via `props` and not extract fields prematurely. But sometimes I like being explicit about it, so I still sometimes use function props.