radEventListener: Client-side Framework Performance | Hacker News Reader

radEventListener: Client-side Framework Performance

css-tricks.com

33 pointsindysigners10 comments

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.

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

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.

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...

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).

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

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

At your service.

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

Thanks dang!

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.

Reply on news.ycombinator.com