safetydank's comments

Serif has had a solid Windows vector drawing app (DrawPlus) for a long time. If I remember correctly, a group of ex-Xara developers moved to Serif to write it. Affinity looks similar, I would be surprised if they aren't based on the same codebase.

I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser. But the uptake is a problem, no other browser maker wants to adopt a big chunk of code controlled by Google, tailored to run optimally in Chrome.

So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM on top of it. The fact that it's Javascript is just a detail, a legacy of the days when one vendor (Netscape) was able to push through a standard for running code in the browser.

In today's fragmented browser landscape I find it hard to believe a consensus could be reached again. Most of the major browser makers (Google, Microsoft, Apple) have their own platform agenda to push - in that context asm.js's compatibility with existing Javascript engines gives it the best chance of adoption.

But I agree, the hoops that had to be jumped through are a damned shame.

Great work!

I wish I'd seen this a month ago - I've been working on my own C++ port of three.js, but focusing on mobile and web targets via emscripten.

It's reassuring to see how similar the client API looks. And interesting to note differences in the porting approach. Three.js uses dynamic objects in a lot of places, which can be difficult to translate to static types in C++. On the other hand, there's a lot less wrangling of types to and from OpenGL compatible arrays which makes it easier to use in some ways.

See http://github.com/safetydank/resinlib for my port.

Ah yes, Native Client. I assume Android allows it since it runs V8.

Ios disallows dynamic code generation at runtime - what other environments could Go target with these restrictions?