The author is Alon Zakai, creator of emscripten, and the article is quite old (2013) when there was a somewhat heated debate whether a byte code format would be better for the web instead of Javascript, with the byte code fans having fairly theoretical reasons (basically: 'because it is the right way to do it and Javascript sucks anyway'), instead Alon went ahead and demonstrated that in reality the more pragmatic solution to compile to JS has no disadvantages compared to byte code, and you don't need to add a whole new language engine to browsers (like Google PNaCl does), but (in the case of asm.js) only fairly minor modifications to existing JS engines, and you keep full compatibility (but lower performance) with old JS engines.

Interestingly, emscripten now also supports an interpreted byte code mode (called emterpreter), which stores code in a byte code format, and runs this inside an JS interpreter(!). The reason for this was quicker startup time for large scripts, but (my own speculation!) it might also be a path to a future byte code distribution format if there are indeed any other practical advantages.

Another interesting point is that Safari actually has now an LLVM based compilation layer in their Javascript engine, so it's coming together from both sides with LLVM being the glue (emscripten's front end is also LLVM).

> more pragmatic solution to compile to JS has no disadvantages compared to byte code

The disadvantage is that compilation takes a not-insignificant amount of time, particularly if you want to go from running AST on a VM to running platform native code. It takes even longer if you're on an underpowered device which could take the most advantage of a simple IR bytecode -> native bytecode compilation.

This is evidenced in the 50% numbers from the OP's article.

LLVM's IR makes no stability guarantees - it can change from one release to the next, with no backward compatibility. That's not ideal for something you're slinging out to the web.

I believe this is the same reason Khronos defined their own IR (SPIR) instead of using LLVM's. Needs to be stable.

That is one reason, the other is being easy and fast to process with tools.

You mean SPIR-V, SPIR is LLVM based

> So why did the author throw out LLVM byte code again? It's BSD, it has bytecode compilers for most platforms browsers exist on (100% vs. 50% speed), and doesn't rely on a subset of another language. It also doesn't have the requirement to fall back to vanilla Javascript. As an added bonus, Javascript could easily compile down to LLVM bytecode.

LLVM has a single implementation, is very complex, isn't even remotely portable, and is primarily suited to C and C++, or similar languages.

We also already have a very performant transformation format for LLVM IR into JS: asm.js. And asm.js fixes most of LLVM IR's problems:

* It's very simple

* It's portable across architectures

* It doesn't have undefined behaviour

* It has multiple implementations

* It has forwards-compatibility (existing browsers, regardless of explicit support, can run asm.js code)

* It is standardised

Well put. One nit: I think you mean backwards compatibility, though asm.js can also be expected to work without modification in future browsers and future versions of javascript.

Yeah, I originally put backwards-compatibility, but I wasn't sure if forwards-compatibility was the right word for allowing old software to use new code.

LLVM IR isn't portable, it's platform-specific.

For those who don't know why that is true (or even that that is true): http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...

And yet Mozilla can use it to write Rust compilers which target ARM and x86-64 architectures, for Mac, Linux and Windows OSes.

It might not compile on an AT-MEGA, but it seems portable enough for the purposes of acting as a browser bytecode representation.

They distribute Rust as Rust code, not as LLVM IR. You use LLVM to compile Rust to a target-specific IR and then to a target-specific binary. Try reading that link your sibling posted.

I don't know if maybe the page relies on JS being enabled to load some content and you have JS disabled or not, but there is significant discussion of LLVM on that page.

> So why did the author throw out LLVM byte code again?

"Again" is right. I don't particularly seek out discussions on this topic, but I've seen this question asked and answered at least half a dozen times before, which is enough for it to start getting annoying.