Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And this would be completely unnecessary if the JS code didn't run in the UI thread or in connection with the page (via user events). The reason to split up work and play with setTimeout() and friends is to avoid UI/page lock-ups or triggering the script max run timeout.

It's effectively co-operative multitasking where I trust the responsiveness of my browser to some random web coder.




The html5 web workers is the proposed long term solution: http://ejohn.org/blog/web-workers/

Writing GUI libraries (as the DOM is) which works with multithreaded code is hard, very hard, and often have awful performance.

So realistic solutions need to trade something: use co-operative multitasking or loose access to the DOM.


Well actually, there may be other ways, for example it may be possible to detect conflicts!

Run the code in separate threads, and then at the end of the routine (or at synchronization points) check for a conflict. If there was a conflict, re-run the code in-order.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: