Comment by hosay123 | Hacker News Reader

Comment by hosay123 | Hacker News Reader

Parent Full thread

>> You're so myopically focused on the ideology of tomorrow over providing a great user experience today.

> Through ActiveX Technologies, today's static Web pages come alive with a new generation of active content, including animation, 3-D virtual reality, video and other multimedia content. ActiveX Technologies embrace Internet standards and will be delivered on multiple platforms, giving users a rich, open framework for innovation while taking full advantage of their investments in applications, tools and source code. "ActiveX brings together the best of the Internet and the best of the PC," said Paul Maritz, group vice president of the platforms group at Microsoft. "Users want the richest, most compelling content delivered through the ubiquitous Internet."

— Microsoft press release, March 1996.

We've seen this all before, and it was as much of a land grab using similar "user experience" excuses then as it is now. And despite it all, everything from this press release is possible with open technologies today already. Now we come to address the performance issue, and platform proponents (let's drop the pretence – platform shills) continue to fiercely reject it, because providing a good user experience was never the original agenda.

I'm deeply reminded of the leaked internal DART e-mail ( https://gist.github.com/paulmillr/1208618 ) where as much ink was expended on marketshare as it was on technical issues.

This is a false comparison.

ActiveX was technologically flawed: it was specific to Microsoft Windows, and it was insecure.

NaCL is secure and portable, without sacrificing the user experience today.

Indirectly referring to me as a platform shill is unwarranted. The reason that I argue so strenuously for maximizing performance is simply that performance improves user experience.

> I'm deeply reminded of the leaked internal DART e-mail ( https://gist.github.com/paulmillr/1208618 ) where as much ink was expended on marketshare as it was on technical issues.

I've read the whole memo, and I don't understand what your complaint is at all. Google seems to be focused on actually improving the web as an application development target, and making it competitive with modern platforms.

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."

http://books.google.com/books?id=97W638tj_NsC&pg=PA38...

ActiveX was, at its very core, not portable.

Are you making an objective technical argument, or a solipsistic one?

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."

http://www.microsoft.com/en-us/news/press/1996/oct96/macpr.a...

So, yes, "non-portablest".

What exactly is the equivalence to (P)NaCL?

The fact that NaCL only works in Chromium, and will only ever work in Chromium.

Here's an implementation of NaCl that has nothing to do with Chromium: http://zerovm.org/

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.

Reply on news.ycombinator.com