Exploring SolidJS: A High-Performance Alternative to React

Recently, I had the opportunity to share my experience with SolidJS at a tech meetup. Today, I want to take you through my journey of discovering this interesting framework while trying to optimize a React application for resource-constrained devices.

The Challenge That Started It All

Late last year, I faced a significant challenge in my project. We needed to optimize our React application running on a device with severely limited resources — low CPU, no GPU, and minimal memory. This constraint led me to explore alternatives that could provide better performance while still using web technologies.

Turning to Benchmarks

When comparing framework performance, benchmarks are often the first port of call. I came across a comprehensive table of framework benchmarks, focusing on runtime duration and memory consumption. I noticed React in the table, but it was far from the top performers and even had some worrying “red” metrics.

Image Source

I remember thinking, “We can find React here. It’s very far from very performant options, but it’s still here. It’s still with some green color, right? But it has a cell with red color on it. Who likes red-colored benchmarks? I bet nobody, and I don’t either.”

This observation pushed me to explore options at the top of the benchmark list, which is how I stumbled upon SolidJS.

My First Impressions of SolidJS

SolidJS caught my attention for several reasons:

1. It promised React-like syntax with significantly better performance.
2. It implements web standards more closely than React.
3. It doesn’t use a virtual DOM, eliminating the overhead of diffing algorithms.
4. Components don’t re-render unnecessarily.

What really intrigued me was its core concept: fine-grained reactivity.

Understanding Fine-Grained Reactivity

As I dug deeper, I learned that SolidJS uses a concept called “signals” to manage state and reactivity. Unlike React’s component-level re-rendering, SolidJS updates only the specific parts of the DOM that depend on changed signals.

Here’s how I understand it works:

1. SolidJS creates “tracking scopes” within components.
2. Signals are defined to hold reactive values.
3. The compiler converts JSX expressions into separate tracking scopes.
4. When a signal’s value changes, only the dependent tracking scopes are updated.

This approach allows for much more efficient updates compared to React’s often broader re-rendering strategy.

Comparing Syntax of React and SolidJS

To illustrate the differences between React and SolidJS, let’s look at a simple example:

*In the example, we intentionally set initial value inside useEffect to highlight the case when that value depends on some asynchronous parts but left with plain string just for the sake of simplicity.

// React version
function Component() {
  const [value, setValue] = useState("");

  useEffect(() => {
    setValue("Initial");
    setTimeout(() => setValue("Updated"), 1000);
  }, []);

  return (
    <input
      value={value}
      onChange={(e) => setValue(e.target.value)}
    />
  );
}

// SolidJS version
function Component() {
  const [value, setValue] = createSignal("");

  setValue("Initial");
  setTimeout(() => setValue("Updated"), 1000);

  return (
    <input
      value={value()}
      onInput={(e) => setValue(e.target.value)}
    />
  );
}

Some key differences to note:

• There’s no need for useEffect in SolidJS
• Event handling is slightly different respecting web standards (onInput vs onChange)

Other Interesting Features I Discovered

As I explored further, I found several other interesting aspects of SolidJS:

1. Resource Handling: createResource for managing async operations.
2. Lifecycle Methods: onMount and onCleanup for more granular control.
3. Props Management: mergeProps and splitProps for working with reactive props.
4. Context: Similar to React’s context, but with potentially better performance.
5. Built-in Components: Optimized components for rendering lists and conditional content.

My Thoughts on Using SolidJS

Our application required optimizations that went beyond what web technologies could offer. However, if we had stuck with web technologies, SolidJS would have been our top choice. While my team ultimately decided not to use SolidJS for our specific use case, I still recommend exploring it, especially if you’re a React developer:

• It offers excellent performance for dynamic, reactive UIs.
• The concepts are familiar to React developers but often more straightforward.
• It’s production-ready with a growing ecosystem.
• It works well with existing JavaScript libraries due to its minimal re-rendering approach.

However, it’s worth noting that SolidJS has a smaller community than React or Vue, which might impact the availability of third-party libraries and resources.

Wrapping Up

For me, SolidJS presents an intriguing alternative to React, especially for applications requiring high performance on limited resources. Its fine-grained reactivity system and adherence to web standards make it a framework worth considering for both new projects and potential React migrations.

While I’ve covered the highlights here, there’s much more to explore in SolidJS. If you’re intrigued, I encourage you to dive deeper, try it out, and see if it fits your needs.

Whether you’re looking to optimize an existing application or start a new project with performance in mind, SolidJS could be the solution you’re looking for. As with any technology choice, be sure to evaluate it against your specific needs and constraints.

Happy coding, and may your applications be ever performant!

Eugene Zhlobo

Lead Software Engineer