I know web programmers generally aren't big on assembly or writing virtual machines, but an instruction set (group of bytecodes) design and implementation predisposes a processor/VM to certain operations. A VM for an OO language is going to have bytecodes (and other infrastructure) for doing fast method lookup, because it will really hurt performance otherwise. A functional or logic language VM will probably have tail-call optimization, perhaps opcodes specific to pattern matching / unification, and a different style of garbage collector.
There are a LOT of details I'm glossing over (e.g. sandboxing/security concerns, RISC vs. CISC, the DOM), but I've been meaning to point this out since I read someone saying, "Why do people keep writing more VMs? Why don't we just use the JVM for everything and move on?" It's not that easy.
For example, Smalltalk has an advantage compared to Java in which designers of VMs can change the opcodes as needed to get better performance. That's not possible with Java because of the JVM.
The future of the language may be compromised by the decisions you make on the VM. For example, think of the problems Java has in fully supporting 64 bit software -- most of it based on the decisions that were made when 32bit processors where the norm.
All of this makes me think that if I was a VM researcher, I'd seriously consider going in this direction. And not being a VM researcher makes me think maybe I should be one.
Nitro follows lot of luajit methods and techniques some are outlined here by Mike Pall - http://article.gmane.org/gmane.comp.lang.lua.general/58908
Some adopted by Nitro - http://webkit.org/blog/189/announcing-squirrelfish/ Nitro does the js-code -> bytecode -> jit-optimization.
However the more beneficial question is how long does it take it to convert js-code -> bytecode and how much it boosts overall performance. Seems like it is very small compared to execution times. https://lists.webkit.org/pipermail/squirrelfish-dev/2009-May...
On the contrary V8 does the direct compile yet following jvm/jit techniques. More details by Lars Bak here http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-E... and here http://www.youtube.com/watch?v=hWhMKalEicY V8 does some more non traditional things like snapshotting, hidden classes, etc which give incremental performance boost. If there was a bytecode standard some V8 techniques might not be applicable but it is possible to maintain the performance boost.
I would love to see bytecode getting as a standard so that people prefer to stick to whatever language they are comfortable with. For instance I like both js and python but if there was an option, I would stick to python for all my needs.
For example, imagine that there was no threat of being sued by Oracle, etc. You could just use the JVM - that already has lots of things that compile to it which work reasonably well. I'm not arguing that we should use the JVM, but only that something like the JVM seems to work reasonably well.
Anyway - having a way that's OK or reasonable to run (say) Ruby in the browser is a lot better than the current situation where there is no such way (without using proprietary stuff).
One of the largest requirements here would probably be a method of linking against/using C libraries, and also a standard for 'import/#include/etc' statements.
Maybe I'm being naive here though. Feel free to correct me.
Unless I'm completely misunderstanding NativeClient, that's not what it's about.
The downside is that if the bytecodes are low level the chances of different languages interoperating easily are small (e.g. take x86 assembly: Python doesn't automatically interoperate with Ruby, but take MSIL, now they do more easily).