4 ms·

Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each... For browsers, this is a bad idea. The biggest adv

Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each... For browsers, this is a bad idea. The biggest advantage of the event loop approach is that it is somewhat deterministic. With threads, that determinism goes out of the window. Lock-management? No way I do that for Browsers. I will quit working on client-side code if that is becoming a requirement! Threads for the server-side? I don't care.

rmrfrmrf 9y ago
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.
- einrealist 9y ago
  A browser can easily optimise HTTP or localStorage calls internally, without introducing Threads to the "userland" code.
  - rmrfrmrf 9y ago
    I'm talking about a userland implementation.
blockoperation 9y ago
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.
- TheCoreh 9y ago
  Which is why the proposal specifically says that only a few DOM APIs would be exposed to background threads (Like console.log())
yusukesuzuki 9y ago
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.

rmrfrmrf 9y ago

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.

einrealist 9y ago
A browser can easily optimise HTTP or localStorage calls internally, without introducing Threads to the "userland" code.
- rmrfrmrf 9y ago
  I'm talking about a userland implementation.

blockoperation 9y ago

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.

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

yusukesuzuki 9y ago

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.