I think Google's Native Client is our best chance for something like what he describes.
It provides a sandbox for executing untrusted machine code (or PNaCl for more portable LLVM bytecode), downloaded on the fly, which would enable efficient implementations of things like HTML/CSS/JS.
I look forward to the day someone gets a browser rendering engine compiled and running in NaCl.
You also need some extra content-negotiation abilities, but that shouldn't be too hard: https://qht.co/item?id=2131870 . I'll pull out this bit:
> Finally, the process can chain, so a particular [data/DSL] file might be given to a display program which is a Ruby script which would in turn be given to a generic-runtime interpreter for the appropriate version of Ruby.
So it's untrue that using NaCl or something similar means that all code (let alone all data) has to be sent to the browser already compiled down to assembler (or PNaCl bitcode or whatever). Among other things, this is one important reason why Mozilla is wrong to claim that adoption of NaCl (or whatever) would mean that HLL/scripting-language/whatever code distributed over the Web would no longer be able to benefit automatically from speed improvements to the browser's HLL runtime(s). Chained content negotiation is your friend TM.
It provides a sandbox for executing untrusted machine code (or PNaCl for more portable LLVM bytecode), downloaded on the fly, which would enable efficient implementations of things like HTML/CSS/JS.
I look forward to the day someone gets a browser rendering engine compiled and running in NaCl.