> But using locks is bad for performance and latency and thus UX. yeah but this way you have only one lock, with free threads or preemptive multitasking you ha

> But using locks is bad for performance and latency and thus UX. yeah but this way you have only one lock, with free threads or preemptive multitasking you have to have them sprinkled into every data structure each with its potential for deadlock and livelocks. 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)