4 ms·

radEventListener: Client-side Framework Performance

33 points by indysigners 6y ago

42droids 6y ago
In other news: if you walk around with weights attached to your body, you will walk slower.
jameskraus 6y ago
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 6y ago
  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-differences https://preactjs.com/guide/v10/differences-to-react/#main-di...
jxi 6y ago
Would be interesting to see how other JS frameworks like VueJS, Angular and Svelte measure up too. I wonder if VueJS would be more performant.
brundolf 6y ago
This is a good article, but the HN title is highly editorialized. Can we get it changed?
- dang 6y ago
  At your service. (Submitted title was 'Vanilla JavaScript renders 5-10x faster than Preact, 30x faster than React'.)
  - brundolf 6y ago
    Thanks dang!
shard972 6y ago
Would have been interesting to see mithril compared as it's pretty much the lightest VDOM implementation out there.
anonytrary 6y ago
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.
- redis_mlc 6y ago
  As a proud vanilla-js developer for over two decades, my primary concern hasn't been speed for the past decade, and today it's a total non-issue - I don't even need to profile vanilla-js code, since execution time is not noticeable. But there is nervousness of supporting/testing browsers like IE/Edge. - I haven't had any issues on Safari/Chrome/Firefox for several years, but you never know with the MS products until you try. I only use a single polyfill for IE/Edge, plus a couple of UA `if' statements, so it hasn't been difficult to write cross-browser code using trailing-edge JS API calls. But there is always a nagging testing load.
- kreetx 6y ago
  I wonder how Svelte/lit-html and others without vdom would have compared.
ex3ndr 6y ago
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.
mnkypete 6y ago
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).

33 points by indysigners 6y ago

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

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 6y ago
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-differences https://preactjs.com/guide/v10/differences-to-react/#main-di...

jxi 6y ago

Would be interesting to see how other JS frameworks like VueJS, Angular and Svelte measure up too. I wonder if VueJS would be more performant.

brundolf 6y ago

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

dang 6y ago
At your service. (Submitted title was 'Vanilla JavaScript renders 5-10x faster than Preact, 30x faster than React'.)
- brundolf 6y ago
  Thanks dang!

shard972 6y ago

Would have been interesting to see mithril compared as it's pretty much the lightest VDOM implementation out there.

anonytrary 6y ago

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.

redis_mlc 6y ago
As a proud vanilla-js developer for over two decades, my primary concern hasn't been speed for the past decade, and today it's a total non-issue - I don't even need to profile vanilla-js code, since execution time is not noticeable. But there is nervousness of supporting/testing browsers like IE/Edge. - I haven't had any issues on Safari/Chrome/Firefox for several years, but you never know with the MS products until you try. I only use a single polyfill for IE/Edge, plus a couple of UA `if' statements, so it hasn't been difficult to write cross-browser code using trailing-edge JS API calls. But there is always a nagging testing load.
kreetx 6y ago
I wonder how Svelte/lit-html and others without vdom would have compared.

ex3ndr 6y ago

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.

mnkypete 6y ago

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