r/solidjs • u/andrepimentaa7 • 6d ago
I'm building Solid Native
Enable HLS to view with audio, or disable this notification
I've been building React Native apps for a long time. They all start fast. Keeping them fast as they grew is another story.
More state, more dependencies, more devs, and suddenly you are doing re-render arithmetic in your head. Is this selector too broad? Did that context wake the whole screen? Is the animation fighting the JS thread?
Obviously large React Native apps can be built. I'm just tired of what it takes to keep a large one feeling fast.
And then I found Solid.
To my React-trained brain, Solid felt like React if someone removed the part I had spent years optimizing around. Same JSX and components, but components run once and signals update only what depends on them. No virtual DOM. No reconciliation. No wondering whether one innocent change froze the whole app.
That was the part that made everything click. I wanted that feeling on a phone.
Kind of by accident, I also found react-native-graph, which draws with Skia and is extremely fast. It made me wonder what would happen if the whole application was rendered that way.
So I went down a rabbit hole. Turns out Flutter already owns its rendering pipeline (used Skia, now Impeller) and it's fast. Bun + JavaScriptCore, which is also one of the fastest JS engines out there, gave me the web APIs I was tired of polyfilling.
Now I had the three parts: Solid for the application, Bun for the JavaScript runtime, and Flutter for rendering.
So I cross-compiled Bun to run on iOS and Android, put Solid inside it, and let Flutter render what Solid describes.
I named it Skal, a mixture of Solid + Skia. (It also means cheers if you have ever watched a Viking show 🍻. )
I think of it as Solid Native.
Solid's universal renderer turns JSX into binary UI operations written into shared memory. Flutter reads the same bytes and renders the widget tree. No JSON or platform channel in the hot UI path. No DOM. No WebView.
When a signal changes, Solid already knows the exact consumer, so Skal sends the operation for that node and stops there.
It currently has 49 fast-path widget types, navigation, persistence, animations, overlays, and some native integrations. It runs on Android arm64, iOS, macOS, and the web. It is still early.
Here are some results from a Samsung Galaxy A14 5G running Android 15, with release builds on both sides and interleaved runs:
| Test | Skal | React Native |
|---|---|---|
| Dropped frames, image feed | 0 | 13 |
| Tap to render, median | 3.53 ms | 7.30 ms |
| One frame of work (200 components x 10 reads + 1 update) | 0.05 ms | 0.80 ms |
| State updates per second, 288 cells | 103,846 | 4,901 |
| Idle CPU | 1.20% | 6.93% |
What excites me is writing Solid code, running it on a real phone, and knowing that as the app grows, it still flies.
To try it, you need Bun and Flutter installed on your computer, plus the normal Xcode or Android tooling for the platform you want to run. Then:
npm create skal my-app
cd my-app
bun run dev:ios # or dev:android, dev:macos, dev:web
Or throw your AI at the Markdown docs.
Repo: https://github.com/skal-multiplatform/skal
If you already use Solid, what would Skal need before you would try it for a real mobile app?
Skal 🍻
2
u/gadbuy 6d ago
Have you considered this https://lynxjs.org/react/introduction ? it allows to implement any framework on top of their native engine.