> afiori: JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder
How's it going to do that? What's so bad about it? Especially in the multi-core era which lets multiple programs run at the same time the way that multiple pages can run javascript at the same time. The lack of preemption is only within a single page/program.
During periods of time where no single chunk of code runs for more than a millisecond, cooperative multitasking should have the exact same performance as preemptive multitasking. And even when single chunks of code do run for that long, if that code wasn't properly isolated then preemption doesn't save you from lag.
So the difference only shows up when you have chunks of code that keep running way too long, that are also inside of properly isolated threads/callbacks, and on web those threads/callbacks are not inside web workers. Is that a common situation?
Of course, doing everything in one thread most of the time makes everything easier, because you're using the thread as the lock, so to speak. But using locks is bad for performance and latency and thus UX.
Also look at single core focused systems like spacetimedb, sometimes if a workload is not embarrassingly parallelizable multithreading can make things slower.
JS needs some way to more easily push things off the main render thread, but i think that there is no easy solution for it. (maybe a model like iirc clojure had where "threads" would automatically rollback and retry in case a data race was detected could work to handle off-threads tasks in js, but it is a quite far off solution)