I know this is Slashdot, but you must be talking about Google here.

If they can tell legal from non-legal, why do they even show the illegal stuff?

In related news, most people earning over $1M through the development of an iOS app have the profession: software developer.

A man is sitting in this ship, and throws a massive Korean-made LED TV-screen overboard into the water.
As a result, will the water level rise, or drop?

Please don't forget that the whole point of my comment was that threads are broken in JS.

The problem with event-driven/asynchronous programming is that it requires a lot of work, and makes your code look awkward. For example, a simple "for" loop turns into a monster of functions calling eachother, in order to break the inside of the for-loop into small chunks that can't lock the UI. Now imagine a doubly-nested for-loop. You'd need special compilers to keep your code clean.

Remember that Windows 3.1 was replaced by true multitasking for a reason.

Also, asynchronous code can only make use of 1 core of your CPU, which is also a waste.

A customer just called. He pressed "Ctrl+End" to go to the end of the document, while it was counting words. He complains that the user interface is frozen.

Yes. But because of this problem of the (fictituous) customer, I now have to rewrite my 30.000 lines of code from web-worker style to single-threaded asynchronous style. Unless you have a better idea :S

The problem is that "threads" are supposed to be a solution to dividing work.
If you don't have threads, how will you divide work without ruining the nice hierarchical structure of your code?
You'll need a special compiler that does this for you. And the result will be *slow* (albeit perhaps more responsive).

Let me get this straight. This means that when the user scrolls the document, the web-worker would feed the GUI with lines of text incrementally (?)
However, if, at the time of scrolling, the web-worker would be busy counting words in the document, I don't see how the GUI would not *effectively* freeze just as well (the main thread would be waiting for new lines from the web-worker which is busy counting words).

This is like splitting up the task of counting words into smaller tasks that execute incrementally.
"Splitting-up tasks" is the keyword here, and the thing is, that's what threads are supposed to do. If we split up all our tasks manually, we wouldn't need threads.
The web-worker thread-model is not really helping, because we'd have to split up tasks anyway ourselves.

You're probably still running Windows 3.1, with pre-emptive multitasking.

Web-workers are not cutting it. For the following reason.
Real multi-threaded programs have a shared address space. Web-workers do not.

Example: suppose your GUI runs on a 1 megabyte long text-file.
The data-structure that models the text-file is 2 megabytes long.
Now you want a web-worker to do something with this text-file in the background (e.g., count the number of words).
So you start a web-worker thread. But then you need to send the text-file as a message to the thread (since there is no other way the thread can reach the data).
Sending this 2 megabyte chunk of data will surely freeze your GUI for a while, and so the whole point of multiple-threads is mostly lost.

The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language. It's like going back to the 80s.
This means that when processing one action of the user (especially if it is a complicated action), the user interface will temporarily freeze.
In this day and age, this is totally unacceptable.

Totally agree with that.

The only problem seems to be the acceptance of NaCl by the other big browser vendors (Microsoft, Mozilla).

Here's what wikipedia says:
(warning: could be outdated)

See http://en.wikipedia.org/wiki/G...

Interesting. Do you know what book(s) on data-mining are most widely used/seen at Google?
Just curious.

vi versus emacs?

However, your note is taken. This won't look good on your Google "behind-the-curtains" resume.