About two months ago, we were tasked with building a new feature in our system. It wasn't overly complex, but it wasn’t trivial either. This feature required its own backend service, and on the frontend side, we wanted to keep things modular and lightweight. After some consideration, we decided that the best approach was to build it as a micro-frontend. During the design phase (and even earlier), we toyed with the idea of using either Preact or Solid.js for the UI. Our main goals were clear: a minimal bundle size and top-notch performance.
To our surprise—and despite my initial hesitation about stepping away from the React ecosystem—our team lead gave us the green light and said: "Go for it."
We decided to run two POCs.
The first was with Preact. On paper, it looked promising: the same familiar React-like API, faster, and much lighter. But in practice, it didn’t live up to expectations. Preact doesn’t support portals natively—a feature we considered critical—so we had to implement a workaround. The Preact DevTools extension was broken, which made it hard to get visibility into what was actually happening. When we tested the workaround, we noticed through DevTools that the portal component was being created multiple times on each render.
We weren’t sure if it was a DevTools bug or a real memory leak, but either way, it didn’t inspire confidence. Despite the promise that it’s “just like React,” we quickly found that wasn’t quite the case. Even basic things didn’t work properly in tests using @testing-library/preact. That alone raised enough red flags to make us reconsider.
Then we tried Solid. From the very beginning of the POC, the difference was striking.
Bundle sizes:
- React: ~290KB
- Preact: ~140KB
- Solid: ~80KB
But the experience went far beyond just kilobytes…
Let’s Start With the Downsides:
Ecosystem limitations:
Yes, it’s the classic complaint, but it's real. Solid has a great ecosystem for what it covers, and the core tools you'd expect are there. But compared to React’s massive ecosystem, where there are 10 libraries for every tiny problem, Solid still has some catching up to do.
AI assistance (and its limits):
When we needed a unique component, ChatGPT generated something solid (pun intended) within seconds. A few tweaks, some tests, and we had a working result. That said, AI tools often assume React by default, and it shows. We encountered quite a few cases of bad advice, confusing React patterns with Solid’s—things that “just work” in React, but are considered bad practice, or simply don’t make sense in Solid.
Now, the Good Stuff:
Community support:
The Solid community deserves serious praise. For every common React utility or pattern, we found thoughtful Solid-native alternatives, often with better performance or DX. Paired with AI support, we were able to build fast and clean.
Performance:
This was the real highlight. In large, data-heavy components with lots of state changes, Solid noticeably outperformed React. Sure, with enough optimization, you can get React to perform well too, but that often comes at the cost of readability, with memoization clutter (useMemo, useCallback, etc.). With Solid, this level of performance is the default. No hacks are needed. (Disclaimer: we didn’t compare React Compiler, which might change the game.)
The Learning Curve: Quick, With a Few Gotchas
We went into this project fully expecting that picking up Solid.js would be easy—and for the most part, it was. Since Solid’s API is heavily inspired by React, the team was able to ramp up quickly and start building real features almost immediately. There was no need for a big knowledge transfer or internal training session. Everyone just… got it.
But while the learning curve was smooth overall, it’s important to note that Solid isn’t React. There are subtle—but critical—differences that can trip you up if you're not paying attention.
A few examples:
- Reactivity works at the signal level, not the component level. Solid doesn't re-render components like React—it updates only what needs to change. That’s great for performance but requires a shift in how you think about updates.
- JSX looks the same, but control flow (<Show>, <For>, etc.) is done through Solid-specific primitives, not plain JavaScript.
These differences aren’t hard to learn, but you do need to be aware of them. Once the team internalized Solid’s mental model, development moved fast and felt even cleaner than what we were used to. As long as you don’t treat Solid like “just React with signals,” you’ll be up and running in no time.
After six years of React and a year with Vue, working with Solid felt like a breath of fresh air. No unnecessary re-renders, intuitive debugging, a clean and familiar API that just works better. Global state is simple, context works flawlessly, and the whole fine-grained reactivity model feels elegant and powerful.
There’s no need for extra tools or runtime compilers to hit top-tier performance. Honestly, going back to React feels like stepping into a library from a previous era.
Final Thoughts:
After about six weeks in production with Solid, wondering what all the React hype was about. The buzz around React Compiler? There's already a library that delivers comparable (or better) results today.
Give Solid a shot. It won’t disappoint.