←back to thread

446 points talboren | 1 comments | | HN request time: 0.205s | source
Show context
muglug ◴[] No.45039093[source]
Improvements merged within the last two days by the WebKit team: https://github.com/orgs/community/discussions/170922#discuss...

For my sins I occasionally create large PRs (> 1,000 files) in GitHub, and teammates (who mostly all use Chrome) will sometimes say "I'll approve once it loads for me..."

replies(6): >>45039371 #>>45039546 #>>45039877 #>>45040882 #>>45043276 #>>45050622 #
Sesse__ ◴[] No.45040882[source]
Interesting how _everyone_ here blames JS and React, yet the fixes you linked are about CSS performance.
replies(4): >>45041372 #>>45041777 #>>45042832 #>>45049426 #
jchw ◴[] No.45041372[source]
You certainly can build slow apps with React, it doesn't make building slow things that hard. But honestly, React primitives (component mounting/unmounting, rendering, virtual DOM diffing, etc.) just aren't that slow/inefficient and using React in a fairly naive way isn't half-bad for data-heavy apps.

I actually have been trying to figure out how to get my React application (unreleased) to perform less laggy in Safari than it does in Firefox/Chrome, and it seems like it is related to all the damn DOM elements. This sucks. Virtualizing viewports adds loads of complexity and breaks some built-in browser features, so I generally prefer not to do it. But, at least in my case, Safari seems to struggle with doing certain layout operations with a shit load of elements more than Chrome and Firefox do.

replies(1): >>45041527 #
1. Sesse__ ◴[] No.45041527[source]
> You certainly can build slow apps with React, it doesn't make building slow things that hard.

By all means. It sometimes feels like React is more the symptom than the actual issue, though.

Personally I generally just like having less code; generally makes for fewer footguns. But that's an incredibly hard sell in general (and of course not the entire story).