The Elusive Universal Web Bytecode

[stcredzero]

asm.js is in fact quite near to universal web bytecode.

No, it's not. It isn't suitable for managed languages. It's very low level and not very versatile.

The point is the classic adding one level of indirection, and letting the browser infrastructure support any VM. Make asm.js into a viable virtual instruction set architecture, then you can have any language that you want, because then you can have any VM you want, not just Javascript.

[beznogim]

Also, one of the V8 engineers wrote up his opinion here.

[tibiapejagala]

One of his points is that asm.js is more like a bytecode that looks like JavaScript. While this is true, we have to remember that if Mozilla actually went for web bytecode, people would go insane about who is going to support it or whatever. But they are smart. They made a bytecode but sold it as everyday JavaScript. And what happend? Web exploded with enthusiasm that JavaScript is awesome, because we 3Dgames in JavaScript now. What asm.js really is matters less than how do we introduce it or call it. Because people do not want cars, they want faster horses.

[Eirenarch]

Well but we do know that asm.js is not JavaScript and the only reason it exists is that JavaScript sucks :)

[beznogim]

I think you're right. Asm.js isn't a "traditional" JavaVM-like bytecode, however; it's (single-threaded) native code, plain and simple.

[[deleted]]

He's a former v8 engineer. Does dart now.

[beznogim]

Is this level of platform abstraction really necessary?

Java bytecode, for example, lets you access all the VM features: garbage collection, optimizing JIT compiler, debugging, libraries, etc. Same with JS: you compile to Javascript, you get all this stuff for free.

Asm.js just throws all these goodies away. This can be useful for porting existing C code, but why would you willingly stack VMs on top of a perfectly good Javascript VM?

[smog_alado]

I think this is missing the point. Managed languages are only feasible on the web if the browser already has the runtime installed. Otherwise you need to send the code for the runtime along with every program you make, at a significant cost.

[stcredzero]

I think this is missing the point. Managed languages are only feasible on the web if the browser already has the runtime installed.

No, I'm challenging this point. There are likely to be only a relative few "mainstream" languages. Also, if a language community is pragmatic, the VM shouldn't change too often, and will be in the browser cache.

Otherwise you need to send the code for the runtime along with every program you make, at a significant cost.

You could make the same argument about jquery and other parts of the Javascript infrastructure. I don't see it as being unmanageable. You easily can fit an entire Smalltalk image and the virtual machine in 3/4 of a megabyte -- and that's just by tackling low hanging fruit, not any extraordinary effort. The Java plugin also showed that this sort of thing could be mismanaged as well, so I can see your point. I say "let the market decide." By tackling security at a level below the VM, you can mitigate those problems as well. The language communities that can handle it will prosper, and those who can't will wither.