In defense of Firefox

> There's no reason whatsoever that tab1 needs to not render or
> respond because tab2 is doing something or other.

The reason is the ancient design decision that the UI and behavior would be customizable
through JavaScript extensions. As extensions are global (i.e. they can see and manipulate all
of your tabs and UI elements), they need to live in a single interpreter.

JavaScript has classically been a single-threaded language; making it multi-threaded now would
create a lot of confusion and unexpected race conditions; most developers cannot even begin to
imagine all the ways that, for example, the renderer and concurrent changes to a document's
DOM could interact.

Adding coarse-grained locking does not have much benefit: any interaction between concurrent
threads would still likely cause one to wait for the other to yield a lock. On the other hand,
with fine-grained locking, writing code to handle race conditions would make extensions and
Firefox more complex and more error-prone.

Furthermore, adding concurrent multithreading support to a high-level language is no easy task
and has a significant performance impact on the interpreter alone -- as Perl, Python, Ruby,
Smalltalk etc developers can confirm.

Now, I'm just playing the devil's advocate and pointing out all the problems with this
approach; clearly it is *possible* to rewrite Firefox as a multi-threaded browser, but it's a
decision that has to be made with great precaution.