4 ms·

Looks nice, but it's yet another Chrome-only project.

by davissorenson 8y ago

tjpnz 8y ago
I'm not sure why you're being downvoted but this is a pretty serious shortcoming.
- richev 8y ago
  True, but their FAQ addresses this: > 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!
  - burgerboy 8y ago
    People here just have to hate in everything Google does eh?
    - tjpnz 8y ago
      Just dead technologies that haven't gained industry wide adoption.
    - zapzupnz 8y ago
      No, people hate that Google is observably becoming the next 1990s era Microsoft. 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.
      - SquareWheel 8y ago
        It's nothing like ActiveX. Native Client was an open and modern recreation of a dying API (NPAPI). It didn't catch on, so it's being deprecated.
        zapzupnz 8y ago
        Sure, but realistically, that makes no difference when (A) only one browser ever implemented it, and (B) its continued use by its originator company _despite_ deprecation last year (after its team was destaffed two years ago) still stinks of an attempt at lock-in, open source or not.
        jchw 8y ago
        There are still things you can't do with the web platform alone. WebAssembly is still in its infancy, and not everything is really figured out yet. In this case, it looks like they're held back by the lack of proper threading: >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.
      - burgerboy 8y ago
        What a nonsense statement. Would you rather this project just not exist at all rather then use a technology specific to chrome? 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.
        zapzupnz 8y ago
        You've made a bit of a logical leap in the way you've interpreted my post. 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.
deleted 8y ago
[deleted]
black-tea 8y ago
We've come full circle. If you work for Google I hope you're proud of yourself.
- jchw 8y ago
  There are some differences between Chrome and previous browser incumbents: - 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.)
  - hueving 8y ago
    >I see no bad intentions. 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.
    - jchw 8y ago
      Sorry, I just don't see that pattern repeating here. Nothing like JScript or MSJVM, no ActiveX or BHO or COM. 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. [1] https://developer.chrome.com/extensions/npapi https://developer.chrome.com/extensions/npapi

Looks nice, but it's yet another Chrome-only project.

tjpnz 8y ago

I'm not sure why you're being downvoted but this is a pretty serious shortcoming.

richev 8y ago
True, but their FAQ addresses this: > 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!
- burgerboy 8y ago
  People here just have to hate in everything Google does eh?
  - tjpnz 8y ago
    Just dead technologies that haven't gained industry wide adoption.
  - zapzupnz 8y ago
    No, people hate that Google is observably becoming the next 1990s era Microsoft. 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.
    - SquareWheel 8y ago
      It's nothing like ActiveX. Native Client was an open and modern recreation of a dying API (NPAPI). It didn't catch on, so it's being deprecated.
      - zapzupnz 8y ago
        Sure, but realistically, that makes no difference when (A) only one browser ever implemented it, and (B) its continued use by its originator company _despite_ deprecation last year (after its team was destaffed two years ago) still stinks of an attempt at lock-in, open source or not.
        jchw 8y ago
        There are still things you can't do with the web platform alone. WebAssembly is still in its infancy, and not everything is really figured out yet. In this case, it looks like they're held back by the lack of proper threading: >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.
    - burgerboy 8y ago
      What a nonsense statement. Would you rather this project just not exist at all rather then use a technology specific to chrome? 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.
      - zapzupnz 8y ago
        You've made a bit of a logical leap in the way you've interpreted my post. 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.

deleted 8y ago

[deleted]

black-tea 8y ago

We've come full circle. If you work for Google I hope you're proud of yourself.

jchw 8y ago
There are some differences between Chrome and previous browser incumbents: - 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.)
- hueving 8y ago
  >I see no bad intentions. 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.
  - jchw 8y ago
    Sorry, I just don't see that pattern repeating here. Nothing like JScript or MSJVM, no ActiveX or BHO or COM. 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. [1] https://developer.chrome.com/extensions/npapi https://developer.chrome.com/extensions/npapi