Solid.js feels like what I always wanted React to be

There are proposals for this and most of the other issues I have with web components. But they all feel like issues that could have been covered from the beginning.

Also if you go all Lit on an app with many nested shadow doms it becomes fairly painful to test with tools like cypress.

  {...map  }

It depends a little on the complexity of the rendering for each item, and where you are fetching the data from, but when you’re into thousands of records you’re very likely to need at least some partial rendering. Suppose each record’s data is one kilobyte (I’ve seen far lower and far higher), then one thousand records is already one megabyte, which for many people will take multiple seconds to transfer, so you’ll still want to load the visible records before fetching more, or do streaming parsing of the records as they come in. And that’s ignoring the backend’s performance on fetching records, which must be taken into account too.

People are certainly often too eager to reach for virtualised lists, or worse still lazy loading without reserved scroll height, but even at a thousand records with simple rendering they’re still probably generally warranted—fast computers can cope with comparatively little visible difference, but on slower ones (especially older and cheaper phones) you’ll easily feel the difference. Memory usage can also be a concern for larger quantities of data and DOM (1000 × 100KB = 100MB).

I’m saying all this as one that scorns React and VDOM stuff in general as unnecessary performance overhead, and likes to use Svelte and plain JavaScript and things like that (or better still, to eschew JavaScript); and who worked on Fastmail’s webmail, which certainly uses such progressive-loading lists, on a precise-DOM-updates framework that cares significantly about runtime performance. React and its ilk are certainly particularly prone to using virtualised lists as a crutch to work around their shortcomings.

All that being said: yeah, I wish things like Discourse would stop doing aggressively lazy loading when there aren’t even several hundred comments in a thread. Render just the things on screen to begin with, if you must (though it’d be better to just send real HTML from the server and let the browser take care of all this, even if it complicates your JavaScript loading), but then load all the rest straight away so that I’m not penalised just because I’m on the other side of the world from the server, and let the browser handle in-page search.

At the time the promise of React was very far-fetched: using JavaScript generate your HTML markup. I actually was really adamant to use React and held off on it for a long time. However, once I gave it a fair shot, I was blown away by how intuitive it felt to use. I think the mental models it champions really helped drive its adoption.

While it was a pleasure to use, I was always wondering about other frameworks. But where React really locked me in was in its support. `create-react-app` was an incredible achievement, tbh. It made it so easy to start using React and have all of the bells and whistles out of the box without ejecting. And then, once you do eject, all you have to do is modify your Webpack configuration and you can get all of the additional stuff you want. The community also made incredible packages, like Downshift and Emotion, which further made React an attractive tool.

Over the years the React team has kept innovating it. Hooks made it so much easier to just write functional components, which has always been a core tenet of React (admittedly, Solid.js was using hooks before React). More recently, React added the concept of SSR/hydration to its framework. Initially a lot of people made fun of it because it was like we went back to HTML generation on the server, but then developers realized that you get the best of both worlds: immediate markup from the server with the reactivity and snappiness of a single-page application.

Because of SSR we now have innovative frameworks like Next.js and Remix. I know Vue 3/Nuxt.js exist now, and I know Solid.js exists now, but now that I've started using Remix I'm trapped in React land again (and honestly, couldn't care less). Remix is so freaking good and it's such a freaking improvement from when I did SSR in 2019 that it's hard to see myself using another framework.

This is kind of a bad answer, but at least I can show you why I'm locked into React I haven't tried any other framework (I also genuinely enjoy using React).

There are some things I don't enjoy about React. I don't enjoy how prevalent Redux is when developers think about global state. I also don't think contexts are a good enough solution (having a good reactive model would have definitely helped here). There are other things I don't like about React: I don't like how often it calls functions; it's extremely wasteful in large applications if you're not careful. And the semantics of `useEffect` are really murky for newcomers (and even sometimes for experienced developers).

If there is something like a Remix equivalent for Solid.js I'll give Solid.js a shot. But right now I'm in love with Remix. Maybe I can use Remix with Solid.js? I'll take a look.