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?
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.
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).
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.
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.
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.”
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.
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.
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.
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
To understand the difference in threading needs between Java and JavaScript it is important to think about their different usages. One of Java’s main usages has grown to be for application servers (since applet’s failure). In application servers, threading is critical, and Java’s somewhat complicated, but robust premptive threading technology is very well suited for the environment. However, JavaScript runs in a browser, and so it is just running for a single user, there is no need to be concerned about other users. Therefore threading is not nearly as important (at least preemptive). And yes, browser based JavaScript is indeed single threaded. However, there are major programming advantages to a single threaded machine. There are a quite number of extra concurrency concerns when dealing with multi-threads (especially preemptive), and these concerns go away in single threaded environment, greatly simplifying programming, as well reducing bugs (and concurrency induced bugs are notoriously difficult to track down and fix, because they are often difficult to reproduce).
What Narrative JavaScript has introduced is form of threading that is cooperative. It is important to understand the distinction between cooperative threading (threads don’t switch until they give up control), and preemptive threading (threads are switched by a timer in the OS). Preemptive threading is very important when dealing with multiple threads that need to compete for resources. This is essential for the OS when dealing with multiple processes and for application servers handling multiple users. However, preemption is not nearly as important in a single application when a programmer has full control of when threads release control. Therefore cooperative multitasking is very well suited for the browser. In addition, many (not all) of the concurrency issues go away with cooperative threading, because as programmer can be certain that thread switching will only take place in known situations (on calls to functions that can yield/suspend), instead of at anytime as with preemptive threading. This gives a much more predictable situation and greatly reduces concurrency issues.
I am a big fan of Narrative, and my project Authenteo is built on Narrative. I use multiple cooperative threads extensively in my project, and think it is amazingly powerful. My system uses a rendering/templating engine which makes Ajax calls to collect data as needed to perform rendering, and can split off into multiple threads as needed to do this. It is really comes together very powerfully. Also, you can see the power of threading in my animation article which was Ajaxian a couple weeks ago.
Come on, please, stop the discusion of handing thread access over into the hands of webapp coders. Concurrent programming is intrinsically hard! The thread programming abstraction is fundamentally flawed. It was an ingenious insight NOT to make Javascript multithreaded, it would have failed like Java. Please keep Pandoras box closed(for web application developers), work on getting browser code rock solid and surviving whatever scripting disaster the creative javascript minds are inflicting on us and keep thread access hidden away for beeing handled by educated adult personal only.
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.
Check out threading in Firefox’s nightlies. Synchronous XHR requests no longer block UI interaction. A HUGE improvement. Been in for a while now.
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.
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.
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!
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.
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.
I think the iframe hack can be use threading.