What's worse is I don't even know how you're supposed to know what the edge cases are without stumbling into them. You shouldn't have to know about APIs like document.hidden unless you specifically want to handle background tabs differently. They shouldn't leak into the regular event loop.
When we were (slowly, painstakingly) making the Firefox UI compatible with multi-thread and multi-process, we hit this kind of issues all the time. One of the reasons we introduced Promise and async/await (née task/yield) in JavaScript was to give us a fighting chance to at least look at the code and understand where it could all break. And then we had to come up with the tools to actually debug these...
I think that it's a combination of two things:
1. many webdevs just have no clue what a thread is, because generally, they don't need it, so it isn't taught;
2. most of the documentation you can find online was written by people (and now ChatGPT) who don't understand async, sprinkle the word randomly and tweak things until they seem to work.
As a consequence, webdevs learn that async is magic. Which is a shame, because the underlying model is almost simple (the fact that we have both micro-tasks and tasks complicates things a bit).
Both your points, 1 + 2, are variations on that.
The right answer is the problem is the language design.
JavaScript doesn't have threads.
It looks like web workers is the way for JavaScript to do multi-threading.
Async has always been enough for what I need to do in the front end, as most of my long running processes are just calling a back end.
Edit to add: for context, I am a full stack developer and know what threads are... I just never have needed them in the browser.
On the other hand, the isolation guarantees are strong. There aren't really any footguns. Messaging is straightforward, works with a lot of data types and supports channels for inter-worker communication.
Yea targeting the web is nuts if you have other options!
You either have to split linear execution (hard although async can make this easier in languages like Python) or go multithreaded with its own difficulties.
But IME what typically happens, at least in desktop apps, is that doing a little work in the UI thread is fine until it isn’t, and the “not fine” moment can be months or years away from when the code is written. The bug reports are often vague and rare enough that it takes a while to see the pattern (eg: “it froze and then I killed the program”). And after enough of these problems, someone with experience puts a framework and some rules in place that move tasks off the UI thread. Which works until they creep back in.
I do a lot of work on a platform that has doubled in user base yearly since its inception, for about a decade (though I think we are at an inflection point now or soon), and it is wild to have “experts” be those with 2 or 3 years of experience. Having used the platform for 11 years, now it is crazy to believe I have more experience than 99.9% of the field.
I was being confused by blocked UI threads TWO decades ago (AWT or Swing or something), so I'm confused that it was confusing you one decade ago.