> Our 3D rendering engine currently uses a Chrome-only technology called Native Client to power Earth Studio. However, we’re closely tracking the evolution of WebAssembly (especially threading). Stay tuned!
NaCl is already deprecated in favour of wasm but this thing still uses NaCl. This should just not have been released until it was ready.
Forgive the world for thinking this smells like IE and ActiveX from an infinitely scarier company with much more power than Microsoft ever had.
>However, we’re closely tracking the evolution of WebAssembly (especially threading). Stay tuned!
It seems reasonable to get this program out and running today and move it over to WebAssembly in the future. One of the alternatives would've been to deliver a native app to every platform, but Chromium is already a native app that runs on many platforms that you can compile yourself, and then you get a security sandbox for free. Seems a better to me, frankly, especially in a world where many "desktop" apps just ship with Chromium anyways.
It's like saying because an app using the Mac touch bar is Mac only is a terrible thing. It's not. It's how platforms work.
So, because I think Google shouldn't use a technology that they themselves marked as deprecated, leaving it only supported in their own browser using their own technology that only they implemented, it shouldn't exist in any way shape or form — despite the fact that wasm is already supported in Chrome and other web browsers?
Obviously, they should have just waited until they'd finished porting to wasm. The world would have survived without the NaCl version of a tool they never had before; bloods wouldn't run down the streets if we'd have had to wait a little bit longer for the only version of the tool that should have released.
> It's like saying because an app using the Mac touch bar is Mac only is a terrible thing
It's really not. The touch bar doesn't purport to be a standards-compliant technology available for every platform to access in an equitable way; apart from the fact it's only on Macs, nothing about it was ever advertised as being explicitly designed for cross-platform use.
The analogy to Chrome, a browser that is advertised as standards-compliant and even advancing standards, to the extent that it already includes wasm support, utterly falls apart.
> It's how platforms work
Chrome is not a platform, and I find myself shocked when anybody thinks so. It's as though the lessons of the past (IE, ActiveX, plugin lock-in) remain unlearnt; a new generation of people who don't know how good they've had it for so long.
Chrome is __not__ a platform; it is merely the window through which we consume the real platform: the open web.
When Google tries to push Chrome as a platform, we need to all push back. We've had one browser as a platform, and it was not good, it was unhealthy for developers as well as advancements in web technologies, and I and anybody who still has to support IE5 and IE6 do not want to see that again.
- Most of Chrome is open source. This would surely run in Chromium.
- It's cross platform.
- It supports web standards. WebAssembly for example.
Are things really full circle? I mean the situation could be better but the amount of things that work seamlessly between multiple browsers has never been larger. Very advanced web apps are now assumed to work across at least Chrome and Firefox, and probably Edge, with only a handful of exceptions, when in the past most things beyond basic pages simply didn't or required Java or Flash binary blobs. I don't think anyone in the browser space is intentionally making things worse, things have mostly just gotten better. NaCl may be a notable exception, but prior to WebAssembly it seemed like a good idea, and frankly the technology itself still seems pretty useful. NaCl also still has a lot of things WebAssembly doesn't yet.
I see no bad intentions. Just people making the best out of a rapidly moving platform. Someone else in this thread mentioned a WebAssembly port is coming eventually, no reason to doubt it given NaCl is deprecated.
Also, P.S.: The NaCl situation is unideal, but frankly I'd rather boot up Chrome to run something than, for example, installing and using an NPAPI plugin that has full privileges and code I can't inspect. (I am, actually, a Firefox user at home.)
(Disclaimer: Google employee, but nowhere near the Chrome team.)
It doesn't take bad intentions to end up destroying an open ecosystem, just a lack of effort to create standard solutions while being the majority market share gorilla.
Microsoft employees likely thought they were doing good by adding non-standard features to IE as well given that "standards couldn't keep up" for them either.
NaCl solved real problems people had. NaCl allowed secure native code inside Chrome extensions and webapps, before Asm.js and before WebAssembly. It helped with removing insecure NPAPI usages (in the past, a Chrome extension could contain an NPAPI plugin![1])
Nowadays, NaCl is a lot less necessary. Many apps can run just fine in Asm.js and WebAssembly. This is definitely due to cross collaboration from the browser vendors, improving JavaScript performance and solidifying the idea of a cross-platform, safe, portable binary format that could be implemented by all browser vendors. That seems like a fantastic outcome to me, as an end user.
Other browsers could've implemented NaCl if they pleased. I recall Mozilla pushing for pure JS and later asm.js instead. In the end, the solution we really ended up with is a lot like a mix of NaCl and Asm.js. You could argue we would've gotten here without NaCl, but I think the end user is certainly better off without things like NPAPI plugins.
That's neither here nor there. For the purposes of this discussion, Chrome and Chromium are the same browser, and the design and development of the Chromium platform is very much dominated by Google, sufficient to call them the owners of the platform.