4 ms·

Am I in the minority that I think it is a positive development, when Google is discarding proprietary ideas in favour of open developments? Not perfect but the

• angry_octet 9y ago
  If you care about security, performance or having portable offline applications its a sad day. Google just pressed reset and erased your work. The way Google has abrubtly sent PNaCL to the knackery, rather than a gradual transition is just ugly. By removing the PNaCL functionality completely from builds they have broken faith with the development community. They didn't even commit to allowing PNaCL to run in deprecated mode via a feature flag or something. In hindsight, I can see that Google had shifted their effort away from PNaCL several years ago. But to kill it they way they have it just brutal. I would agree that for general web development this seems a way out of the javascript purgatory. But there is a long way to go before it can match what PNaCL did. And I find it bizarre that they created a 32 bit implementation; I know they had reasons but they seem shortsighted.
  • roca 9y ago
    AFAIK the main missing feature in WebAssembly that PNaCl had is shared-memory multithreading and that is implemented and waiting on spec finalization to ship. What else is there?
    • angry_octet 9y ago
      Security (code signing, timing determinism, large API attack surface, complex javascript interpreter/jit), performance (obvious deficit between an IR bytecode and jit, static analysis vs runtime checks), concurrency (how many cores on your new 2017 box? By 2027?), features (the p/nacl api let you do more, like access devices for video/graphics/audio; instead it will be an implementation specific thing; networking - open sockets to unrelated hosts; same origin is a straight jacket), elegance (wasm/asm.js/js is just hack, hack, hack; thanks Mozilla), maturity (just bugs need time to be sorted).
      • roca 9y ago
        I don't think PNaCl guarantees timing determinism. Not sure what you mean by "code signing" in this context. The API attack surface is a non-issue; it's already accessible by any page that serves a PNaCl object. There's a small performance deficit but it's getting smaller. AOT compilation and caching of compilation results is possible; asm.js did it. I already mentioned shared-memory parallelism (it's just about done); did you read what I wrote? Standard cross-browser Web APIs give you access to those devices already. Same-origin is a strait-jacket --- a necessary one. "Break the Web's security model" isn't a desirable feature. "Elegance" is just a point of view. From another point of view, "duplicate everything in the Web platform" is not elegant. As for maturity and bugs --- having multiple interoperating implementations and real specifications is a good way to drive competition on quality ... and to distinguish "this is a bug, fix it" from "hello de-facto standard!"
      • roca 9y ago
        Also "static analysis vs runtime checks" is a red herring --- PNaCl and Wasm are basically identical in those respects.