
radEventListener: Client-side Framework Performance - indysigners
https://css-tricks.com/radeventlistener-a-tale-of-client-side-framework-performance/
======
anonytrary
Cool experiment, but what was learned? We already knew that:

    
    
      1. Vanilla JS is faster than Preact's diff/render.
      2. Preact's diff/render is faster than React's.
      3. Preact's concurrency model is extremely weak/non-existent.
      4. Preact has worse third-party library support than React.
      5. Preact is not that much smaller (min-gzip) than React 16.
    

The conclusion is still the same: use React for UI, don't bother with React-
family libraries. Use vanilla JS for games, canvas, and other web APIs that
aren't UI.

~~~
kreetx
I wonder how Svelte/lit-html and others without vdom would have compared.

------
jameskraus
I'd love to know _why_ there is such a significant difference in performance
between Preact and React here. It's not like the React team doesn't profile
it. They must be optimizing for other features over this performance metric.

~~~
brundolf
One thing preact does differently is ditch React's "synthetic events" system.
React creates its own middleman wrapper objects for every single browser event
that goes through it. This is where most of preact's size difference comes
from, and I'd bet it has an impact on speed too.

More info: [https://preactjs.com/guide/v10/differences-to-react/#main-
di...](https://preactjs.com/guide/v10/differences-to-react/#main-differences)

------
mnkypete
You'd think that choosing a stack based on your target audiences computing
needs would be more common.

Choosing React over vanilla JS is not only required for simple state things
imho - for complex state I'd even say some may use something like Redux/MobX.
The development experience and speed vs vanilla JS is just unmatched. The
amount you need to worry about adding / removing classes, with implicit state
all over the place will soon slow you down soon much because of all the edge
cases you haven't thought of.

I hope nobody starts off development for new apps in 2020 based on pure JS -
even if you explicit target ultra-low-end devices, maybe try a lighter
framework like preact (et al).

------
42droids
In other news: if you walk around with weights attached to your body, you will
walk slower.

------
brundolf
This is a good article, but the HN title is highly editorialized. Can we get
it changed?

~~~
dang
At your service.

(Submitted title was 'Vanilla JavaScript renders 5-10x faster than Preact, 30x
faster than React'.)

~~~
brundolf
Thanks dang!

------
ex3ndr
preact is usually slower than react actually. Initial load may be slow, but
not overall performance.

Also preact are very often simply not work, i can't explain, but it is always
something really creepy happening in random places. Event listeners also
behave somehow different.

Also React 17 sets only a single listener to a document, not everywhere and
adding a lot of listeners is much cheaper now.

At the same time most of the react slowness is not from react, but from awful
libraries, usually css-in-js. And concept of css-in-js is actually very good,
but implementations are simply awful.

