By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems.
Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".
> By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems.
That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE.
Additionally, PNaCL can be retargeted at as-of-yet unknown architectures.
The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately.
This seems reasonable to me; default to portability, provide an option for best-case performance.
Totally different. In all of those cases, the developers have access to devices that run the hardware, and they have economic incentive to target all of those devices. Whereas with your suggestion, developers ship and test native builds for all of the CPUs on the market, plus one extra "portable" version for posterity, one that no immediate customers will ever use (because they'll be using the native versions for their architecture instead). I suspect developers wouldn't even ship the portable version (too much of a pain), browsers won't optimize it (because nobody will use it), and developers won't test it (because nobody will use it).
It's like saying that images are no problem for accessibility on the Web, because designers know to use alt text. Of course they know they should, but we all know what the reality is. A backup "portable" version of an app is like alt text in this way. Some developers would do the right thing; many won't, and the Web will be de facto locked in to x86 and ARM forever.
That's a bit ridiculously alarmist, isn't it? Heck, you could have lead with that, rather than waiting for me to reply -- you seem to already know what you wanted to say.
Won't developers have access to PNaCL runtimes? How is this so different than Apple developers having access to the other target hardware
It comes down to toolchains and the workflow they're optimized for. With PNaCL, the portable version is the primary target of the toolchain, from which one generates other native binaries. You can still generate native binaries separately, but ideally, PNaCL would lead.
If the tools lead naturally in the right direction, then developers do follow. If you're feeling really worried about it, define a distribution format that mandates a PNaCL entry.
Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".