22 ms·

Goodbye PNaCl, Hello WebAssembly

655 points by Ajedi32 9y ago

camus2 9y ago
Why bother investing time and resources in Google techs when they keep on discontinuing them? they don't care about enterprise software, if they did, they wouldn't act like that. AMP? lol, think again before implementing this, it will not be worth the effort since Chrome will eventually drop that too. A good reminder not to invest in any Google specific technology. > We recognize that technology migrations can be challenging. You recognize you wasted a lot of people's time.
- josteink 9y ago
  > Why bother investing time and resources in Google techs when they keep on discontinuing them? I really think this is a good question, despite the form of your post (hence the downvotes). To anyone who decided "lets use NaCl or PNaCl", I have a genuine question: Are you honestly surprised to see this tech too go obsoleted? > We recognize that technology migrations can be challenging. ... You recognize you wasted a lot of people's time. They are taking this from Apple's book: Don't leave any compatible stuff behind. Leave the maintenance-cost to others.
lwlml 9y ago
At this point, I really loathe adopting any facet of web-browser technology: there are too many broken APIs in too many browsers to maintain on both sides of the system: the browser developers have an insane number of combinations of features that need to be useful, secured and made reliable and developers for browsers are always at some weird disadvantage where they can spend months or years maintaining an application for the browser to find it rots out from underneath them. Should you even be slightly successful in the use of an API, you always have to worry about deprecation when someone is no longer interested in doing the maintenance any more. I am sure there were more than a few game developers that are are livid today about this announcement. These things will go in cycles and I expect there will be an native-application cycle coming soon from browser-api-fatigue.
- skybrian 9y ago
  If you used this at all, it was in a Chrome-only app; this is pretty far from mainstream. A good rule of thumb seems to be to use what everyone else uses, and make sure you're always ready to ship another version. People expecting compiled apps to survive unchanged for years are out of luck.
  - rch 9y ago
    It used to be worse: keeping an old Compaq or DOS box around just so one random business app would keep working.
    - Turing_Machine 9y ago
      "Used to be"? There are still places that do that. :-) It's especially prevalent in factory automation and process control. We're lucky in that many of those systems are actually so old that no one ever thought of connecting them to the Internet.
  - tostitos1979 9y ago
    Not true. NaCl is pretty big in some areas of Consumer Electronics.
    - jonknee 9y ago
      Can you provide some examples?
      - tostitos1979 9y ago
        E.g. http://developer.samsung.com/tv/develop/extension-libraries/nacl/getting-started http://developer.samsung.com/tv/develop/extension-libraries/...
        BHSPitMonkey 9y ago
        That's a controlled environment, though; Samsung almost certainly creates a customized build of Chromium for its TVs and can simply keep NaCl enabled if it wishes. They aren't beholden to the same policies that apply to the consumer Chrome releases.
gklitt 9y ago
It seems like the browser vendors are doing a good job coordinating to provide a robust ecosystem around Web Assembly. Clearly much healthier for the future of the web than fragmented browser-specific solutions.
nimrody 9y ago
Then perhaps Andreas Gal's "Chrome Won" assertion wasn't entirely accurate. After all WebAssembly is something that was derived from Mozilla's asm.js.
- pvg 9y ago
  The assertion was about market share so the fact that Chrome might have adopted some mozilla-derived technology doesn't affect its accuracy.
  - dtech 9y ago
    Yep, consider x86_64. That's an AMD instruction set but it's very safe to say that Intel at the moment has won the desktop CPU market.
    - deleted 9y ago
      [deleted]
coolmitch 9y ago
As a web developer working primarily in JS, what should I be learning now to stay relevant/up-to-date once WebAssembly is more common? Are we going to see more web stuff built with c++, like the dsp example in this blog post?
- camus2 9y ago
  WebAssembly is a medium for ASM.js apps, and ASM.js apps are mainly C and C++ . You have to learn C and C++ period.
  - dasmoth 9y ago
    Right now, that's probably the best way to go if you're keen to build non-trivial wasm stuff, but I don't think it's a foregone conclusion that it'll stay that way. There's a Rust implementation now, for instance. And some talk of better support for garbage collected languages.
  - dragonwriter 9y ago
    > You have to learn C and C++ period. You can program in wasm's text format (the actual assembly language) directly, if you want, and you can program in anything that compiles to wasm. C/C++ have the most developed toolchains for higher (than wasm itself) level languages, for now, but that should open up.
- butabah 9y ago
  To your second question, WebAssembly shouldn't be affecting your day-to-day standard frontend development, unless you're developing very performant applications like games, simulations, etc. For resources, MDN has a great introduction. Pretty up-to-date too. [1]. [1] https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wa...
- sjrd 9y ago
  I don't think WebAssembly will become more common than JavaScript anytime soon. And even when it will be, it means the tooling will have become so good that you won't even have to think about WebAssembly. That will be left to the people who create compilers to WebAssembly. Hopefully you'll just use whatever language your org/team/etc. uses, and have it compiled to JS or WebAssembly as is most appropriate for said language. To answer your other question, I most certainly hope we won't see "more Web stuff" built with C++. C++ is a terrible language for that. It's a very good language to do stuff that needs predictable high performance such as games. And games is a good market for C++ in the browser through WebAssembly. But other than that I hope other, more high level languages will pick up.
withjive 9y ago
Looks like Mozilla won this fight. When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web Assembly being the general way forward.
- vvanders 9y ago
  Yup, when you consider that WASM can be polyfilled with Asm.js it's pretty obvious where things were headed.
  - jfbastien 9y ago
    Except with all browser vendors being involved with WebAssembly, efficient polyfill-ability hasn't been a goal for a while.
    - cromwellian 9y ago
      WASM has 64-bit ints, did asm.js support those? How can you polyfill that without a real slowdown.
      - recursive 9y ago
        A property with getter and setter backed by singleton typed array instance?
        cromwellian 9y ago
        "without a real slowdown" Any operation, like 64-bit adds/muls/divs/etc would have to call emulation functions. It'll be orders of magnitude slower.
  - wyldfire 9y ago
    What does that mean: "polyfilled with asm.js"?
    - 9y ago
jepler 9y ago
OK, so where do I get a mosh client programmed in WebAssembly? Without it, my chromebooks might as well be bricks.
- dragonwriter 9y ago
  By the time Google disables PNaCl on Chrome Apps, this kind of thing won't be an issue. There is a reason why the announced 2018 deactivation excluded Chrome Apps and Extensions.
  - sp332 9y ago
    I haven't seen any real activity from browser makers to add raw UDP APIs.
    - dragonwriter 9y ago
      > I haven't seen any real activity from browser makers to add raw UDP APIs. Well, for the Chrome Apps use case for Chrome OS, chrome.sockets.udp seems to be available, and wasm can call out to JS APIs. What other browser vendors do isn't really relevant for Chrome Apps.
- sciurus 9y ago
  Google is adding support for Android apps to Chrome OS, so presumably you'd get an app like JuiceSSH from the Play store. https://blog.google/products/chromebooks/the-google-play-store-coming-to/ https://blog.google/products/chromebooks/the-google-play-sto...
eeZi 9y ago
This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps I use all the time that would require a native app otherwise: - Signal Desktop - TeamViewer - Postman - SSH client - Cleanflight drone configuration tool It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure. Now everyone is moving to Electron and instead of one Chrome instance, I'm now running five which use more than one GB of RAM each. Much less secure, too, since each has its own auto-updater or repository and instead of being sandboxed by Chrome's sandbox, they're all running with full permissions. It also means I cannot longer use Signal Desktop on my work device since installing native apps is forbidden for good reasons, while Chrome Apps are okay. It also hurts Chrome OS users since Chrome Apps are being abandoned in favor of Electron. It also makes it less useful for developers to create Chrome Apps since the market is much smaller. Since Chrome Apps continue to be available on Chrome OS, I'm considering separating that functionality into a stand-alone runtime or making a custom build for Linux. Anyone wants to help with that?
- xyzzy_plugh 9y ago
  Your comment scared me, but TFA doesn't say that: > We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. Where do you see that chrome apps are being discontinued? Otherwise this is FUD.
  - TimothyFitz 9y ago
    EOL for Chrome Apps outside of Chrome OS was announced in August 2016 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html?m=1 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
    - datguacdoh 9y ago
      But OP is specifically calling out how this hurts Chrome OS, but it doesn't seem to affect that platform, from what I can tell.
Crontab 9y ago
Is WebAssembley going to turn into yet another web technology that can be used by websites in order to track us or to annoy us with advertising? I'm asking because every time something new is introduced, it feels like it ends up being used to abuse users (Javascript, XSS, Cookies, HTML5 Video).
- AsyncAwait 9y ago
  Every piece of technology can be abused, that doesn't mean the technology itself is bad and shouldn't be adopted.
  - nol13 9y ago
    Will WASM trackers/ads be harder to block than ECMA Script ones?
    - yorwba 9y ago
      ECMA Script trackers/ads are blobs of code that can sometimes be identified based on the requests they make, WASM trackers/ads are blobs of code that can sometimes be identified based on the requests they make. The only real difference is that the WASM variant will probably run faster than obfuscated ECMA Script.
      - _pmf_ 9y ago
        > The only real difference is that the WASM variant will probably run faster than obfuscated ECMA Script. ... which will lead to more ads being served, evening out any advantage.
- marcosdumay 9y ago
  It doesn't do anything that Javascript didn't already do. By the way, why do you think HTML5 is a problem?
  - duskwuff 9y ago
_wmd 9y ago
The most material result of this is that Chromebooks won't have a working SSH client starting sometime next year, because WebAssembly can't do real sockets without an external proxy.
- dragonwriter 9y ago
  No, FTFA: “We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions.” Chrome Apps (and extensions) using PNaCl will continue to work.
  - cbhl 9y ago
    Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020. Disclaimer: My opinion, not that of my employer.
    - dragonwriter 9y ago
      > Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020. Sure, it is deprecated and will be deactivated eventually (but maybe not soon; consider WebSQL). Google's got every incentive to make sure that WebAssembly (plus the APIs exposed in ChromeOS) provides a complete replacement for PNaCl and apps have had time to transition before doing that.
      - i336_ 9y ago
        WebSQL is so sad. https://stackoverflow.com/questions/42288596/websql-has-increasing-browser-support-whats-its-future https://stackoverflow.com/questions/42288596/websql-has-incr...
- 9y ago
xoroshiro 9y ago
I'm not familiar with what goes in a browser, but for some reason, browsers seem to eat up a lot of resources. While I am happy that it looks like this will (more or less) be standardized across browsers, I still hope for the day where running a more minimal browser (text, image, maybe videos) will become viable. Of course, I'm pessimistic on this, seeing as so many sites are probably not functional without javascript and other related technologies, but maybe some web developers care about choice. Who knows.
- Ajedi32 9y ago
  Well, there's AMP. Most people on HN seem to really hate that solution though.
- IamCarbonMan 9y ago
  I do this, or at least, I'm trying my hardest to. I use terminal interfaces to my usual sites like Reddit, Gmail, GitHub, Google, etc. A mouse button or keystroke opens links using a little script I've written which basically opens media files in feh/mpv/whatever, html sites using [Mercury](https://mercury.postlight.com/web-parser/ https://mercury.postlight.com/web-parser/) and links, and if I really need to open the page in Chrome for some reason, the open script will begin nagging me to find a terminal client for that service if I use it very often.
jhpriestley 9y ago
From the asm.js FAQ: Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript? A. The principal benefit of asm.js over whole new technologies like NaCl and PNaCl is that it works today asm.js however wasn't good enough to actually be useful, as evidenced by the lack of adoption and the move to wasm. So now we have wasm which is not backward compatible. We would be further along now if Mozilla/Eich would have gotten behind Google's more mature effort, this really was stubbornness IMO.
- Analemma_ 9y ago
  "Stubbornness" in refusing to let Google unilaterally decree web technologies and standards is stubbornness I support fully.
- bobajeff 9y ago
  Actually, the AOT optimization path for asm.js has been supported by Internet Explorer/Edge for quite some time. Chrome also supports AOT asm.js path now through their wasm implementation[1]. Before that Chrome and Safari did optimizations that just happened to make asm.js faster ;) It's likely that if WebAssembly didn't happen everyone would've implemented AOT optimizations for asm.js and all the new features (shared memory threads, simd, 64bit int etc.) would be targeting that instead. [1] http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-december-edition/ http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-dec...
- roca 9y ago
  PNaCl had two big problems Google never attempted to solve: * No spec, just import some particular version of LLVM and it does what it does * Dependence on Pepper for its platform API --- just a big pile of Chromium code that does what it does and duplicates all the standard Web APIs
  - jhpriestley 9y ago
    I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't support it. Now they're backtracking and building a non-js asm system too. Do you think wasm apps will always use slow JavaScript ffi to call opengl say? We'll get a new pepper in like another decade.
seanwilson 9y ago
I'm so confused why Google deprecated Chrome Apps. You'd think they'd take advantage of the abundance of Electron apps by extending the capabilities of Chrome Apps to grow their Chrome ecosystem and attract new developers.
zurn 9y ago
Say hello to memory-unsafe languages and resulting vulnerabilities in web apps?
- roca 9y ago
  To some extent yes, but not nearly as bad. One feature Wasm has (shared with asm.js, but NOT PNaCl) is that the stack of return addresses lives outside addressable memory, and therefore can't be corrupted by an arbitrary-write primitive, so no ROP attacks. Likewise Wasm memory is entirely non-executable so you can't return or jump to exploit code. Function pointers are quite restricted; you can only make an indirect call to a function that's explicitly listed as indirectly-callable. Wasm applications can have type confusion bugs, use-after-free bugs, and array overflow bugs, etc, but this is inevitable for any realistic C/C++ compilation target.
willvarfar 9y ago
This is a sad day. NaCL was excellent tech, and its a shame it didn't get incorporated into LLVM proper, and that it didn't take off. We should be using NaCL/pNaCL for all apps everywhere, and for components within apps... etc. ZeroVM was a desktop/server sandboxing environment that just didn't get any attention and mindshare. Shame! I want a ZeroVM-like system that makes all of the Debian user-space available on any other OS, each app in a little sandbox... It ought just be another compiler target and automated. Oh to what could have been! :(
- krzyk 9y ago
  How is it better than WebAssembly?
  - smitherfield 9y ago
    It executes (sandboxed) native code directly, instead of requiring JIT compilation to native.
    - Houshalter 9y ago
      But that wouldn't be portable to other architectures though. Webasm is supposed to run on anything a modern browser can run on. I think it would also be much harder to guarantee that's secure.
    - traverseda 9y ago
      Have you seen the "the birth and death of javascript"? More interestingly it could vastly reduce the cost of interprocess communication to the point where the idea of a process starts to look a bit weird. Want to query a database? Upload a function you wrote yourself for complicated queries like GIS, or let the SQL parser generate the raw wasm on your behalf. Want to authenticate your users, but don't want to deal with all the different permiations on hardare tokens, ssh keys, etc? Just let them upload a wasm function.
      - willvarfar 9y ago
lawthemi 9y ago
It's sad. PNACL is more efficient. Go to lichess.org/analysis, make a few moves, turn on the engine analysis. With firefox and WASM, my machine compute 300 knode/s. With chrome and PNACL, my machine compute 2000 knode/s. That's a big step backward.
- gok 9y ago
  I see nothing inherently more efficient about PNaCl. Both it and WASM expose an architecture-agnostic 32-bit virtual instruction set, then rely on the user agent to apply good optimization. WASM’s performance will improve. Non-portable NaCl did have the advantage that it could specifically target and optimize for one CPU architecture, and it had the beginnings of 64-bit address space support. These were nice, but not widely used. And we both could conceivably make it into WASM in the future.
ap46 9y ago
Can someone get opencv running on it?
- Houshalter 9y ago
  Webasm doesn't currently have access to SIMD instructions or the gpu. So that kind of intensive matrix math stuff might not benefit too much from webasm.
tehabe 9y ago
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 direction looks good so far.
- 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).
r0anne 9y ago
>We will remove support for PNaCl in the first quarter of 2018 While the new Google Earth with PNaCl was just introduced, a large engineering cost for a semester-lived technology! Too bad
- johncolanduoni 9y ago
  The code base is almost certainly in C or C++. The parts that use the APIs will need to be changed, but it won't need anywhere close to a full rewrite.
- nnethercote 9y ago
  Plenty of people were left scratching their heads when the new Google Earth was introduced, precisely because it was clear that PNaCl's days were numbered. I think the likely explanation is that Google is a large company with numerous departments and those departments don't always pull in the same direction. I imagine some people within Google weren't happy with the Google Earth announcement.
TekMol 9y ago
Can somebody ELI 5 what is the benefit of WebAssembly vs Asm.js?
- johncolanduoni 9y ago
  It's a format designed to be a target for static languages that do manual memory management (like C/C++) instead of JavaScript that some engines know how to recognize and optimize. The binaries are smaller and much faster to parse and the sandbox model results in much less overhead. For a concrete example, at least two JavaScript engines (those of Chrome and Firefox) need to emit almost no range checks on regular memory accesses with WebAssembly on 64-bit computers. (For those interested in going past ELI5, they do this by allocating a large chunk of virtual address space, such that any out of range pointers will land somewhere in that space (WebAssembly currently only has 32-bit pointers). Some of the space is filled with memory, and the rest causes a controlled signal/exception so the engine can safely terminate the instance.)
  - TekMol 9y ago
    target for static languages that do manual memory management So I will have to do all the garbage collection myself? Isn't that a huge burdon on the programmer? And will this lead to lots of apps with memory leaks that needlessly eat up my resources?
    - AgentME 9y ago
      That's already the case if you want to do high-performance stuff with C/C++. WebAssembly is primarily about getting that into the web.
JacobiX 9y ago
We used PNaCl to port some games to a Smart TV. It was a painful experience. Debugging chrome from a custom gdb, breaking changes from release to release, and some very subtle bugs in pepper API. But the final results were surprisingly not so awful.

655 points by Ajedi32 9y ago

Why bother investing time and resources in Google techs when they keep on discontinuing them? they don't care about enterprise software, if they did, they wouldn't act like that. AMP? lol, think again before implementing this, it will not be worth the effort since Chrome will eventually drop that too. A good reminder not to invest in any Google specific technology. > We recognize that technology migrations can be challenging. You recognize you wasted a lot of people's time.

josteink 9y ago
> Why bother investing time and resources in Google techs when they keep on discontinuing them? I really think this is a good question, despite the form of your post (hence the downvotes). To anyone who decided "lets use NaCl or PNaCl", I have a genuine question: Are you honestly surprised to see this tech too go obsoleted? > We recognize that technology migrations can be challenging. ... You recognize you wasted a lot of people's time. They are taking this from Apple's book: Don't leave any compatible stuff behind. Leave the maintenance-cost to others.

lwlml 9y ago

At this point, I really loathe adopting any facet of web-browser technology: there are too many broken APIs in too many browsers to maintain on both sides of the system: the browser developers have an insane number of combinations of features that need to be useful, secured and made reliable and developers for browsers are always at some weird disadvantage where they can spend months or years maintaining an application for the browser to find it rots out from underneath them. Should you even be slightly successful in the use of an API, you always have to worry about deprecation when someone is no longer interested in doing the maintenance any more. I am sure there were more than a few game developers that are are livid today about this announcement. These things will go in cycles and I expect there will be an native-application cycle coming soon from browser-api-fatigue.

skybrian 9y ago
If you used this at all, it was in a Chrome-only app; this is pretty far from mainstream. A good rule of thumb seems to be to use what everyone else uses, and make sure you're always ready to ship another version. People expecting compiled apps to survive unchanged for years are out of luck.
- rch 9y ago
  It used to be worse: keeping an old Compaq or DOS box around just so one random business app would keep working.
  - Turing_Machine 9y ago
    "Used to be"? There are still places that do that. :-) It's especially prevalent in factory automation and process control. We're lucky in that many of those systems are actually so old that no one ever thought of connecting them to the Internet.
- tostitos1979 9y ago
  Not true. NaCl is pretty big in some areas of Consumer Electronics.
  - jonknee 9y ago
    Can you provide some examples?
    - tostitos1979 9y ago
      E.g. http://developer.samsung.com/tv/develop/extension-libraries/nacl/getting-started http://developer.samsung.com/tv/develop/extension-libraries/...
      - BHSPitMonkey 9y ago
        That's a controlled environment, though; Samsung almost certainly creates a customized build of Chromium for its TVs and can simply keep NaCl enabled if it wishes. They aren't beholden to the same policies that apply to the consumer Chrome releases.

gklitt 9y ago

It seems like the browser vendors are doing a good job coordinating to provide a robust ecosystem around Web Assembly. Clearly much healthier for the future of the web than fragmented browser-specific solutions.

nimrody 9y ago

Then perhaps Andreas Gal's "Chrome Won" assertion wasn't entirely accurate. After all WebAssembly is something that was derived from Mozilla's asm.js.

pvg 9y ago
The assertion was about market share so the fact that Chrome might have adopted some mozilla-derived technology doesn't affect its accuracy.
- dtech 9y ago
  Yep, consider x86_64. That's an AMD instruction set but it's very safe to say that Intel at the moment has won the desktop CPU market.
  - deleted 9y ago
    [deleted]

coolmitch 9y ago

As a web developer working primarily in JS, what should I be learning now to stay relevant/up-to-date once WebAssembly is more common? Are we going to see more web stuff built with c++, like the dsp example in this blog post?

camus2 9y ago
WebAssembly is a medium for ASM.js apps, and ASM.js apps are mainly C and C++ . You have to learn C and C++ period.
- dasmoth 9y ago
  Right now, that's probably the best way to go if you're keen to build non-trivial wasm stuff, but I don't think it's a foregone conclusion that it'll stay that way. There's a Rust implementation now, for instance. And some talk of better support for garbage collected languages.
- dragonwriter 9y ago
  > You have to learn C and C++ period. You can program in wasm's text format (the actual assembly language) directly, if you want, and you can program in anything that compiles to wasm. C/C++ have the most developed toolchains for higher (than wasm itself) level languages, for now, but that should open up.
butabah 9y ago
To your second question, WebAssembly shouldn't be affecting your day-to-day standard frontend development, unless you're developing very performant applications like games, simulations, etc. For resources, MDN has a great introduction. Pretty up-to-date too. [1]. [1] https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wa...
sjrd 9y ago
I don't think WebAssembly will become more common than JavaScript anytime soon. And even when it will be, it means the tooling will have become so good that you won't even have to think about WebAssembly. That will be left to the people who create compilers to WebAssembly. Hopefully you'll just use whatever language your org/team/etc. uses, and have it compiled to JS or WebAssembly as is most appropriate for said language. To answer your other question, I most certainly hope we won't see "more Web stuff" built with C++. C++ is a terrible language for that. It's a very good language to do stuff that needs predictable high performance such as games. And games is a good market for C++ in the browser through WebAssembly. But other than that I hope other, more high level languages will pick up.

withjive 9y ago

Looks like Mozilla won this fight. When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web Assembly being the general way forward.

vvanders 9y ago
Yup, when you consider that WASM can be polyfilled with Asm.js it's pretty obvious where things were headed.
- jfbastien 9y ago
  Except with all browser vendors being involved with WebAssembly, efficient polyfill-ability hasn't been a goal for a while.
  - cromwellian 9y ago
    WASM has 64-bit ints, did asm.js support those? How can you polyfill that without a real slowdown.
    - recursive 9y ago
      A property with getter and setter backed by singleton typed array instance?
      - cromwellian 9y ago
        "without a real slowdown" Any operation, like 64-bit adds/muls/divs/etc would have to call emulation functions. It'll be orders of magnitude slower.
- wyldfire 9y ago
  What does that mean: "polyfilled with asm.js"?
  - 9y ago

jepler 9y ago

OK, so where do I get a mosh client programmed in WebAssembly? Without it, my chromebooks might as well be bricks.

dragonwriter 9y ago
By the time Google disables PNaCl on Chrome Apps, this kind of thing won't be an issue. There is a reason why the announced 2018 deactivation excluded Chrome Apps and Extensions.
- sp332 9y ago
  I haven't seen any real activity from browser makers to add raw UDP APIs.
  - dragonwriter 9y ago
    > I haven't seen any real activity from browser makers to add raw UDP APIs. Well, for the Chrome Apps use case for Chrome OS, chrome.sockets.udp seems to be available, and wasm can call out to JS APIs. What other browser vendors do isn't really relevant for Chrome Apps.
sciurus 9y ago
Google is adding support for Android apps to Chrome OS, so presumably you'd get an app like JuiceSSH from the Play store. https://blog.google/products/chromebooks/the-google-play-store-coming-to/ https://blog.google/products/chromebooks/the-google-play-sto...

eeZi 9y ago

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps I use all the time that would require a native app otherwise: - Signal Desktop - TeamViewer - Postman - SSH client - Cleanflight drone configuration tool It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure. Now everyone is moving to Electron and instead of one Chrome instance, I'm now running five which use more than one GB of RAM each. Much less secure, too, since each has its own auto-updater or repository and instead of being sandboxed by Chrome's sandbox, they're all running with full permissions. It also means I cannot longer use Signal Desktop on my work device since installing native apps is forbidden for good reasons, while Chrome Apps are okay. It also hurts Chrome OS users since Chrome Apps are being abandoned in favor of Electron. It also makes it less useful for developers to create Chrome Apps since the market is much smaller. Since Chrome Apps continue to be available on Chrome OS, I'm considering separating that functionality into a stand-alone runtime or making a custom build for Linux. Anyone wants to help with that?

xyzzy_plugh 9y ago
Your comment scared me, but TFA doesn't say that: > We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. Where do you see that chrome apps are being discontinued? Otherwise this is FUD.
- TimothyFitz 9y ago
  EOL for Chrome Apps outside of Chrome OS was announced in August 2016 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html?m=1 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
  - datguacdoh 9y ago
    But OP is specifically calling out how this hurts Chrome OS, but it doesn't seem to affect that platform, from what I can tell.

Crontab 9y ago

Is WebAssembley going to turn into yet another web technology that can be used by websites in order to track us or to annoy us with advertising? I'm asking because every time something new is introduced, it feels like it ends up being used to abuse users (Javascript, XSS, Cookies, HTML5 Video).

AsyncAwait 9y ago
Every piece of technology can be abused, that doesn't mean the technology itself is bad and shouldn't be adopted.
- nol13 9y ago
  Will WASM trackers/ads be harder to block than ECMA Script ones?
  - yorwba 9y ago
    ECMA Script trackers/ads are blobs of code that can sometimes be identified based on the requests they make, WASM trackers/ads are blobs of code that can sometimes be identified based on the requests they make. The only real difference is that the WASM variant will probably run faster than obfuscated ECMA Script.
    - _pmf_ 9y ago
      > The only real difference is that the WASM variant will probably run faster than obfuscated ECMA Script. ... which will lead to more ads being served, evening out any advantage.
marcosdumay 9y ago
It doesn't do anything that Javascript didn't already do. By the way, why do you think HTML5 is a problem?
- duskwuff 9y ago

_wmd 9y ago

The most material result of this is that Chromebooks won't have a working SSH client starting sometime next year, because WebAssembly can't do real sockets without an external proxy.

dragonwriter 9y ago
No, FTFA: “We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions.” Chrome Apps (and extensions) using PNaCl will continue to work.
- cbhl 9y ago
  Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020. Disclaimer: My opinion, not that of my employer.
  - dragonwriter 9y ago
    > Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020. Sure, it is deprecated and will be deactivated eventually (but maybe not soon; consider WebSQL). Google's got every incentive to make sure that WebAssembly (plus the APIs exposed in ChromeOS) provides a complete replacement for PNaCl and apps have had time to transition before doing that.
    - i336_ 9y ago
      WebSQL is so sad. https://stackoverflow.com/questions/42288596/websql-has-increasing-browser-support-whats-its-future https://stackoverflow.com/questions/42288596/websql-has-incr...
9y ago

xoroshiro 9y ago

I'm not familiar with what goes in a browser, but for some reason, browsers seem to eat up a lot of resources. While I am happy that it looks like this will (more or less) be standardized across browsers, I still hope for the day where running a more minimal browser (text, image, maybe videos) will become viable. Of course, I'm pessimistic on this, seeing as so many sites are probably not functional without javascript and other related technologies, but maybe some web developers care about choice. Who knows.

Ajedi32 9y ago
Well, there's AMP. Most people on HN seem to really hate that solution though.
IamCarbonMan 9y ago
I do this, or at least, I'm trying my hardest to. I use terminal interfaces to my usual sites like Reddit, Gmail, GitHub, Google, etc. A mouse button or keystroke opens links using a little script I've written which basically opens media files in feh/mpv/whatever, html sites using [Mercury](https://mercury.postlight.com/web-parser/ https://mercury.postlight.com/web-parser/) and links, and if I really need to open the page in Chrome for some reason, the open script will begin nagging me to find a terminal client for that service if I use it very often.

jhpriestley 9y ago

From the asm.js FAQ: Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript? A. The principal benefit of asm.js over whole new technologies like NaCl and PNaCl is that it works today asm.js however wasn't good enough to actually be useful, as evidenced by the lack of adoption and the move to wasm. So now we have wasm which is not backward compatible. We would be further along now if Mozilla/Eich would have gotten behind Google's more mature effort, this really was stubbornness IMO.

Analemma_ 9y ago
"Stubbornness" in refusing to let Google unilaterally decree web technologies and standards is stubbornness I support fully.
bobajeff 9y ago
Actually, the AOT optimization path for asm.js has been supported by Internet Explorer/Edge for quite some time. Chrome also supports AOT asm.js path now through their wasm implementation[1]. Before that Chrome and Safari did optimizations that just happened to make asm.js faster ;) It's likely that if WebAssembly didn't happen everyone would've implemented AOT optimizations for asm.js and all the new features (shared memory threads, simd, 64bit int etc.) would be targeting that instead. [1] http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-december-edition/ http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-dec...
roca 9y ago
PNaCl had two big problems Google never attempted to solve: * No spec, just import some particular version of LLVM and it does what it does * Dependence on Pepper for its platform API --- just a big pile of Chromium code that does what it does and duplicates all the standard Web APIs
- jhpriestley 9y ago
  I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't support it. Now they're backtracking and building a non-js asm system too. Do you think wasm apps will always use slow JavaScript ffi to call opengl say? We'll get a new pepper in like another decade.

seanwilson 9y ago

I'm so confused why Google deprecated Chrome Apps. You'd think they'd take advantage of the abundance of Electron apps by extending the capabilities of Chrome Apps to grow their Chrome ecosystem and attract new developers.

zurn 9y ago

Say hello to memory-unsafe languages and resulting vulnerabilities in web apps?

roca 9y ago
To some extent yes, but not nearly as bad. One feature Wasm has (shared with asm.js, but NOT PNaCl) is that the stack of return addresses lives outside addressable memory, and therefore can't be corrupted by an arbitrary-write primitive, so no ROP attacks. Likewise Wasm memory is entirely non-executable so you can't return or jump to exploit code. Function pointers are quite restricted; you can only make an indirect call to a function that's explicitly listed as indirectly-callable. Wasm applications can have type confusion bugs, use-after-free bugs, and array overflow bugs, etc, but this is inevitable for any realistic C/C++ compilation target.

willvarfar 9y ago

This is a sad day. NaCL was excellent tech, and its a shame it didn't get incorporated into LLVM proper, and that it didn't take off. We should be using NaCL/pNaCL for all apps everywhere, and for components within apps... etc. ZeroVM was a desktop/server sandboxing environment that just didn't get any attention and mindshare. Shame! I want a ZeroVM-like system that makes all of the Debian user-space available on any other OS, each app in a little sandbox... It ought just be another compiler target and automated. Oh to what could have been! :(

krzyk 9y ago
How is it better than WebAssembly?
- smitherfield 9y ago
  It executes (sandboxed) native code directly, instead of requiring JIT compilation to native.
  - Houshalter 9y ago
    But that wouldn't be portable to other architectures though. Webasm is supposed to run on anything a modern browser can run on. I think it would also be much harder to guarantee that's secure.
  - traverseda 9y ago
    Have you seen the "the birth and death of javascript"? More interestingly it could vastly reduce the cost of interprocess communication to the point where the idea of a process starts to look a bit weird. Want to query a database? Upload a function you wrote yourself for complicated queries like GIS, or let the SQL parser generate the raw wasm on your behalf. Want to authenticate your users, but don't want to deal with all the different permiations on hardare tokens, ssh keys, etc? Just let them upload a wasm function.
    - willvarfar 9y ago

lawthemi 9y ago

It's sad. PNACL is more efficient. Go to lichess.org/analysis, make a few moves, turn on the engine analysis. With firefox and WASM, my machine compute 300 knode/s. With chrome and PNACL, my machine compute 2000 knode/s. That's a big step backward.

gok 9y ago
I see nothing inherently more efficient about PNaCl. Both it and WASM expose an architecture-agnostic 32-bit virtual instruction set, then rely on the user agent to apply good optimization. WASM’s performance will improve. Non-portable NaCl did have the advantage that it could specifically target and optimize for one CPU architecture, and it had the beginnings of 64-bit address space support. These were nice, but not widely used. And we both could conceivably make it into WASM in the future.

ap46 9y ago

Can someone get opencv running on it?

Houshalter 9y ago
Webasm doesn't currently have access to SIMD instructions or the gpu. So that kind of intensive matrix math stuff might not benefit too much from webasm.

tehabe 9y ago

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 direction looks good so far.

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

r0anne 9y ago

>We will remove support for PNaCl in the first quarter of 2018 While the new Google Earth with PNaCl was just introduced, a large engineering cost for a semester-lived technology! Too bad

johncolanduoni 9y ago
The code base is almost certainly in C or C++. The parts that use the APIs will need to be changed, but it won't need anywhere close to a full rewrite.
nnethercote 9y ago
Plenty of people were left scratching their heads when the new Google Earth was introduced, precisely because it was clear that PNaCl's days were numbered. I think the likely explanation is that Google is a large company with numerous departments and those departments don't always pull in the same direction. I imagine some people within Google weren't happy with the Google Earth announcement.

TekMol 9y ago

Can somebody ELI 5 what is the benefit of WebAssembly vs Asm.js?

johncolanduoni 9y ago
It's a format designed to be a target for static languages that do manual memory management (like C/C++) instead of JavaScript that some engines know how to recognize and optimize. The binaries are smaller and much faster to parse and the sandbox model results in much less overhead. For a concrete example, at least two JavaScript engines (those of Chrome and Firefox) need to emit almost no range checks on regular memory accesses with WebAssembly on 64-bit computers. (For those interested in going past ELI5, they do this by allocating a large chunk of virtual address space, such that any out of range pointers will land somewhere in that space (WebAssembly currently only has 32-bit pointers). Some of the space is filled with memory, and the rest causes a controlled signal/exception so the engine can safely terminate the instance.)
- TekMol 9y ago
  target for static languages that do manual memory management So I will have to do all the garbage collection myself? Isn't that a huge burdon on the programmer? And will this lead to lots of apps with memory leaks that needlessly eat up my resources?
  - AgentME 9y ago
    That's already the case if you want to do high-performance stuff with C/C++. WebAssembly is primarily about getting that into the web.

JacobiX 9y ago

We used PNaCl to port some games to a Smart TV. It was a painful experience. Debugging chrome from a custom gdb, breaking changes from release to release, and some very subtle bugs in pepper API. But the final results were surprisingly not so awful.