Ajax Girl

Joe Walker (DWR. I know you know) is talking about The Hardware of Tomorrow Versus the Platform of Tomorrow.

The problem is that web-browsers are a step backwards as far as multi-threading goes. In Javascript there is no such thing as a new thread, and worse than that, the entire platform (i.e. a browser) runs a single JavaScript thread. If a script in one window goes into a tight loop, or runs some synchronous Ajax then the browser HTML display freezes.

So are the any solutions?

• Adding thread primitives to Javascript might technically possible, but it seems to me to be impractical; the single-threaded assumption is built fairly deeply into many applications.
• It might be possible for browser manufacturers to create a thread per domain. I don’t see how this could cause problems, but I’ll admit that I have a suspicion that I’m overlooking something. If it does work then it might be possible to allow developers to create new threads by dynamically creating iframes in other domains and having some safe way to communicate between them.
• There is a Javascript pre-compiler called Narrative JavaScript that looks like it might be of some use: it contains a spawn() method to start a new thread of execution. It’s written in Javascript so you can deliver the pre-compiler to the browser or deliver the output. However until there is support for something like this at a language level that can exploit newer hardware, it doesn’t solve the problem.

The solution that I’d like to see is a language emerging that pushes the job of creating threads to the compiler, that runs on the JVM, and that is available in all browsers. I think I can safely predict that this is not going to happen any time soon though.

I agree that it will be interesting to see how Ajax fits in after we see great looking apps via WPF and the new Apple APIs (and Apollo….).

However, faster CPUs also mean faster running Ajax applications.

And, threading? The idea of having actual threading code in Ajax apps scares me. It is hard to get threading code right. We don’t want to repeat the problems of the past by making people mess up multi-threaded code. Instead we need to have better mechanisms for handling concurrency and threads. If we ever go there, we can learn from COmega and the world of chords.

What do you think?

Source: Ajaxian
Original Article: http://ajaxian.com/archives/the-hardware-of-tomorrow-versus-the-platform-of-tomorrow