Chrome runs a separate process for each tab, and that process includes the layout engine and the JS engine (V8) running in tandem. V8 has to be able to block the layout engine from rendering, otherwise it will draw invalid page states. The execution model (greatly oversimplifying) is that the browser runs a tight loop that monitors for changes to the DOM state and input events, and then synchronously executes JS code bound to these events (and the native handlers if they are not overridden), finally re-rendering parts of the viewport that become "dirty".
In a browser that isolates tabs into their own processes, like Chrome, try opening a tab for www.google.com and then enter this in your address bar:
javascript:document.getElementById('lst-ib').onclick=function(){while(1);}
When you click on the search box the entire tab will freeze, because the tab process is stuck inside the JS engine running the infinite loop function we bound to the click handler. It's not a matter of bad browser design, that's how the JS execution model is intended to work.
"Web workers" is the HTML5 proposal for running JS code that does not block the event loop. They do not have direct access to the DOM and can only communicate with JS code in the main event loop via a message passing API.