React-Node VS Solid-Bun. Let’s have a battle!

Do we really need this? I say why not….

A cute smiley bun is fighting against a nuclear reactor 😅

There are so many frameworks, runtimes, and libraries in Javascript ecosystems that one can quickly get a feel of having a Linux-like multiverse of distros! But there can’t be only one among them all, Right?

So, allow me to introduce a fairly new entry into the pool of Javascript. It’s a multipurpose runtime with the potential to replace Node in the future! Being in the very early stages of its life, One can easily claim that Bun is just like one among those hundreds of runtimes. I agree for most of the part except for one sole thing. Which is Performance.

If most of the well-known runtimes are bullet trains then this cute bun is Super Sonic Missile itself 🚀, Because it claims to be 20x faster than famous runtimes like Node and Deno!

My favorite quote from its owner Jarred Sumner from his talk @ Real World React states something like the following…

Bun installs node packages 20x faster than npm. Usually in linux it reaches around 100 times, But I feel like if I say 100 times faster then nobody believes you! 🤣

So I just had to give it a try. I thought about what might be the tools in the current time that holds the potential to possibly affect the web development stack in the future! Thus, I tested another UI Framework called Solid JS (I recommend going through an awesome 100second tour of Solid JS if you’re unaware of it).

P.S. Bun is not yet ready enough to handle million dollars react or node project, So keeping that in mind I had to conduct testing while keeping node usage as lowest as I could! Here goes my conduct of testing!

1. Project Initializing

Since Bun doesn’t ship commands like npx, I had to use npm init to initialize the Solid JS project, However seeing at Bun’s ecosystem, I’m hoping that we’ll get npx equivalent with a 20x speed boost 😅

Create React App using NPX — 2m 13s
Create Solid App using NPM — 2m 3s (If Bun had capabilities for initializing packages then maybe it could’ve been 3 seconds? As I already tried installing packages via Bun which barely took seconds!🤔)

Since I had to use npm for initializing Bun project, It was quite slow yet faster then create-react-app

2. Project Initializing

This one was quite easy to figure out and worked as expected since Solid JS is a pretty small package compared to React JS.

npm run start —13s
bun run start — 5s

Solid JS started almost 50% faster!

3. Rendering

I did find Solid JS’s reactivity concept better in use and amazing in this test run. I used a simple component which was increasing the count by 1 each second. I followed common usage patterns that were required and found interesting results. (JFI: The reason behind flickering is due to the nature of React component, Which is setting a new interval on each render while in Solid JS, the Interval gets only initialized at the time of mounting only. In real world scenario, You’d most likely use Intervals in useEffect along with cleanup functions to clear that intervals.)

React component (left) vs Solid component (right)

4. Production Build

Nothing to debate here as Solid JS definitely wins because it ships with a very low bundle size whereas React does need some extra chunk of JS to be able to create a production build.

npm run build — 49.34 kb
bun run build— 6.066 kb

Solid JS is optimal when we’re talking about production builds!

5. Final Thoughts?

In conclusion, I can only say that being only reactive to the changes that occur on signals, Solid JS seems to handle rerendering better than React in the first go. There might be some real-world cases where Solid JS might fail but it seems promising enough to me for trying it out in my personal projects already.

Do check out the following video for seeing the rendering test. Feel free to leave your thoughts in the comments and let me know what you think about the future of Bun and Solid!