4 ms·
> an embarrassingly large amount of the software I use on a daily basis for productivity runs in a single thread. My expectation was that UI blocking would be r
by zozbot123 8y ago
> an embarrassingly large amount of the software I use on a daily basis for productivity runs in a single thread. My expectation was that UI blocking would be rare- it isn't, particularly with Chrome, Firefox, and Slack. Jira in the browser is terrible- even with insane resources and 1Gbps bandwidth I regularly have to wait 10-15 seconds to be able to enter text.
Why would you expect anything different when JS _does_ run in a single thread? We'll have to wait for WebAssembly to have anything like real multithreading, with good-enough performance, on the Web.
- blattimwind 8y ago> Why would you expect anything different when JS _does_ run in a single thread? No reason for site A rendering to block site B; no reason for either to block the main UI. No reason for an issue tracker to take 10 seconds to achieve interactivity on LAN (heck, I'd consider 0.5 seconds slow).
- wongarsu 8y agoNot just in a single thread, in the same thread as DOM rendering. It's conceptually impossible to use a website in the time the javascript executes (except for webworkers etc). Still, javascript issues tend to cause too many hangups of other parts (browser UI or other websites). We are in the awkward position where OS threads are considered too heavyweight to use an entire thread for each tab, but browsers haven't implemented a more lightweight alternative either. So things just share threads when they really shouldn't.
- pythonaut_16 8y agoBrowser green threads could be amazing! Specifically an Erlang/Elixir-ish actor async implementation
- the8472 8y agolayout and rendering can happen asynchronously in background threads, but you have to carefully structure your JS code to not read back layout properties any time soon after modifying the dom, otherwise it will block and turn everything back into sequential execution