Naive question: is there a reason why we cannot just compile programs to both native/bytecode and javascript and have browsers automatically fetch the version they support? If it turns out that native/bytecode universally runs (say) 20% faster and loads in half the time, the javascript target will eventually die a natural death of obsolescence without compatibility ever being sacrificed. If it turns out that the javascript target can keep up with the performance native/bytecode, then we can just stop compiling to anything but javascript, and nothing will be lost. The attitude that we should not even try to do better than compiling to javascript just seems odd.
Well, that seems to be what Google is doing with PNaCl and pepper.js. Pepper.js uses emscripten to compile PNaCl apps so they run in JS (specifically asm.js). In Chrome the PNaCl version can run, and everywhere else it runs in JS. That sounds like what you are proposing?
Those two sites have the same codebases built for both PNaCl and asm.js. Overall they run pretty well in both, so this doesn't seem to show a clear advantage to either JS or a non-JS bytecode. PNaCl starts more slowly, but then runs more quickly, but even those differences are not that big. And surely both PNaCl will get faster to start up, and JS get faster to run, because there is no reason they both cannot get pretty much to native speed in both startup and execution.
Note though that there are risks to this approach. No one enforces that everyone create dual builds of this nature, and there is no guarantee that the dual builds will be equivalent. So while this is interesting to do, it does open up a whole set of compatibility risks, which could fragment the web.
Except for the fact that you can not compile threaded programs to javascript I am pretty sure while you can to PNaCl and this is my problem with this talk of asm.js, until it supports threads I don't really consider it an acceptable solution.
Nope, it's a better idea to create a higher level thread-pool-based parallel-task-system which abstracts away the differences between pthreads and WebWorkers. I think that at least most game engines have such a system in place anyway, and can be relatively easily adopted. YMMV because it may be more overhead to get data in and out of WebWorkers since they don't have a shared address space (so in that regard they are more like processes).
We can do that - I mean, it's a chicken and egg problem; browsers don't support proper bytecode because there's not a particular mass of software that needs that support, and there won't be a mass of software until the support exists on most browsers.
Asm.js provides a 'fake egg' that can be hatched by the already existing JS support - but once there is enough software being built through, say, LLVM to asm.js, then it would make sense for a browser vendor to provide a feature "supply alternative bytecode built by the exact same compiler toolchain, and you'll get 50% better performance".
I don't care if it's just Google or Google + Mozilla + some bunch of other guys. At least with Dart I can see the difference and it took a couple of years to implement instead of a dozen of years. I hope Dart will get some traction so that other players will be innovating again instead of relying on legacy languages.
