Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yah, that's the one. And we'll see if he delivers, but I know one thing right now: when I sit and wait while one very slow site freezes the whole browser, I get quite annoyed.

Does he not realize that the browser is basically the OS these days, and he's keeping it in Windows 3.0 territory?

It's time to make a thread for the UI, and a thread for each window, and each tab (child windows AKA popups, shall thread with their parent). JS can't cross those walls anyway, so his probably with concurrency are not as bad as he thinks.



I think Eich is advocating against explicit thread support in JavaScript like e.g. Thread.run() in Java. Separate threads per tab is an unrealated issue as long as the tabs cannot communicate. Tabs might however be able to communicate if one tabs opens another through script. In that case it might introduce racing conditions if the tabs runs in different threads.

Btw in HTML5 there is a proposal for cross-window communication http://www.w3.org/html/wg/html5/#crossDocumentMessages which is asynchronous. This would allow communication between different threads using message passing.


>I think Eich is advocating against explicit thread support in JavaScript

Oh! Well I sure read that wrong. I thought he was against threads in the browser. So I guess there is hope.

If one tag opens another, it's a child of the first, so they should thread together.

Javascript already has threads anyway (setTimer, and events), they are just serially scheduled - on a single core it's identical to regular threads. So you already have to deal with concurrency issues in javascript apps (although it's not as bad as full threading since I think a single function is allowed to run to completion before something else is scheduled).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: