By your own words Native Client is technically flawed: it's specific to x86 and ARM (and whatever other vaporware platforms they promise "next week" – PNaCl has been due for years already), and removing the VM, it's also insecure. So basically Native Client is ActiveX inside a VM.
How exactly is that by my own words? You also seem to be confusing quite a few technical topics.
First, you're equating ARM and x86 with Microsoft Windows. Those are all "platforms", but they exist at very different levels of the technology stack, and the impact of relying on them is quite different.
Samsung and Apple can both ship compatible ARM devices. Only Microsoft could ship an ActiveX runtime.
Second, you're throwing out "security" as a red herring without actually explaining what is insecure. Exactly what are you talking about?
Lastly, if PNaCL is not viable, then NaCL is not viable. Thus, Google is holding off on NaCL until PNaCL is viable. In the meantime, I'm targeting mobile and desktop applications -- today -- which is entirely consistent with my earlier stated position.
"ActiveX is definitely going cross-platform," Willis says. "To be a viable technology for the Internet, we need to be able to support more platforms than Microsoft Windows. You cannot predict what kind of platforms will be on the other end."
Which part of ActiveX wasn't portable? COM is definitely portable. Shipping signed executables that implement COM interfaces is as "portable" as NaCL is, so no problems there.
If your complaint is that ActiveX controls used the Win32 API, then you're missing the point. A Mac or Linux ActiveX control would use OS-native APIs, but still use COM and be an ActiveX control.
Furthermore, if you had even looked up the Wikipedia page for ActiveX, you'd see that:
"On 17 October 1996, Microsoft announced availability of the beta release of the Microsoft® ActiveX Software Development Kit (SDK) for the Macintosh."
Yep, so non-portable that they released a Mac SDK back when Macs were PowerPC. Super non-portable. The non-portablest.
ActiveX was portable the way that the SYSV/SVR4 binaries were portable -- almost entirely in theory.
"It was introduced in 1996 and is commonly used in its Windows operating system. In principle it is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator. Most also require the client to be running on Intel x86 hardware, because they contain compiled code."
What rational comparison do you have between NaCL's constrained syscall interface + Pepper, and ActiveX?
> Yep, so non-portable that they released a Mac SDK back when Macs were PowerPC. Super non-portable. The non-portablest.
Which produced binaries that couldn't run on any other PPC OS other than Mac OS, and provided a runtime that couldn't run the ActiveX controls being deployed for Windows clients, even if it was somehow magically possible to run x86 code.
It was explicitly advertised as being non-portable, as a feature: "Developers can create ActiveX Controls for the Mac that integrate with other components and leverage the full functionality of the Mac operating system, taking advantage of features such as Apple QuickTime."
Not due to technical constraints, unlike ActiveX. It's a self-fulfilling prophesy -- Mozilla's refusal to adopt NaCL will, indeed, stall the adoption of NaCL.
Things might get more interesting if NaCL provides a higher performance deployment target for Chrome users than asm.js does. Then you can just cross-compile for both.
