Wednesday, January 24th, 2007

The Hardware of Tomorrow Versus the Platform of Tomorrow

Category: Editorial

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?

Posted by Dion Almaer at 8:28 am
17 Comments

+++--
3.5 rating from 22 votes

17 Comments »

Comments feed TrackBack URI

It’s hard to ignore the current direction that the web is going, with more and more web based apps replacing traditional client side applications.

With the previous opinion that javascript being some sort of heinous affront to accessibility slowly going away (good javascript development mind you that enhances an application rather than controls it), Javascript is the sleeping giant of the web.

That said, it is obvious that SOMETHING needs to change in regards to the support that client machines can provide. Though libraries like Prototype, Dojo and Backbase are maturing, they are also getting bigger and bigger. To quote, we live in a just add water society. We want more, and we want it now. Bigger, more featured, but with flexibility comes complexity, and this directly relates to the size of our web based applications.

Yes, threaded javascript applications is a scary notion. But with the way things are going, it’s bound to happen. It’s just a matter of when.

Comment by Ryan Brooks — January 24, 2007

Very timely since I just saw this article yesterday on the O’Reilly Radar (Threads Considered Harmful – http://radar.oreilly.com/archives/2007/01/threads_conside.html).

Comment by Brian Yamabe — January 24, 2007

I agree. Java-style threading is too complex. As much as I think JavaScript needs a concurrency implementation, I’d rather have none than deal with Java threads.

Comment by Neil Mix — January 24, 2007

Each web page should sport a seperate javascript interpreter running on its own thread. It would not be wise to introduce a concept of true threads and shared memory in javascript – too complicated.

Comment by Jeb — January 24, 2007

Personally, I think we need to stop the escalation of abuse of the HTML web and start working on the next version. Now that we’ve all learned what we have, and about how users are using connected technologies, its time to move forward with the “next big thing.”

I haven’t the foggiest idea what that is precisely, and its likely built on top of XML and HTTP as a transport mechanism, but the way we have to build things to achieve the results we want is ludicrous. Sure, third party libraries are helping with this a LOT, but its still “too hard.”

Comment by Dave Sanders — January 24, 2007

well, creating a simple method that spawns a thread should be as easy as*:

Function.prototype.timeout = function($msec, $argv, $scope) {
var $self = this;
var $id;

function invoke() {
$self.apply($scope || this, $argv || []);
}

var $thread = {
start: function() {
$id = window.setTimeout(invoke, $msec);
},
stop: function() {
window.clearTimeout($id);
}
};

$thread.start();
return $thread;
};

and while we’re at it:

Function.prototype.interval = function($msec, $argv, $scope) {
var $self = this;
var $id;
var $startTime = 0;
var $stopTime = 0;

function invoke() {
$self.apply($scope || this, $argv || []);
}

var $thread = {
start: function() {
if (!this.running()) {
$id = window.setInterval(invoke, $msec);
$startTime = new Date().getTime();
}
},
stop: function() {
if (this.running()) {
window.clearInterval($id);
$stopTime = new Date().getTime();
}
},
running: function() {
return $startTime > $stopTime;
}
};

$thread.start();
return $thread;
};

* I have to be honest, I’m writing these from memory so some tweaking may be needed.

Comment by Mikael Karon — January 24, 2007

I think most people are still getting used to the idea of closures and how ‘this’ works in javascript, if they are aware of it at all. I don’t have much hope for most ajax developers becoming competent in concurrency.

Comment by Rob Sanheim — January 24, 2007

What would a mostly event based language gain by adding threads? It would perhaps become more useful for other purposes, but I would first like to see the case made that concurrency is essential for the purposes JavaScript exists.

But I was surprised to learn browsers run JavaScript on a single thread. Is that really true? That’s scary. It means the more windows you have open with JavaScript polling in the background, the slower the browser experience becomes.

Comment by Berend de Boer — January 24, 2007

I dont think thread will be an important feature in javascript, but i agree browser should create one thread per site. But if thread have to implemented in javascript, i think it should implemented on next version with carefull usage design, so overall language usage became similiar, without odd function calling

Comment by depok — January 24, 2007

I think that browsers has to use threading for each page. And about threads in JavaScript, it can be very useful for many purposes (like animations and data manipulations at same time). But there must be a simplier way to do it than Java threads implementation. All in hands of Mozilla Foundation/Opera Software… And in fact threads are not so bad.

Comment by Wojciech SiudziÅ„ski — January 24, 2007

Check out threading in Firefox’s nightlies. Synchronous XHR requests no longer block UI interaction. A HUGE improvement. Been in for a while now.

Comment by Simon — January 24, 2007

Threads are baaaaaaaaad tool for client side development! They are so hard to use and even harder to turn back into safe predictable applications once you open yourself up to using them. They also radically change your coding and make it difficult to build reusable code because of the asynchronous nature. I think the web community is too focused on threading because that’s the one thing we’ve had in the past to do concurrency for the past 10-15 years. But, they are alternatives.

Continuations are much much simpler predictable and aford better reusable code. You don’t have loads of complicated join, sleep, wait, synchronization semantics. Or like in Swing heavy use of SwingUtilities.invokeLater junk. Bigger plus is you write your application as if you’re writing a single threaded application. So what’s worse? Using threads, which require just about the same overhead, synchronization, write loads more code or doing full continuations?

I think the javascript 2.0 group should look into them again, and forget generators.

Comment by Charlie Hubbard — January 24, 2007

I believe that Mozilla’s JS rendering library (SpiderMonkey) support threading but doesn’t provide it down to the web pages. I know that the browser’s UI JavaScript (XUL/JS) can create threads by using the nsIThread interface. Basically my point is that it’s already built-in but not implemented at the page level.

Comment by Jeremy Gillick — January 24, 2007

What do you mean it’s too hard. If the feature is there it doesn’t mean you have to use it. Let’s ban Java too no? Stay away from it it won’t hurt you!

Comment by Shazam — January 24, 2007

Actual threading is an interesting thought for JavaScript, though it seems the asynchronous nature of the ajax calls themselves are nearly threading in and of itself. That would leave being able to set the priority on the calls and being able to set a call to sleep or idle when needed two of the remaining pieces to have something like an actual thread.

Comment by Chris Ash — January 25, 2007

Chris,
Asynchronous XMLHttpRequests use queued, not threading. They are completely different because there is no continuitity of call stacks, and blocking of code execution. By using continuations (emulated or native) you can emulate cooperative threading however, because you continuations allow contininuity of call stacks.

Comment by Kris Zyp — January 25, 2007

I think the iframe hack can be use threading.

Comment by Patrick Whittingham — January 26, 2007

Leave a comment

You must be logged in to post a comment.