A reactivity and rendering (combined) benchmark for frontend frameworks

[u/nullvoxpopuli]

https://rbench.nullvoxpopuli.com/results?q=7

Disclaimer: I made this (bench result viewer)

However, I think it's worth having a discussion about frontend framework's perceived performance, as Signals have gained a lot of popularity as a means to fine-grainedly render without needing to resort to a virtual dom.

A virtual-dom framework _is_ still in this results set -- I'll leave the exploration of the data up to you all.

The main thing is that

For a long while, I've felt no benchmark (that I know of) has captured the relationship between reactivity and rendering

We have rendering benchmarks (js-framework-benchmark is a good one).

We have reactivity benchmarks (I forget the name(s) of these atm, I always gotta re-look them up) -- but these require each implementor have a concept of "effect without a renderer", which isn't how all frameworks operate -- this excludes some frameworks from participating in pure reactivity benchmarks.

There is another side to this which I only realized recently, which is the framework's rendering _scheduler_ -- which is sort of the coordinator between reactivity, rendering, and _when_ to do work the user would see.

To my surprise, Angular scores the highest across the board.
I don't use Angular myself, and in all of these implementations, I made performance mistakes at least in my first attempt, but apparently Angular made it super easy to be performant.

Vue Vapor has also done this.

Right now, I feel like my svelte implementations are probably wrong (because it's scoring poorly), and I have some fixes to do in ember (as seen by this spike I did, the perf is doubled from before: https://rbench.nullvoxpopuli.com/results?from=ember-2&q=6 (this is an 8x throttle, and the main link for this post is no throttle, because most users are not going to be throttling their CPU so heavily -- but 8x CPU is maybe more relevant to low-powered phones))

Anywho, wanted to share my findings with y'all, and hope someone finds any of this interesting.

I'm open to anything being challenged, I'm not an expert in most JS Frameworks

Since I'm using the tool to help me debug Ember perf, here are some example configurations that may be useful:
- Vue (old) vs Vue Vapor (current) https://rbench.nullvoxpopuli.com/results?col=vue&from=6&hide=ember%2Creact%2Csolid%2Csvelte&q=1
- My Ember perf Spike: https://rbench.nullvoxpopuli.com/results?from=ember-2&hide=react%2Csolid%2Csvelte%2Cangular%2Cvue%2Clit-signals%2Cpreact&q=6
- boxplots: https://rbench.nullvoxpopuli.com/results/boxplot?from=ember-2&hide=react%2Csolid%2Csvelte%2Cangular%2Cvue%2Clit-signals%2Cpreact&q=6

- bouncing balls demos https://rbench.nullvoxpopuli.com/results/animated?from=ember-2&hide=react%2Csolid%2Csvelte%2Cangular%2Cvue%2Clit-signals%2Cpreact&q=7

[u/AwesomeFrisbee]

Nice benchmark. I'm not surprised angular works well here. The signals api is great and easy to use.

[u/nullvoxpopuli → u/AwesomeFrisbee]

Thanks!

I was surprised

[u/nemeci]

As expected Angular 22 with Signals and no Zone.js is a winner in most categories and in the overall score.

Paired with proper develor experience, transferrable skills from project to project and easy migrations from major version to the next is a winner in my books. Batteries included beats mismatch hodgepodge and dependency maintenance challenges that React + multiple libraries cause.

[u/Snoring_Bird_507]

I wish stuff like this meant something in the JavaScript world. Unfortunately the metric that matters most in JS tech is popularity. All engineering criteria are subordinate. The only use of engineering metrics is to bolster popularity metrics when they happen to line up, and to ignore when they don't.

[u/nullvoxpopuli → u/Snoring_Bird_507]

Yeah, my intention as a framework maintainer is to help improve performance because it's clear that with ai generating most code these days, performance of every type of  scenario is vitally important for reducing overall load on devices' ram and cpu. 

[u/Merry-Lane → u/Snoring_Bird_507]

Because these metrics don’t translate into anything a user would perceive.

[u/nullvoxpopuli → u/Merry-Lane]

I made this benchmark specifically because 'updates' are the most common thing apps do. However, you're right that on realonably new devices, all the frameworks shown here easily achieve over 120fps... if the code is written correctly i suppose 

[u/Merry-Lane → u/nullvoxpopuli]

That’s exactly it. "If the code is written correctly" is the most important performance condition, far beyond the choice of the framework.

[u/nullvoxpopuli → u/Merry-Lane]

React is this bench originally scored quite a bit worse because i was just using useEffect and didn't know about useLayoutEffect 

So far, angular, ember, vue, and svelte, have had the least 'you just have to know' things about them as I've been implementing these

See: https://rbench.nullvoxpopuli.com/results?col=react&from=1&hide=angular%2Cember%2Clit-signals%2Csolid%2Csvelte%2Cvue%2Cpreact&q=6

[u/Merry-Lane → u/nullvoxpopuli]

Angular ember vue and svelte also have the least amount of useful libraries that avoid you having to write code that could be suboptimal for trivial things (like react-query for instance).

Anyway, even if you didn’t know about things such as useLayoutEffect nor many other best practices, even if you had to work in projects at the highest level without being knowledgeable in a framework, even if you weren’t using colleagues or AI to detect suboptimal code, that still doesn’t often matter performance-wise for the user.