SolidJS vs. React: Comparing declarative UI libraries
Tags: react
Published: 2022-01-27 18:57:00

**Written by [Iniubong Obonguko](https://blog.logrocket.com/author/iniubongobonguko/)✏️**

Ever wondered what the differences between the SolidJS and React JavaScript libraries are? Me too. In this article, we will uncover the similarities and differences between them to enable you to decide which one works best, depending on your use case.

React has been around for quite a while now and has revolutionized and influenced the JavaScript ecosystem to a great degree. Solid, on the other hand, is new to the party and has a lot to offer. [You can learn more about Solid here](https://blog.logrocket.com/introduction-solidjs/).

## Similarities between SolidJS and React

It’s not news that Solid and React share almost the same design philosophies, and anyone that has written code in both libraries quickly understands this. Let’s go over what makes Solid and React so similar.

### JSX first class support

JSX is simply short for “JavaScript XML” and you can think of it as syntactic sugar for writing React or Solid components. This means you can create Solid or React code without JSX using the `document.createElement` or `React.createElement` functions, respectively.

JSX allows you to describe what the UI should look like in HTML while giving you the full power of JavaScript. As well as being a visual aid, using JSX in Solid or React is useful for debugging, because it shows more intuitive warnings and error messages.

### Declarative nature

Both Solid and React are declarative because they update efficiently and render the right components when data changes.

In declarative programming, you only describe the final state of the desired UI and the rendering engine will determine the best way to execute. Declarative components are easier to debug and more readable as opposed to the imperative way of writing code.

### Unidirectional data flow

A unidirectional pattern of data flow means that data has only one way to be transferred to other parts of the application. In libraries such as Solid and React, this means that you would often need to nest child components within higher-order parent components.

A unidirectional pattern of data flow has the following advantages:

*   You have more control over your data so you tend to have fewer errors
*   More control means debugging is a breeze
*   High level of efficiency, because the system has boundaries and already knows which component owns what piece of data

## Differences between SolidJS and React: Why is SolidJS so fast?

Despite sharing almost the same design philosophies, a few features set both JavaScript libraries apart. We will go over some of those differences in this section.

### Absence of a virtual DOM

One of the most striking differences between Solid and [React](https://blog.logrocket.com/tag/react/) is the absence of a virtual DOM. Contrary to the idea that using the main DOM slows down an application, it is part of what makes Solid so performant.

The virtual DOM is a lightweight implementation of the main DOM. In the past, JavaScript libraries made use of the virtual DOM because it was comparatively faster than the DOM itself. After all, the DOM was not built to handle frequent updates on a large scale, so JavaScript libraries make changes to the virtual DOM and then compare the changes against the real DOM, and merge both.

This is the solution that many libraries and frameworks such as React, [Vue.js](https://blog.logrocket.com/tag/vue/), and Riot.js use, but today, the creators of Svelte and Solid have described the virtual DOM as pure overhead that only slows down the performance of the library. They have sought out alternate, faster options that include using the real DOM (which beats the rest of the virtual DOM competition).

The way Solid achieves such performant speeds without the use of a virtual DOM is to compile its templates down to real DOM nodes and wrap updates in fine-grained reactions. This way, when your state updates, only the code that depends on it runs.

### Components don’t re-render

Components in Solid, unlike React, render just once, and only the JSX expressions and primitives that are being used in the component get updated.

This brings performance gains to Solid as re-rendering a component is not necessary every time it is being used. Solid is reactive enough to track the changes happening inside the component itself.

### Fine-grained reactivity

React in itself is not fully “reactive,” which the [React team acknowledges](https://reactjs.org/docs/design-principles.html#scheduling). This should not in any way be a turnoff for anyone looking to use React, because it still gets the job done and is loved by thousands of developers and companies around the globe.

However, Solid was built with reactivity in mind, and uses this as its selling point. It uses the term “fine-grained reactivity” to describe its performant speeds and ability to swiftly update data.

## SolidJS vs React at a glance

For this section, we’ll be comparing both libraries based on the following metrics:

*   Developer experience
*   Performance
*   Community and ecosystem
*   Documentation and resources

### Developer experience

Both Solid and React have great developer experiences. This is because both Solid and React share a few of the same philosophies, such as unidirectional data flow, read/write segregation, and immutable interfaces (except the implementation of a virtual DOM, as we discussed earlier).

Solid also provides first-class JSX and TypeScript support, alongside a few features that are similar to that of React’s, such as context, portals, SSR, hydration, and many more.

### Performance

In terms of performance, Solid beats React and almost every other JavaScript library out there as the fastest there is.

Don’t get me wrong, React is mighty fast, but its potential is limited by its implementation of a virtual DOM and its quest for clean code architecture.

Solid’s performant speeds can be attributed to a design principle known as granular reactivity, which the creator talks about in [this article](https://dev.to/ryansolid/thinking-granular-how-is-solidjs-so-performant-4g37).

The [JS Framework Benchmark](https://krausest.github.io/js-framework-benchmark/current.html) provides us with a way to visualize all the JavaScript libraries and how they compare to vanilla JavaScript. As we can see in the performance, memory usage, and startup time tests, Solid trumps React and is way closer to vanilla JS speeds than most libraries.

### Community and ecosystem

Hands down, React wins this segment because of its vast ecosystem of third-party UI component libraries, tools, and resources.

At the time of writing, React comes in at over [180k Github Stars](https://github.com/facebook/react) and 8.7M weekly [npm downloads](https://www.npmjs.com/package/react) while Solid comes in at over [13k Github Stars](https://github.com/solidjs/solid) and 11.5k weekly [npm downloads](https://www.npmjs.com/package/solid-js).

With regards to third-party libraries, Solid does not have a lot yet, but it does have first-party libraries. Its first-party libraries are the equivalent of other popular libraries in other JavaScript libraries, such as [Solid App Router](https://github.com/solidjs/solid-app-router) for routing, [Solid Testing Library](https://github.com/solidjs/solid-testing-library) for writing component tests, and [Solid Transition Group](https://github.com/solidjs/solid-transition-group) for animations.

React’s numbers dwarf that of Solid, but we have to take into account the fact that Solid is fairly new to the competition as it was open-sourced in 2018 and now has over [70 contributors](https://github.com/solidjs/solid#contributors). Its growth isn’t staggering, but it is steady.

If you like to get your hands dirty and figure things out yourself, or contribute to the early stage development of a library, then Solid is the one for you.

### Documentation and resources

The number and quality of resources or documentation that exists for a particular framework or library is a result of how established the ecosystem is.

Because React has been around for longer, it has good documentation alongside a vast ecosystem of resources for newbies and advanced developers to follow.

While Solid is fairly new, its creator, [Ryan Carniato](https://twitter.com/RyanCarniato), is doing a lot of work to put Solid out there by creating videos and blog posts regarding Solid’s development. Members of the community are also creating lots of useful resources and guides on the library. Solid also has proper documentation on its website for newcomers.

## The final verdict

In this article, we’ve gone through similarities, differences, and even gone ahead to compare both Solid and React based on developer experience, community, and documentation, among other metrics.

We can see that Solid is doing something right when it comes to performance and developer experience, which are the most important benchmarks. But its biggest hindrance to becoming one of the most used libraries out there is its community and ecosystem.

Let’s face it, most people and corporations will only choose React because of the vast ecosystem and resources that back it up. I mean, there’s an npm package for virtually anything in React. Solid can’t compete with that at this stage, so there’s a lot of work to be done with regards to community building if Solid wants the mass adoption of their library.

---

## Full visibility into production React apps

Debugging React applications can be difficult, especially when users experience issues that are hard to reproduce. If you’re interested in monitoring and tracking Redux state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try [LogRocket](https://www2.logrocket.com/react-performance-monitoring). 

![LogRocket signup](https://blog.logrocket.com/wp-content/uploads/2017/03/1d0cd-1s_rmyo6nbrasp-xtvbaxfg.png)

[LogRocket](https://www2.logrocket.com/react-performance-monitoring) is like a DVR for web and mobile apps, recording literally everything that happens on your React app. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app's performance, reporting with metrics like client CPU load, client memory usage, and more.

The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.

Modernize how you debug your React apps — [start monitoring for free](https://www2.logrocket.com/react-performance-monitoring).