Solidjs: Simple and performant reactivity for building user interfaces

With MVC/MVVM? Yes, but not all at once. That is, you focus on one layer at a time. You think about its inputs and outputs, and how it interacts with other layers. Then you follow the data to the next layer, and so on.

With JSX, or any project that disregards SoC, you're forced to think about all layers at once. You have to think about how the JS processes the data, and at the same time how this impacts the content and final rendering.

It would be like if on the backend you would mix business logic and data processing layers, or more accurately, put business logic AND your views inside your database. There are developers who don't mind or even argue for this approach, but most developers would agree that this is an insane way to build applications. Yet on the frontend, for some reason, everyone is fine with this.

To give a concrete example, take a look at this page from the React docs[1]. Ask yourself this: what is the structure of the page at any point in time? Is any component modifying data? What happens if it does? What happens if a component renders a structure that is incompatible with other components?

This is a trivial example, so some of the answers are evident, but in a real-world application these and many other questions are very difficult to answer. Especially by staring at the code during a review. I've found that the only reliable way to review code in a modern frontend framework is to run it locally, see what the behavior and rendering is, and correlate that with the changes. And, of course, since there is usually a complete disregard for UI and E2E testing of any kind, this process is error-prone and regressions are common.

> It’s a trade off between separation-of-concerns and locality-of-behavior.

These are often seen as opposing principles, but it's possible to have both. A single HTML file can contain HTML, JS and CSS. Each section has a single concern, but would you argue that LoB isn't preserved?

> any abstraction has a cost of increased cognitive load

None of these principles or models are abstractions. They're design patterns that suggest a certain way of thinking about and organizing an application that makes reasoning about it and maintenance easier.

> If I have to look at 5 files instead of 1, the 5 files better pay for itself in some way

Again, SoC is not about putting things in different files. It's about a logical separation between different parts of the codebase. Whether that happens in a single file or multiple is up to the team to decide.

[1]: https://react.dev/learn/thinking-in-react

React doesn't win speed races, but the mentioned slow-downs are rather extreme and would be noticeable.

I agree that one should benchmark against React-MUI as the baseline. In fact, that would give Solidjs a meaningful (less synthetic) benchmark, as in this case we have a wide range of non-trivial one-for-one components to compare with. A goldmine for performance testing.

If SolidJS could outperform React in these kind of workloads you would have a great proposition.

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.

Might just be me, but it feels like a good framework/library would put in a lot of work to avoid or at least alert about these kinds of issues so they can’t stay very long without being fixed.

I’ve seen the same in React (even infinite render loops which couldn’t be ignored and had to be fixed) and to a lesser degree with the likes of Vue as well.

I’m not sure what’s missing but having a tool that is easy to use in the wrong way doesn’t inspire confidence.