If your goal is to have a lisp implementation running in your browser, there's another approach which I think is interesting: Google developed this technology for Chrome/Chromium called "Native client" (https://code.google.com/p/nativeclient/) which allows running native code in Chrome in a sandboxed environment.

You can check my experiments with it here: https://github.com/ageneau/ecl-android. It includes a sample ECL REPL web application based on "hterm". Compiling ECL for this toolchain requires very little changes to ECL itself.

Unfortunately it looks like other browsers won't pick up the technology so this is limited to Chrome/Chromium.

Current limitations:

* Single threaded -> This is because NaCL doesn't have sigprocmask

* File system access not implemented* GMP/MPIR uses the fallback C implementation so is probably not very performant

In theory CL core consists of 25 special operators + build-in data types. Everything else
is a library. So when porting to a new platform, theoretically, all we need to reimplement
is a compiler understanding 25 operators + some build-in functions representing datatypes
(make-array, aref, cons, etc) and some basic reader, allowing to read the source code of the library.

That is indeed the theory. In practice much of the library deals with operating system stuff: memory allocation, files, etc. That forces a low level implementation of several core structures. Moreover, several functions are critical for performance and are also hard-coded to make bootstrapping faster.

How close this theoretical view to practice? We now have several open-source CL implementations.
If one wants to create a Javascript port, what else he must be prepared to solve?

ECL is pretty well isolated: the C library works like the lisp API and offers a number of functions that one may start with. Many of those functions could _nowadays_ be ported back to Common Lisp, using the fact that the compiler is more efficient. But there are critical things, such as the filesystem, running processes, or I/O operations, that would be hard to implement from scratch.

Perhaps Christian could comment, given that he is using the ECL Common Lisp base to implement a LLVM-based Common Lisp implementation