remotely related, but I've always wondered how hard it would be to do the opposite (for those who haven't read the article he mentions in the beginning that the round about goal of javascript mode is to eventually write emacs extensions in javascript); Would/could/should it be possible to use Lisp in a browser in place of javascript? you know, script type="text/lisp". Just totally replacing javascript for dom interaction etc. with lisp. Is that insanity or have other people thought similar things?
I thought it is probably pretty easy to write a LISP interpreter in Javascript (or a Scheme interpreter), so why not do that and have it execute your LISP code? I thought about that recently, when I took up Scheme programming again - so no, you are not alone ;-)
I assume it is easy to write such an interpreter because it is frequently an exercise in LISP classes, and I think it has been done many times before (for example I think some games took that approach, using LISP as a scripting language).
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.
People who wonder what's so great about Lisp's s-expression syntax should read the bit about indentation. 27k lines of code to do a good job of indenting C-like languages!
