There are ways this story fails in practice, like the "language mismatch" I mentioned. For example, in Google Web Toolkit, which compiles Java to JavaScript, t

There are ways this story fails in practice, like the "language mismatch" I mentioned. For example, in Google Web Toolkit, which compiles Java to JavaScript, theoretically the static type information should be a huge boon to optimization. And indeed, the compiler does some fancy stuff, including static inlining, and segmenting the code so that chunk 2 is only downloaded when a method call crosses the boundary of chunk 1. However, consider something like a HashMap. A JavaScript programmer might use a single JS object as a hash, whereas the GWT programmer has the luxury of using a java.util.HashMap, which is theoretically compiled down to something efficient, maybe just as efficient. In practice, this is hard or impossible for the compiler, and HashMaps are compiled to a system of objects that's much more complex. There are great reasons for this -- primarily, HashMaps can have any object as a key, not just a string; also the nature of the HashMap API and behavior under subclassing -- but the result is if you want something fast, you need to use a FastStringMap or some such class, backed by a "native" JS object. But in general, when you're not worrying about performance, you might find yourself using many HashMaps, even parsing JSON into nested HashMaps! So now each JS object is represented by a bunch of JS objects needed to make the mechanics of the HashMap abstraction work. I worry that not having arrays leads to a similar problem. In magic happy land, a call like List.pop that removes the last element of a list would be implemented as a tail-recursive operation on heads and tails, which the compile would then recognize and turn back into a call to Array.pop! In practice, this kind of thing is unlikely. As with HashMaps, the programmer is forced (or told) to use heavyweight data structures to simulate lightweight ones, with the hope that the compiler will recognize that this is a case where the lightweight structure applies and transform it back! As for "online" compilation, I guess this is easier on the JVM. Clojure, Rhino, Scala, and Java are all compiled and can be set up to recompile on the fly after every change to the program. Node.js too. Having developed this way, I don't think I could go back to having to do anything after changing the code besides reloading the page.