Rejected thesis idea: web assembly language

I got clearance today to go ahead and blog about the various thesis topics that I have contemplated but have subsequently been rejected for various reasons (usually because of the lack of novelty).

To start off posts of this nature, I present to you the idea of a web assembly language. This came to me while thinking about justifications of bringing Python to the browser.

It seems to have become a popular thing to compile down to JavaScript. Look at the Google Web Toolkit (GWT) or Links from Philip Wadler. Some have even gone as far as to translate Java bytecode into XML and then have that executed on an interpreter implemented in JavaScript (this is done by XML11)!

Obviously some people don't like coding in JavaScript and want to have support for other languages. But as there is no other target on the browser for coding, people compile down to JS. I wondered if some assembly language couldn't be developed that was web-centric. It would provide some assembly-level primitives for basic DOM access and socket communication (ala AJAX, but better). And of course it would be safe to use. Then everyone would have a common compile target and the world would not have to use JS anymore. JavaScript itself could be compiled down to this assembly language on the fly in the browser.

In the end, though, we rejected the idea. There is nothing explicitly wrong with targetting JS; I just don't like targeting such a high-level language. Practically it would destroy the readability of web source. It also seemed like Flash is kind of the unofficial assembly language. There is also Tamarin on the way which could expose its bytecode. Hell, I could just move over Java's or .NET's bytecode and use that somehow as they already do verification at some level.

There is also a fundamental shift in development style. Suddenly web development would be compiler-based. Some people like that, some don't. You could keep JavaScript around, but then it would definitely be locked down as the only scripting language in the browser unless you added some hook for JIT compilers for various languages.

And browser compatibility would be an issue as well. What if IE and Mozilla implemented a single opcode differently? That could be much more disastrous than the incompatibilities we have now.

So this idea got dropped. I still would not mind seeing this happen some day, but it won't be me for my Ph.D. thesis.