Whether it's a good addition to the language or not is debatable, but as a browser feature, it sounds terrifying. Browsers have a huge attack surface as it is (I mean, WebGL is a thing – exposing GPU drivers to random untrusted code on the internet, what a brilliant idea...), and exposing threading will only make it worse. Every single API would have to be carefully audited and made thread-safe, and I'm sure that many 'fun' bugs would crop up as a result.

Which is why the proposal specifically says that only a few DOM APIs would be exposed to background threads (Like console.log())

For that matter, anyone who'd like to have "fun" with concurrency and lock management in browser-side JS is free to play around with recurring asynchronous data fetching cached in localStorage when multiple browser tabs are open.

Spoiler: locks are the wrong approach and you should be relying on events/callbacks instead. Oddly enough, that's similar to my gut feeling about Threads in JS.

A browser can easily optimise HTTP or localStorage calls internally, without introducing Threads to the "userland" code.

I'm talking about a userland implementation.

Because of user inputs and networking, we already do not have determinism. And even without introducing thread feature, a site can spawn 10 threads each by using Web workers. So, it is not related to introducing threads.