> Ad blockers are a thing. I use them on every browser (it's even possible to do on iOS). It makes a big difference.
True. They also break things, which I’m not a fan of for personal use. They also make manual testing of web work less consistent with what normal users experience, which I avoid.
> There are plenty of annoying dark patterns (and simply poor UX) out there being used, but what I'm trying to get at here is specifically the perception of slowness for the web as a platform. UX problems can exist in any software.
What I’m describing though is sites using common patterns having such poor performance that I can literally watch a sequence of state changes take place and categorize them as they happen. Forget the ad experience. Common tech oriented sites linked on HN which make it to the front page will frequently show me three to four layout shifts as their fonts load.
> I think you may be misunderstanding here... some sites - especially news sites - use a dark pattern where they override the back button behavior to prevent you from going back (presumably to increase "engagement", or whatever). You could argue the web platform shouldn't let them do this, but that still wouldn't have to do with "slowness" (and wouldn't be solved by the OP).
This wasn’t some back button hijack, I double checked. It was a slow website meeting what I assume is a race condition in the browser, where the state change on load coincided with my decision to stop waiting. And it happens a lot on iOS Safari on perfectly trustworthy sites.
> This just sounds like a logic bug; bugs exist regardless of platform
Sure, like I said, race condition. But exacerbated by how slowly reverting some mistake might take effect.
> This is absolutely insane to me. I just tried changing the font size in a very large VSCode project with 10 files open and it took 1 second to change the font size for the whole app. Killing the entire app (Cmd+Q) and restarting it took 4-5 seconds.
> How many files do you have open? Are you using some crazy extensions that could be poorly-written or interacting badly?
Like I said I have 9-10 projects open. Assuming I have 10 files open in each (I have more, but that wouldn’t matter if the app we’re using native controls), that’s 9-10 times the same thing you tried. Each instance is its own process pool. But they’re all responding to the same event asynchronously.
> Again, totally crazy compared to my experience. I just refreshed the full window for the medium-sized org I'm in and it took 2 seconds for the UI to come back, and another 5 seconds to load the conversation text (the latter is pretty bad, but as I noted in my original post, not related to performance of the actual web platform)
This is also not comparable to what I described, you refreshed one instance vs my 8. And again this would not be an issue using native controls, which would not be running 8 separate instances.
- - -
You seem pretty focused on defending the web and web technologies in the abstract. I’m not necessarily even disagreeing with that. Although real world usage of web tech is the reason things are so bad that I do experience the performance degradation I describe.
I’m not your typical HN anti-JS zealot. I’m just very disappointed with how bad the common web based product is.
You’re mostly right that it’s not the underlying tech that’s bad but how it’s used. But not totally. It’s the only UI platform I’m aware of that developed a huge resource intensive multiprocess model to work around the fact that common usage routinely blocks shared resources and routinely crashes.