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.

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

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

[dead]

[flagged]

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.

One of my biggest gripes about this is that the wire format for React Server Components is neither standardized nor documented. Every bundler has its own format [1], but what this means in practice is that every bundler wants to be able to "move fast and break things" and treat the format as an internal implementation detail, which in turn means that there's no reference implementation and no way to have interop between, say, a RSC "backend" and a non-JS-based frontend (or crawler/scraper), or to have a non-JS backend emit RSC-compatible updates. Or to be able to allow people to iterate on it with fresh JS server-side code, rather than needing to build around a bundler.

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

> I personally don't like that direction so looking forward to exploring new frameworks

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.

I've been using solidjs (via solidstart) for awhile on a medium sized project.

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

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

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.

> I personally don't like that direction so looking forward to exploring new frameworks.

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.

Yep. Solid js stays true to js. A div is literally a div. And you can use Solid without jsx, and used tagged templates if you so desire.

Never did I ever once think React would one day be compared to PHP.

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.

You can just use styled-conponents on React.

  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 personally don't like that direction so looking forward to exploring new frameworks.

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?

Amy thoughts on AlpineJS or RiotJS in this same realm?

> most importantly, it's just 1,823 well organized commits (1,329 of which belong to the creator). That gives me confidence to keep it around long term.

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

What about hono client side? Seems to have most React functionalities:

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

Sorry, but number of commits don't say anything about the quality and direction of a project.

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.

With Svelte anyway, a third-party component just gets in the way.

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.

Not much is going to compete directly with React's ecosystem maturity.

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.

Vue has a large ecosystem. A lot of very good component libs like PrimeVue, Vuetify, Quasar, NuxtUI, ElementUi ...

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.

Most of the modern front end frameworks can handle those use cases.

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

[flagged]

Looks like its still in the discussion phase, did not see a timeline but also did not read super close. Did learn about the tanstack-router which I had never heard of, so that was worth looking this up right there ;)

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

[flagged]

Ironically, mechanically Vue and Svelte historically were much closer to React. Vue has a similar VDOM and Svelte while compiled still had a rerun component model. It was only the past year about 6 years after Solid showed the way Svelte 5, and Vue Vapor got away from that and now compile down to what more or less Solid has been doing all along. Of course this is under the surface. But in many ways while Solid itself has stayed relatively small it has profoundly impacted the rest of the ecosystem in a way we haven't seen since React. From Vue, Svelte, to Angular, Preact, and Qwik all using Signals now. The average user of these frameworks probably has no idea but everyday all the non-React frameworks work more and more like Solid.

SolijS is just JS without much magic. It's simple, small and very fast.

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.

I've tried both and I much prefer Solid. The key advantage for me is that it's just JS/JSX -- you can use it in both your UI code and JS utility functions and it works everywhere. Svelte seems a lot more magical; your UI code is in a special language that looks different and works differently from JS utility functions.

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

so i managed to convince my company to try solid on a new project, pretty much on the basis of "this looks like react but solves many of our existing problems with react". since the JSX and project structure is basically the same, we could take our (pretty tiny at the time) demo project and do a 1:1 diff and show the differences inline. and it was pretty compelling! the code was simpler, and faster, and we still got to keep lots of the unique patterns/other stuff we were used to when creating react apps

I would not necessarily. It depends.

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.

I haven't used Solid yet, but it is commonly said to have "fine-grained" reactivity, compared to React, and better performance.

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

[dead]

It's likely that your React codebase is huge (I assume it's for work) and you're messing around with a toy Solid project. I'm sure once you get to the same scale and complexity of a Solid project, you'd feel the same way about whatever next framework you find

To me, no. It’s in the developer experience where Solid really shines.

React has to maintain a virtual DOM, which slows it down.

That's not quite right! I made the same mistake in a Solid project.

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.

Funny. To me JSX is a much superior language compared to HTML templating. And I would say it's provably so. You can do JSX-in-JS-in-JSX recursively in a way that is "natural" and "safe" and "maintainable". And with TypeScript you get great IDE support, ability to refactor and whatnot.

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.

Yes, it feels super natural, which is actually a good way to describe Svelte's overall DX. Part of the reason it feels so natural in relation to HTML is that Svelte treats it as "The Mother Language". [0]

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

Btw, you can use Solid without JSX and any build steps: https://www.solidjs.com/guides/getting-started#buildless-opt...

Svelte is fun

If you want to compare Solid to Vue, I think it is easier to just compare React to Vue. If you like React better, then you can compare React to Solid and see which you prefer. SolidJs is 90% similar to React in terms of DX, with only a coupler major differences.

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.

Both use signal-based reactivity, both are heavily optimised at compile-time to ensure only the parts of your app that need to well change at runtime.

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.

Vue is my framework of choice but currently working on a project with SolidJS. It's fine. To me it feels like React with the most objectionable parts removed. I haven't found too many painful bits, though there are some odd gotchas about destrecturing params losing reactivity.

From my modest understanding it turns how you use hooks on its head. React will run the functional component to render each time state updates, and you need hooks to cache and sync things (eg useCallback, useMemo, useEffect). Solid is the opposite I think, it executes only once, and you use hooks to set up bindings which run updates on the component.

Solid is fundamentally different from React - it compiles reactive primitives to direct DOM updates with no virtual DOM or re-rendering, whereas React re-renders components when state changes.

Solid js does basically the same thing as React (building UIs for websites) but the architecture and primitives are slightly different.

That has been my experience.

[dead]

Yes, what you're looking for is SolidStart (https://start.solidjs.com/)

Every app with state can benefit from reactivity. There are tradeoffs, that's for sure.

A shockingly underrated statement these days. Couldn't agree more.

I'm not sure how that's relevant to this post?

Here the creator of Solid compares it to Mikado: https://github.com/solidjs/solid/discussions/485

Deleight is faster than Mikado.

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

...when SolidJS isn't niche enough!

Performance is not necessarily worth maxing at all costs.

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