Why doesn't JavaScript get its own thread in common browsers? -

not enough javascript isn't multithreaded, apparently javascript doesn't own shares thread load of other stuff. in modern browsers javascript typically in same queue painting, updating styles, , handling user actions.

why that?

from experience immensely improved user experience gained if javascript ran on own thread, alone js not blocking ui rendering or liberation of intricate or limited message queue optimization boilerplate (yes, you, webworkers!) developer has write keep ui responsive on place when comes down it.

i'm interested in understanding motivation governs such seemingly unfortunate design decision, there convincing reason software architecture perspective?

user actions require participation js event handlers

user actions can trigger javascript events (clicks, focus events, key events, etc...) participate , potentially influence user action single js thread can't executing while user actions being processed because, if so, js thread couldn't participate in user actions because doing else. so, browser doesn't process default user actions until js thread available participate in process.

rendering

rendering more complicated. typical dom modification sequence goes this: 1) dom modified js, layout marked dirty, 2) js thread finishes executing browser knows js done modifying dom, 3) browser layout relayout changed dom, 4) browser paints screen needed.

step 2) important here. if browser did new layout , screen painting after every single js dom modification, whole process incredibly inefficient if js going make bunch of dom modifications. plus, there thread synchronization issues because if had js modifying dom @ same time browser trying relayout , repaint, you'd have synchronize activity (e.g. block operation complete without underlying data being changed thread).

fyi, there work-arounds can used force relayout or force repaint within js code (not asking, useful in circumstances).

multiple threads accessing dom complex

the dom big shared data structure. browser constructs when page parsed. loading scripts , various js events have chance modify it.

if had multiple js threads access dom running concurrently, you'd have complicated problem. how synchronize access? couldn't write basic dom operation involve finding dom object in page , modifying because wouldn't atomic operation. dom changed between time found dom object , when made modification. instead, you'd have acquire lock on @ least sub-tree in dom preventing being changed other thread while manipulating or searching it. then, after making modifications, you'd have release lock , release knowledge of state of dom code (because release lock, other thread changing it). and, if didn't things correctly, end deadlocks or sorts of nasty bugs. in reality, you'd have treat dom concurrent, multi-user datastore. more complex programming model.

avoid complexity

there 1 unifying theme among "single threaded js" design decision. keep things simple. don't require understanding of multiple-threaded environment , thread synchronization tools , debugging of multiple threads in order write solid, reliable browser javascript.

one reason browser javascript successful platform because accessible levels of developers , relatively easy learn , write solid code. while browser js may more advanced features on time (like got webworkers), can absolutely sure these done in way simple things stay simple while more advanced things can done more advanced developers, without breaking of things keep things simple now.

fyi, i've written multi-user web server application in node.js , amazed @ how less complicated of server design because of single threaded nature of nodejs javascript. yes, there few things more of pain write (learn promises writing lots of async code), wow simplifying assumption js code never interrupted request drastically simplifies design, testing , reduces hard find , fix bugs concurrency design , coding fraught with.

discussion

certainly first issue solved allowing user action event handlers run in own thread occur time. but, have multi-threaded javascript , require whole new js infrastructure thread synchronization , whole new classes of bugs. designers of browser javascript have consistently decided not open box.

the rendering issue improved if desired, @ significant complication browser code. you'd have invent way guess when running js code seems no longer changing dom (perhaps number of ms go no more changes) because have avoid doing relayout , screen paint on every dom change. if browser did that, js operations become 100x slower today (the 100x wild guess, point they'd lot slower). and, you'd have implement thread synchronization between layout, painting , js dom modifications doable, complicated, lot of work , fertile ground browser implementation bugs. and, have decide when you're part-way through relayout or repaint , js thread makes dom modification (none of answers great).