←back to thread

446 points talboren | 7 comments | | HN request time: 0.471s | source | bottom
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 #
1. 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 #
2. 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 #
3. 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).

4. ajross ◴[] No.45041777[source]
Confirmation of priors is a powerful drug. And performance engineering is really hard and often lives at a different layer of the stack than the one you know.

It's just easier to blame the tools (or companies!) you already hate.

5. psygn89 ◴[] No.45042832[source]
JS is the logical place to start with all the virtualization and fanciness.

But CSS has bit me with heavy pages (causing a few seconds of lag that even devtools debugging/logging didn't point towards). We know wildcard selectors can impact performance, but in my case there were many open ended selectors like `:not(.what) .ever` where the `:not()` not being attached to anything made it act like a wildcard with conditions. Using `:has()` will do the same with additional overhead. Safari was the worst at handling large pages and these types of selectors and I noticed more sluggishness 2-3 years ago.

replies(1): >>45043040 #
6. Sesse__ ◴[] No.45043040[source]
`:not(.what) .ever` should be fairly fast, unless you have lots of `class="ever"` elements. Not ideal, but not as bad as e.g. `.ever :not(.what)` would be. `:has()` is just inherently slow if there's a significant amount of elements to search, even though browsers have some caching and tricks.

Normally, you be able to debug selector matching performance (and in general, see how much style computation costs you), so it's a bit weird if you have phantom multi-second delays.

7. MobiusHorizons ◴[] No.45049426[source]
These performance problems are new since a rewrite which also added react. Could be just a coincidence, but that is why people blame react.