I'd love to be able to script in a browser in multiple different languages. I've been thinking about this lately. If we had some sort of lightweight VM embedded

I'd love to be able to script in a browser in multiple different languages. I've been thinking about this lately. If we had some sort of lightweight VM embedded in the browser which took bytecode rather than interpreted source then many languages could successfully manipulate the DOM. As much as I like this idea, I don't think it will gain very much traction. Since no browser currently implements such a thing, and there's not any standard which includes a VM for DOM manipulation, it is extremely difficult to reach critical mass to the point that you can depend on your audience to have access to execute any bytecode you embed in your web page. Flash, Silverlight, and Air are VMs (I think?) which could be considered for this sort of project, and Flash at least has very high market penetration. But it's still a proprietary environment and I don't think I've ever seen it used for actual DOM manipulation, rather than as a self-contained "Walled Garden" of animations. Silverlight and Air are shooting for being platforms for rich client-side applications but they are not designed to be first-class citizens on the web, as part of the HTML / Javascript / CSS collection of standards. The Google Web Toolkit takes an interesting tack on running multiple languages in a browser. They compile their language (in this case, Java) with the Javascript interpreter being the target platform. It's a neat idea but it feels kind of odd to me to compile down to an interpreted language. As the next generation of JIT Javascript interpreters come to prominence this will be less of a performance issue and more of an aesthetic one. The advantage here is that you can piggy-back on all of the Javascript advances as they come along. Interpreting lisp, or any other language, from Javascript inside the browser feels klugey to me. It's just another layer of indirection which my gut instinct tells me will be very leaky, with a high performance overhead. I suppose you could write a VM in Javascript which executes compiled bytecode of your favored language. You'd then need to write a bytecode compiler for your language. At least you wouldn't need a separate interpreter for each language you wish to use in your page. But if you're going to have to write a compiler for your language (or at least a new compilation target for an existing compiler) why don't we compile down to Javascript rather than a new bytecode interpreter written in Javascript? If we could get the standards bodies to bless one particular VM specification then developers could use whichever language they like to do DOM scripting. They could include their compiled scripts directly in the page. Javascript would probably be the default, and the browsers would including compilers down to this bytecode representation. That's actually not too far from what the browsers are doing with Javascript today. There's just not a standard for what the VM looks like. Anyway, sorry for rambling on like that. It's Monday morning. I'd love to be able to have the capability to use whatever language I like for scripting a page, but I don't think it's very practical right now. Javascript is mostly Good Enough and has a lot of momentum in the browsers. In the long run I think that an open and standardized browser VM specification is the way to go but who knows when that will happen? In the short term if it's very important that you be able to use some nonstandard language for DOM scripting I think your best bet is to compile your language down to Javascript like the GWT does. That's an awful lot of effort though. I don't know how much advantage you will gain from doing that as opposed to just using Javascript in the first place.