Solidjs: Simple and performant reactivity for building user interfaces

> I would say that the "market" doesn't agree with your thoughts on the matter

I'm well aware. :) But it wouldn't be the first time that large-scale groupthink has led an industry or society in the wrong direction.

The problem is that there is now an entire generation or two of frontend developers who are "senior" based on years of experience who have only known web development post-React. They're not really aware of working with anything other than a framework, what these frameworks and libraries initially set out to solve, whether those same problems still exist today, or what is possible with modern native web technologies. They in turn go on to invent new frameworks and libraries to address some of the shortcomings of what they're used to working with, but without considering the possibility that these massive frameworks might not be needed at all. This is why we need developers with experience in the early days of the web, those with different backgrounds, and those who are willing to rethink the modern approach from first principles, to guide the industry towards saner development environments, and more maintainable and performant projects.

Datastar, for example, takes a radically different approach, and while I can't say whether it's the right one for every project, the results speak for themselves. It powers projects that would be a nightmare to build, if not outright impossible, with any other framework, with incredible performance, all with a tiny fraction of code and complexity. It's not that Datastar is somehow magical—the author simply took a step back and used technologies that already exist, which no one else thought to put together in the same way.

> You can write MVVM as an unmaintainable mess also.

I don't disagree, but it's much harder to do than with most mainstream frontend frameworks. JSX by definition mixes different concerns, and leaves the door open to not care about this separation at all. The only unit of organization in a modern frontend framework is a "component"; a concept so nebulous to be practically useless. When everything is a component, nothing is, and you might as well not use it at all[1]. The only reason we do, is because we want to avoid code duplication. That on its own doesn't encourage designing applications with a sane structure in mind, and doesn't emphasize the idea that using different layers with separate concerns helps with reasoning and long-term maintainability. These are not novel ideas, mind you. They've existed for decades, yet after React we collectively decided to throw them out the window.

IMO frontend web development peaked around 2010 with Knockout.js. It provided just the right amount of abstraction to allow us to build highly interactive web apps without the maintenance problems of jQuery, and without the insanity of JSX, virtual DOM, diffing, reconciliation, SSR, bloat and supply chain vulnerability issues of incomprehensibly large dependency trees, etc.

[1]: You can see this confusion here[2]. They suggest separating components into "container" (or "controller") and "presentation" components, but then confusingly also say: "[container components] may contain both presentational and container components* inside", and that double asterisk is never addressed... Huh?

In practice, in all the React and Vue projects I've worked on (which admittedly isn't many; I don't consider myself a frontend developer), I've never seen this separation being followed, and components end up being a dumping ground for loosely-related content, behavior and style of things that exist on the screen.

Turns out that even the 2015 Dan Abramov article they link to[3] has an update from 2019 where he backtracks the separation suggestion. Wat. "Hooks" are supposed to be the modern solution... Yeah, sure, I'll trust you _now_, Dan.

But wait, actually, "signals" are the modern _modern_ solution![4] JFC, this is like a carousel from hell...

[2]: https://handsonreact.com/docs/component-architecture#contain...

[3]: https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

[4]: https://javascript.plainenglish.io/signals-a-performant-alte...

Yes, Solid is very fast, but Svelte's Signals implementation seems to be even more performant. [0]

I just loved the simplicity of using $: for deriveds and effects in Svelte 3 and 4. But after building a correlation matrix [1] and a work project with Svelte 5, I have to say that I really like it.

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

[1] https://covary.xyz

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.

Solid indeed does not have the same number of options that React has when it comes to UI component libraries. I've only used Solid on small throwaway projects, but I do like it better than React.

However, like you've pointed out, there's going to be things that you have to do yourself that in React you could likely depend on someone else for.

For tables though, I haven't used this in Solid, but it's pretty nice in general https://tanstack.com/table/latest

Yes, and you will probably get a little better at HTML/JS/CSS if you do not have to spend time learning a third-party component's API. Third-party components can also become unbearable if you have a very clear idea of what you want to archive.