Popularity is not Efficiency: Solid.js vs React.js

Introduction

Two well-known JavaScript frameworks and libraries used for creating user interfaces are React.js and Solid.js. Solid.js, a lightweight reactive library, prioritizes fine-grained reactivity and efficient rendering through a reactive programming model. However, React.js, which was developed by Facebook, is well known for its declarative architecture based on components and its handling of the virtual DOM (Document Object Model). Different approaches to state management and reactivity set these tools apart, even though they both enable developers to create dynamic and interactive web apps.

Efficient front-end development is necessary for excellent online performance. Rendering speed, bundle size, and developer experience are all greatly impacted by the choice of your framework, which is important when creating high-performing, user-friendly apps.

Comparing Features

In terms of the reactive programming idea, Solid and React provide good solutions. But the fine-grained reactivity architecture of Solid.js sets it apart; when there is a change in data, it updates only the necessary components. In scenarios with deeply nested components, this could result in better performance as compared to React's virtual DOM technique.

But with React, developers can build scalable and maintainable apps thanks to its virtual DOM and component-based design.Virtual DOM maximizes rendering efficiency by reducing the need for pointless re-renders.

React's virtual DOM is a copy of the actual DOM; when changes take place, React updates the portion of the copy that was affected. Next, it updates the real DOM with the portion of the modified virtual DOM that isn't present in the real DOM by comparing it to the previous version.

Performance Comparison

Web development relies heavily on rendering speed and optimization strategies, which Solid.js and React.js handle differently. Solid.js provides highly efficient updates with fine-grained reactivity, which is especially useful in complicated settings.

To optimize rendering for large-scale applications, React.js combines a diffing method with a virtual DOM and component-based design. The decision is based on the particulars of the project; Solid.js excels at exact reactivity, whereas React.js uses a virtual DOM method to provide efficiency for larger apps.

Real-world application benchmarks

JavaScript benchmarks are instruments for measuring the speed and effectiveness with which a JavaScript engine—such as the ones found in web browsers—can complete particular tasks. Benchmarks are used by developers and browser vendors to evaluate various engines, find places in the code where improvements are needed, and make sure JavaScript standards are being followed.

Though this benchmark compares a number of actions between solid and ReactJs, in this explanation I have thoroughly examined the solid-store, react-hook, and react-redux actions, offering insightful information on the create rows activities.

Duration in milliseconds ± 95% confidence interval (Slowdown = Duration / Fastest)

The average duration of React hooks is 45.6 milliseconds, and we are fairly confident that the true duration falls within the range of 45.3 to 45.9 milliseconds. Similarly, for React-Redux, the average duration is 49.1 milliseconds, with a confidence interval of 0.7, suggesting that the true duration likely falls between 48.4 and 49.8 milliseconds. The fastest among the three is Solid.js store, with an average duration of 43.5 milliseconds and a confidence interval of 0.4, indicating that its performance is likely between 43.1 and 43.9 milliseconds. Lower values and narrower confidence intervals generally suggest better and more consistent performance.

Start-up metrics, represented by Lighthouse scores with mobile simulation, provide insights into the performance of different technologies.
These scores reflect the efficiency and speed of each technology during application startup. The higher the score, the better the performance. In this comparison, React Redux has the highest score of 2626.2, indicating that, among the three, it exhibits the fastest start-up time and overall better performance during the initial loading of the application.

When we compute a 95% confidence interval using memory allocation data, we are describing a range within which we have a high degree of confidence regarding the actual average memory allocation value. This statistical measure acknowledges the inherent variability in memory allocation measurements and helps to provide some degree of confidence regarding the accuracy of our estimation.

Developer Experience

React offers a gradual learning curve with widespread adoption and extensive documentation, while Solid.js emphasizes simplicity and minimalism. Striking a balance involves considering the team's familiarity with reactive programming and the project's complexity to determine the most suitable framework for adoption.

React's mature ecosystem and widespread community support provide robust tooling. Solid.js, though newer, offers a growing community and streamlined minimalism. Balancing considerations involve weighing the benefits of React's extensive tooling against Solid.js' focused approach, depending on specific project requirements and preferences.

Use Cases and Recommendations

There are a few factors to take into account while deciding which of the two frameworks to use. These are my opinions, and whether or not they are accepted by everyone is irrelevant.

Solid

• Solid.js is well-suited for scenarios where fine-grained reactivity is crucial.
• If developers are already familiar with reactive programming concepts, Solid.js might be a preferred choice.

React

• React's virtual DOM and component-based architecture are well-suited for building large and complex applications
• In situations where leveraging a mature ecosystem and benefiting from community support are essential, React provides a strong foundation.

Conclusion

Large-scale apps benefit from React's virtual DOM and rich ecosystem, although it may lead to larger bundle sizes. Solid.js is perfect for exact scenarios and lightweight applications because of its superior fine-grained reactivity and minimalism, which lead to smaller bundle sizes and faster rendering. The decision is based on optimization priorities and project specifics.

Comments

[Alex Lohr]

Actually, React doesn't scale too well. At some point, you will inevitably run into the necessity to optimize updates, which will eat up increasingly more time. The main thing it has going for itself is the employability that comes with it being known to managers.

The thing that Solid.js cannot yet compete with is the state of the ecosystem, and it gets better by the day. I should know, being the maintainer of its testing-library and multiple community primitives. If you are building your components yourself anyways, you should definitely consider Solid.js.

[Makanju Oluwafemi]

I would pick solid any day🙌

[Rense Bakker]

React scales really well if you avoid dirty state inside your render function.

For example, a lot of people do this:

function SomeComponent(){
  const thisObjectIsRecreatedEachRender = { foo: 'bar' }
  return <SomeChild unawareOfDirtyState={thisObjectIsRecreatedEachRender} />
}

When they should really be doing this:

function SomeComponent(){
  const objectReferenceNeverChanges = useMemo(() => ({ foo: 'bar' }), [])
  return <SomeChild safelyRelyOnProp={objectReferenceNeverChanges} />
}

There's a whole religious movement in the React community that advocates against the use of memoization. This problem has become so big, that it has spawned the React Forget project, that will just auto memoize everything for you 😛

[Alex Lohr]

The issue here is that complex applications run on complex data, which often requires nested objects that change a lot - and then even memoization won't save you, as you need a changed object reference for the fiber walker to detect the change.

The only way around that is to not manage that state within react and useSyncExternalStore to subscribe to changes (or use a state management like mobx to emulate the behavior of Solid.js in React).

[Rense Bakker]

Not sure about your use case, but i haven't ran into any trouble myself with fast changing data, even when building something like a stock rate checker that updates in realtime. React is extremely efficient at rendering, if it can rely on a clean state, that only changes when the value actually changes. If you start with dirty state high up in your React tree, once you get 10 levels deep, your component is recomputing 10x or more, while the actual value it relies on hasn't changed at all. Suppose that component is one of a hundred table rows all doing computations 10x on the same unchanged value... Even if that computation only takes 2ms that's still 2 seconds of CPU time that the user can't interact with your app :B and all of those 2 seconds can be brought down to 10ms with simple memoization.

[Alex Lohr]

In this case, it was an online meeting software supporting more than 50 attendees, each of which required rather complex state.

React is extremely efficient at rendering

Not much more than the alternatives. Also, the problem with fibers vs. a signals-based architecture is that you still have to walk two trees until you even start rendering.

And while memoization allows you to re-use object references for unchanged values, you still need to create new references for changed values, or else your updates won't be detected.

[Rense Bakker]

Well I'm definitely not against signals based solutions like solidjs, just wanted to make sure that devs don't write off React because they refuse to memoize and are thus confronted with poor performance when scaling up.

[Stasi Vladimirov]

Balance is key, Vue is the winner. Have no idea why anyone would recommend React for large projects. From the provided solutions it’s the least scalable one. Vapor is under active development and once it’s available I have hard time seeing any advantages Solid can offer. I’ve done production development with each of the main reactive frameworks and Vue is an easy and clear winner in performance, flexibility, ecosystem, DevEx, consistency, maintainability, learning curve. The only place where react has advantage is popularity, and given the JS development scene popularity is a very temporal advantage.

[Makanju Oluwafemi]

Apparently, React relies solely on its ecosystem. There are better alternatives in terms of learning curve, performance, and code style. That's where Vue stands out.

But when comparing there performances, the key battle lies in how effective the reactivity system is. This is where Solid shines. React and Vue use the same virtual DOM techniques, with Vue having the edge thanks to its direct tracking reactivity, which allows it to make changes directly to the DOM when an update is made to its reactive data.

Solid otherwise, outshine them by removing the virtual DOM and replacing it with a more efficient reactive system. I mean, it makes it better. My only issue with Solid is that it has the same code style as React. It will only be easier for someone coming from React backgroud to hit the ground running when working with it.

[Stasi Vladimirov]

That’s why I pointed out Vue Vapor mode which is under active development and will be available soon. It removes the virtual DOM and implements Solid-like reactivity within Vue. Look it up.

Also I strongly disagree about the react ecosystem. It’s actually pretty bad. Things like routing, css styling and build and browser tools are behind and in some cases just sad compared to Vue counterparts. Even if you ignore Vitest, Vite, VuePress, Vue Dev Tools, Volar that are clear winners in their respective context, there are some other open source project such as Quasar (no react alternative), NativeScript, JSX/TSX support that are nothing short of impressive and incredible. Arguably the Vue documentation is better and more consistent too. Even just considering Next should be a good start in understanding how messed up the React Ecosystem is. To give where credit is due ReactNative is actually good, although I personally prefer single codebase solutions like Quasar and Ionic.

I’ve been using both React and Vue professionally for over 5 years and don’t know a single developer who would pick react given the choice and having at least basic experience with Vue.

[Gy]

That's why React is just a library not a FW. While I totally agree with you, for routing, styling, building things are just fixed/collected in Next.Js. I still had bad dreams when I had to re-configure react router and when I started working with Next 13 it was a pleasant surprise.

[Stasi Vladimirov]

What if I don't want to use Next by Vercel? Why do I have to use another framework with questionable practices and affiliations in order to handle basic things such as routing and styling?

[Gy]

I had no other way. Our client's SA made this choice before I joined the team. This is an enterprise project, it's not always our choice, or even most of the time. Anyway, I think Next is quite ok. Just 1.5 years ago, one of our clients was looking for people with KNOCKOUT (!) knowledge. :D The whole thing was a rewrite, but it still required knowledge of a technology from 13 years ago. I'm just pointing out that I rarely choose, technology choose us.

[Stasi Vladimirov]

I understand. But you also got to realize that part of the reason is developers like you defending and/or advocating for bad solutions as per in this example. Settling for solutions that are "quite ok" and promoting them in the community is how we reach a stage where the worst solution is the most popular one. On another hand voicing concerns and pointing out problems brings attention to alternative solutions which is necessary to displace the current popular choice. Given all of the conversation under this article, many of the posts on reddit, the countless tweets about issues, the state of issues in the github repository I believe sunsetting react is only a question of time. Sooner or later it will be just another KNOCKOUT technology from 13 years ago. And this can't happen too soon.

[Gy]

I'm not defending or advocating, you've got something very wrong. You can change at any time on a home project. In the case of a large banking software, which was started 3.5 years ago by 6 teams and now has a huge code base, it is simply not possible to always replace it with the best and fastest one. If the client were to support this in time and money, by the time it was completed, Solid would also be obsolete by then. The introduction of Next is already a step forward.

[Alex Lohr]

Vue Vapor, Svelte 5 and React Forget will be there at some point in the future. Solid is already there now.

That being said, you can work around most of the issues so there's no wrong choice except to call other choices wrong.

[José Pablo Ramírez Vargas]

While the benchmarks might be a little "artificial" in nature, they clearly reveal a major problem in the React library. React simply can't compete with Solid or Svelte, or pretty much 70% of the frameworks out there. It wastes RAM and CPU cycles left and right, and I wonder why people seem to be so fixated with it, even when confronted with the cold hard data.

React for new projects makes no sense to me. Why would I go for one of the worst performing libraries for UI in existence today? The only reasons are: Existing codebase, or need of the ecosystem, and the first one doesn't apply to new projects.

So this leaves us with the ecosystem reason. I, as team leader of a project written in React, studied my needs and decided to kill React. My only roadblock was Kendo Grid. I ended up making a replacement in Svelte. Now we'll move all code to Svelte progressively using single-spa.

Don't know if you've seen, but Rich Harris (the creator of Svelte) has some videos where he shows React and Svelte solutions of the same thing, and wow, React cannot come close.

I get that many people think React is king, and in some ways it is, but really is just a matter of time before a new king is crowned, and I think it will be Svelte. Svelte 5 early benchmarks place it in the top 5, competing with Solid and vanilla JS.

But even if all this doesn't convince you, let's talk about learning curves. Have you seen the documentation on the <Suspense> component? Have you seen the documentation on the {#await} Svelte block (which provides equivalent functionality)? Svelte can be learned in 1 day. All of it. React? 1 month, perhaps.

[Makanju Oluwafemi]

Svelte can be learned in one day. All of it. React? 1 month, perhaps.

I believe you are talking from the perspective of an experienced developer trying to learn svelte. But realistically, we are going to be using newbies to judge the learning curve. I don't think it's possible to learn a framework in a day, IMO.

[Alex Lohr]

A bit exaggerated, but not exactly wrong. However, the learning curve matters not if all newly hired developers already know the framework.

In that case, what matters most is that internal and external code can be (re-) used – and React still has the most extensive ecosystem. Granted, there are many packages that are no longer maintained or have low quality, but managers cannot make such a distinction, so they can only judge the size.

So the best we can do is improve the ecosystems of the alternatives and all work together in order to find better patterns and solutions.

[Adriaan]

One of the issues I have with React is that it doesn't play nice with others. This is why I'm looking into Lit/WebComponents and perhaps Solid and Svelte.
I want to be able to create components that are small, efficient and performant and can be used in any environment without worrying about performance or interoperability.
I've noticed that a lot of component bundles for React are actually written in pure javascript or some other closer to javascript form and just wrapped to be React friendly - makes sense since then you can also use it in other frameworks. If you wrote it in React then you'd have to rewrite it for other frameworks.
I'm currently trying to determine if Solid or Svelte would be viable or perhaps I have to try sticking with Lit as far as possible.

[Alex Lohr]

It is true that React assumes an awful amount of control over the DOM and even overwrites fetch. I personally prefer Solid.js, but Svelte and Lit are also viable choices, all with their individual advantages and drawbacks.

If you are afraid that you need to rewrite your components, you might want to check Mitosis, which allows you to write components in a certain JSX flavor and compile them to React/Vue/Solid/Svelte/Lit and a multitude of others.

[José Pablo Ramírez Vargas]

Interesting thing, Mitosis. The premise is super attractive, but I worry: The example shows a React-like example, and in all honesty, I don't think this would produce optimized per-framework versions of the component. Still, I just spent 1 minute looking at it. I'll shut up for now, and maybe have a better look at it.

[Alex Lohr]

You can use plugins to optimize separate use cases. It's less obvious, but a) optimisations can be shared over modules and b) this entry barrier helps avoiding premature optimisations.

[José Pablo Ramírez Vargas]

React's virtual DOM and component-based architecture are well-suited for building large and complex applications

The more complex it is, the more it suffers from coarse-grained reactivity. React is dead. Just like that. I personally switch to Svelte to never see React again.

[Makanju Oluwafemi]

But you can't actually shy away from the ecosystem advantage; it's holding a lot of people down. Lol

[José Pablo Ramírez Vargas]

Oh, yes I can. For example, I recreated all the functionality of Kendo Grid in Svelte to drop Kendo React. Fixed columns, dropdown column menu, inline editing, sorting, searching, column resizing. Svelte is so nice you actually enjoy building components. What holds people down is themselves. You just have to plan appropriately.

[Makanju Oluwafemi]

Fair

[Riccardo Basile]

It's only that - and it's only a matter of time.

[Adaptive Shield Matrix]

Solid.js is better than React in every category, except ecosystem size/breath.

Solid.js scales much better than React.

"React's virtual DOM and component-based architecture are well-suited for building large and complex applications"

• component based -> applies to solidjs as well
• well-suited for building large and complex applications -> applies to solid.js as well

Solid.js is the spiritual success to react.
It has all its upsides (except ecosystem size) and none of its downsides (missing signal based state solutions), while being very similar (using JSX and having similar hooks like APIs). Solidjs is the perfect choice for React developers.

Both Solid.js and Svelte -> are successors of React, because they learned on Reacts mistakes and improved/solved them, each in their own way.

• Svelte -> introduced a custom syntax that is transformed with compiler magic using native/underlying DOM.
• Solidjs -> build-in a signal based state manager while getting rid of VDOM for better performance.

Both Svelte and Solidjs are at the top of the performance charts because if this.

New/Junior Developers should learn

• React -> if you want to get a job and support a legacy web app
• Svelte or Solid -> if you want to be productive/joyful of your work

[Kristof]

I am here to defend React. We have an experienced team, working with the library for many years on a quite big code base. We had performance issues, but fixed them without major impact. Our customers are also quite happy, maybe because they are not going into the performance horse race. React's big ecosystem, still improves with web frameworks like Remix, making it much easier to use the library. Of course, we will look into new technologies, like Solid and play with it. For developing major apps I would still wait until it gets more mature, though. SolidStart is still beta.

[Arindam Majumder]

Great Share

[Brad]

It's usually too easy to disregard the business side of a tech stack, which is where the term used in the title "efficient" becomes subjective to the context.

React isn't efficient in terms of performance compared to many competitor UI libraries.

Popularity might not make efficient code, but you really want efficient software within an efficient business. Sticking with what's popular can help alleviate a lot of issues, rather than focusing on specifics.

[Makanju Oluwafemi]

React in terms of jobs, and the number of people who use it is great. The more people, the better it's to find solutions to problems.
Even though other frameworks are better.

[Oziel Perez]

Just use Svelte, there is no need for VirtualDOM if you know how to optimize a UI. Plus we need to get back to basic JS not these React shenanigans

[Jean-Michel 🕵🏻‍♂️ Fayard]

Counter-argument :

A mature company has different sets of concerns when making choices
Concerns A : efficiency, performance, ...
Concerns B : how productive the team is with the framework, ie time to market
Concerns C : how hard it will be to hire good people

I am not into web development, so I have no idea who the winners are for each categories.

What I know is that while I value Concerns A, I value concerns B more, and I value Concerns C even more.

[Camilo Arriagada Vallejos]

solid is dope 👌🏻👌🏻

[Makanju Oluwafemi]

I really do love a valid explanation backed with good examples.

1. Why do you think Million is not solving the problem?

[Makanju Oluwafemi]

It was a pleasure to talk with you all about this. I completely agree that the react reactivity method is inadequate. Nevertheless, million.js is addressing this issue.

[aaronblondeau]

Thanks for including Vue in the tables!

[Makanju Oluwafemi]

Hi Oscar,
There is no point in saying someone does not know how to use a certain tool if they do not agree with your explanation.

[Makanju Oluwafemi]

This doesn't happen in React if you break everything into components. The problem is that with Vue, usually people love to put everything in one huge single component. That can't happen in React because of its rendering system, when you know that you could avoid a lot of the pain.

Are you saying people don't break stuff into components in Vue?

That argument is void.

[Stasi Vladimirov]

The problem is that when you work in a team you can’t expect that everyone is aware and knowledgeable on how to deal with reactivity bottlenecks that simply don’t exist in Vue. I can go into detail, but If you ever worked on a large enough project you’ve been to the point where the number of WTF’s exceeds the change count in almost every PR. Reviews quickly become bottleneck watch outs where the focus is on making sure you have all memoizations in place and reduce dependencies as much as possible for the sake of not having to debug where the lag comes from instead of keeping focus on what we are actually trying to build/do in the first place. It’s really sad state of affairs, but hey everyone has their own preferences on what to do with their free time and I can respect that.