I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc.
However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm compiled to javascript. Maybe that is the sweet spot for asm.js: You are still able to support Safari and IE though native javascript, but it's faster on Chrome and Firefox.
> It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc.
Bytecode doesn't mean smaller download or faster startup, or necessarily better performance. It might, but you need numbers to show that.
In practice, right now startup is faster on asm.js than PNaCl, and vice versa for execution speed, but in both cases the differences are not large. Compare for yourself:
"It would make much more sense if it were compiled to some kind of bytecode (like NaCl)."
asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that happens to have a serialization to a Javascript-compatible syntax.
Do not be fooled by the surface appearance and the name. Look at what it does. It is a bytecode, just one with a bizarre serialization. (And as a result of that serialization, the most literal interpretation of "bytecode" admittedly doesn't quite work, but it's a bytecode in every way except for a literal fixed-length code of bytes.)
asm.js code is just numbers and functions, no JS "objects". Passing a C++ object by reference resolves to passing a pointer just like in native code (a pointer in emscripten-generated code is actually an index into the typed-array representing the heap). A nice side-effect of this is that asm.js code doesn't trigger the garbage collector.
No, but it's not a great deal to write a parallel execution subsystem in C/C++ which abstracts the differences between pthreads and WebWorkers away. Using low-level pthreads primitives directly in high-level code is a bad idea anyway.
> I agree, an Unreal Engine compiled to javascript doesn't make sense.
That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms.
Well that has nothing to do with JS or asm.js, only how the game manages its assets. The Citadel demo needs to preload all data before it starts which is very easy to implement but is of course a suboptimal approach to asset loading, a proper game would only load what's really needed to start (4..5 MBytes max?), and from then on stream everything on demand in the background. It's about how much new data can be presented to the player per second, not how big the game data is overall. Asset sharing/reuse, data compression, procedural generation are all important topics for browser games in general, not just games running in asm.js.
Original Java bytecode was actually worse than compiling to some real language - all the value lifetime and other optimization information was lost, even conversion to native asm produced unoptimized code. Is NaCl any different? I imagine javascript that is jit-compiled could create a pretty good binary?
NaCl is just native machine code with some additional restrictions, AFAIK. It can make use of existing compilers and optimizers.
I agree that the binary is probably relatively efficient, but a) only if your code deals with 32bit floating point numbers, b) the binary (erm js file) is probably going to be bigger (hence increased download times) c) the compilation does not come for free.
However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm compiled to javascript. Maybe that is the sweet spot for asm.js: You are still able to support Safari and IE though native javascript, but it's faster on Chrome and Firefox.