21 ms·

W3C recommends WebAssembly

385 points by lottamus 7y ago

dm33tri 7y ago
Write once, run everywhere. I bet in few years we will run wasm natively on processor.
- giancarlostoro 7y ago
  Didn't Apple do some CPU that runs JavaScript in a more optimized fashion? It wouldn't surprise me, which is odd cause for years I heard that was the plan for Java, but regular processors got faster and faster and the VM stayed.
  - grenoire 7y ago
    There have been ARM chips with added instructions for faster JavaScript processing due to some very odd and non-standard behaviour for common operations. See https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... for more deets.
- oefrha 7y ago
  https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- kevingadd 7y ago
  WASM is poorly designed for execution directly in-silicon. It's not that kind of IR. You'd lower it into some other representation no matter what, so why not x86 or ARM? The hardware already exists and the development tools exist too.
  - sitkack 7y ago
    The instructions in your binaries aren't directly executed either, they get lowered into uOps.
    - aseipp 7y ago
      That's not really relevant to the suitability of WASM in hardware, though. uops are an implementation detail of microarchitectures; even if you do not introduce the uop design into your architecture, x86, ARM, etc ISAs are still efficient to implement in logic for a number of reasons. For example, instructions in a traditional ISA normally encode things like the register operands they reference as part of encoded instruction. The bits corresponding to the register operands are carefully designed to index into another piece of memory, the register file. This means decoding the operands from an instruction and referencing the relevant registers is extremely cheap in hardware, because you simply slice a few bits out of an existing wire and do a lookup/relative increment/whatever. Similarly, things like relative jumps are encoded directly as offsets that get added to an instruction pointer, which again is extremely cheap. In contrast, WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing an instruct pointer register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' or inlining the table values to work around before being executed, or, alternatively, you'd have to just bite the bullet and put limits on their size, and eat the cost of the indirection. Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that information and translate it to direct jump operations. At this point, you are just implementing a compiler, and if you choose to do it in hardware, you are willingly trying to shoot yourself in the foot (or the face), and it will end badly. You're far better off calling a spade a spade and compiling, in software, to a representation that actually can be implemented efficiently in hardware. But you could of course hide this compiler in the firmware to make it "seem" like WebAssembly is the native ISA, and the small surface area of the specification can help ensure you do it safely and correctly. This is probably for the best anyway, because it's dramatically harder to design correct hardware vs correct software.
- thesuperbigfrog 7y ago
  WASM machines--the next (hopefully) better version of Lisp machines (https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine)! It looks like Gary Bernhardt was pretty spot on in his talk "The Birth and Death of JavaScript": (https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...)
  - monocasa 7y ago
    Lisp machines didn't go away because of some conspiracy, they just stopped making sense. The vast majority of the benefit was that since they ran on (and were compared to other) 1980s minicomputer hardware without instruction caches, pulling the interpreter into microcode meant that the interpreter's overhead wasn't competing with data fetches on the von Neumann memory bus. Instruction caches (and JITs to a degree) solve the same problem in much more general ways. That's why Azul went out of their way to create an appliance to run Java code with custom CPUs, and ended up with a pretty standard RISC for the most part. All of that applies to WASM machines too.
- GlitchMr 7y ago
  I don't think that will happen. The design of WebAssembly (in particular not having GOTOs) isn't really hardware-implementation friendly. I would rather expect hardware JVM or BPF implementation than WASM.
- goto11 7y ago
  This was also attempted for Java bytecode but didn't really pan out. I think the benefit just wasn't there compared to JIT compiling for a regular processor. The processes would have to translate the wasm into some form of register-based operations anyway, and a JIT compiler might be able to do this more efficiently since it can see a bigger picture than the processor.
  - int_19h 7y ago
    JVM bytecode is very high-level though (it deals with objects, and has opcodes for method calls etc). Wasm is in this interesting spot where it's relatively low-level, but high-level enough to allow proper sandboxing. It strikes me that the arrangements to accommodate that, like call indirection via tables, could be optimized on CPU level. Not necessarily in a sense of a CPU that directly runs wasm, but rather a CPU architecture which is optimized to be a target for JIT or AOT compilers from wasm.
    - marcthe12 7y ago
      I wonder it's small enough to have the interpreter in kernel space
- Sharlin 7y ago
  Just like we these days run JVM bytecode natively on processors.
- Ididntdothis 7y ago
  I know. And we all use Java native CPUs right now.
tmountain 7y ago
What's the horizon for WebAssembly capable browsers gaining enough marketshare that it becomes a viable compilation target?
- dangoor 7y ago
  Looks like it probably already is a viable target for many apps (at 88%+ share): https://caniuse.com/#search=wasm https://caniuse.com/#search=wasm
- no_wizard 7y ago
  Unless you have to support internet explorer for any reason, that would be today: https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm
- oefrha 7y ago
  https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm Pretty much all relevant browsers support wasm (and I suspect data for the few non-compliant Chinese browsers may be outdated, they’re definitely not last released in 2016 or 2017). Do you have some other idea of wasm-capable?
  - pastage 7y ago
    Our buisness instances are 30% IE, luckily not even that is enough to get anyone to care about IE around here.
    - oefrha 7y ago
      At least you can rest assured it’ll never get wasm support.
- austincheney 7y ago
  WASM has been available in all modern browsers for a few years. Availability isn't whats limiting adoption. Here are the limitations as I see them: * Sandbox. WASM is a sandbox. Think of WASM as a language agnostic replacement for Flash. It is an island in a webpage isolated from that page. This is great for security so that the opaque binary running in that WASM island cannot modify the page in such ways as to violate the same origin policy, such as turning a button into a hyperlink with a user's personal details attached as query parameters on a malicious third party URL. It also means code executing in WASM cannot interact with the surrounding page, which means it isn't a JavaScript replacement. The developers of the WASM standard have been very clear that WASM will not ever be a JavaScript replacement. To be fair there is work being done, several years in the making, to provide web-like technologies to WASM instances, such as a DOM. This enhancement eases some concerns of overhead, see the next bullet point, but they won't break security or escape the sandbox. This enhancement might go so far as allowing the containing page interaction with the WASM instance, but I suspect this would be limited, if at all, and only cross the sandbox barrier in one direction. There is huge interest in WASM and page interaction, but this is all coming from developers who want alternatives to JavaScript. There is no prevailing business interest in advanced WASM interaction. * Overhead. Since WASM is a self-contained sandbox the incoming binary needs everything an application binary would otherwise need to execute as an application. For example if a WASM instance wants to pretend to be web page instance then it has to include its own DOM library, interaction code, presentation, and absolutely everything else. If accessibility is a concern you would likely have to reinvent how that works in your WASM instance. While this is of great interest for developers who hate JavaScript there isn't a lot of business value in that. * Performance. So far WASM has not been able to significantly outperform JavaScript. In many cases WASM code performs slower than JavaScript. Without a large performance differentiation there is little business justification to invest in WASM. Flash's claim to fame is that for most of Flash's life it did significantly outperform JavaScript by an order of magnitude. JavaScript never got faster than Flash, but it did almost completely close the performance gap. Once JavaScript got fast Flash started dying. --- There is potential business value in WASM, but you have to be willing to abandon any consideration that you are executing in a web page. Selling the idea to business owners that you are executing in a web page, but you need to imagine that you aren't is a tough sell. Here are some ideas that might work better in WASM than the typical web environment: * Document interaction with digital signatures from physical tokens. * Streaming media players with embedded DRM. * Certificate negotiation for an end-to-end encrypted messaging tunnel transmitted via web page.
markstos 7y ago
This is bad for frontend JavaScript being "open" for review, right? Companies will ask their developers to deliver WASM resources in the name of performance. As a notable side-effect, it will become harder to review how websites work. Yes, I'm sure there will be reverse-compilation tools for WASM, but still.
- nicoburns 7y ago
  Complex websites are already delivering minified source. This isn't really meaningfully different. Luckily with so much open source code, it's less important to be able to inspect live websites these days.
- williamdclt 7y ago
  It's pretty rare companies ask their devs for a specific tech. The execs don't really have any idea what is the difference between JS and WASM, or what is WASM, or what is JS. And minified JS isn't particularly more reviewable I think
- icey 7y ago
  So much frontend JS has been packed and minified now that I’m not sure it will make that much difference. Reviewing Open Source code is still a far superior way to understand how code works, imo.
  - sprash 7y ago
    Unminified javascript is far easier to understand than disassembled code which originated from compiled C++ or Rust. It is possible to disable half of the paywalls on the web just by looking at the JS code. I can see why certain parties would push really hard to introduce Webassembly. The performance argument is just a pretext because today's jit compilers for Javascript are really good.
    - arthurcolle 7y ago
      > It is possible to disable half of the paywalls on the web just by looking at the JS code. Shhh! Don't tell them!
dmvinson 7y ago
This feels like another step away from the free and open web many people are clamoring for. Distributing opaque binaries with websites instead of Javascript is a step past even the obfuscated minified javascript files meant to be confusing. At least those can still be debugged, stepped through, and explored freely by the end user if they want to learn or reverse engineer. Is there any tool or standard being worked on to make .wasm files coherent for users who have to run the code to view websites? This feels like a step backwards in so many ways, even if it is a technological marvel.
- mbrock 7y ago
  Doesn’t that reasoning also imply that GNU and Linux are awfully opaque and not free nor open, since they are typically distributed as binaries?
  - re-actor 7y ago
    If the binaries were the only way to access GNU or Linux then yes, obviously. That's not the case now is it.
    - mbrock 7y ago
      Right, because when you distribute free software in binary form, you make sure to make the source code available with a copyright license disclaimer allowing redistribution. This applies exactly to WebAssembly software just as it does with Java software. Software freedom is compatible with binary distribution.
  - neckardt 7y ago
    No, because GNU and Linux are bound by license restrictions which require the unobfuscated source code to be made available. If all websites made their source available as well as distributing the binary, there wouldn't be a problem.
    - deleted 7y ago
      [deleted]
duxup 7y ago
Does anyone have any good intro resources for WebAssembly for noobs? I've read articles here and there seen some in person demos, and honestly struggle to understand what it is / how it would / works relative to the current state of JavaScript frameworks. Often I'm approaching it from a JavaScript framework (React/Vue/Angular) approach as I'm a bit of a noob to the industry and that's generally my day job working on web applications.... and while I read about WebAssembly I wonder about state management and someone tells me "oh you still need to something to do that" and I'm a bit lost on ... how that would work / why I would or wouldn't use one of those frameworks anyway, etc. So many examples I've seen are one off simplified (and for good reason I like those for demos) widgets but ... I'm not sure I've seen them as an application / understand how that would work. Obviously I'm missing a lot here and feel like on HN I'm often talking to folks who aren't so much front end web devs who are excited about the efficiencies and such but ... not sure how this plays out in a practical sense / relative to the state of web applications as they are now.
- rdudekul 7y ago
  You may like Lin Clark's posts on the subject: https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/ https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse... https://hacks.mozilla.org/category/code-cartoons/ https://hacks.mozilla.org/category/code-cartoons/
  - StreamBright 7y ago
    I don't think it is a particularly great explanation of what WASM is. >> Wait, so what is WebAssembly? >> WebAssembly is a way of taking code written in programming languages other than JavaScript and running that code in the browser. So when people say that WebAssembly is fast, what they are comparing it to is JavaScript. A better definition: > WASM is a binary instruction format for a stack-based virtual machine[1] This goes into some details that could answer the question raised in this thread: > WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript. More useful details: >> Engineers from the four major browser vendors have risen to the challenge and collaboratively designed a portable low-level bytecode called WebAssembly. It offers compact representation, efficient validation and compilation, and safe low to no-overhead execution. Rather than committing to a specific programming model, WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web. WebAssembly has been designed with a formal semantics from the start. [2] More details from Wikipedia: >> Wasm does not replace JavaScript; in order to use Wasm in browsers, users may use Emscripten SDK to compile C++ (or any other LLVM-supported language such as D or Rust) source code into a binary file which runs in the same sandbox as regular JavaScript code. ... There is no direct Document Object Model (DOM) access; however, it is possible to create proxy functions for this. [3] I hope this helps. 1. https://webassembly.org https://webassembly.org 2. https://dl.acm.org/citation.cfm?doid=3140587.3062363 https://dl.acm.org/citation.cfm?doid=3140587.3062363 3. https://en.wikipedia.org/wiki/WebAssembly https://en.wikipedia.org/wiki/WebAssembly
bogwog 7y ago
Hopefully this also means that Javascript is going away for good
- k__ 7y ago
  I think people starting to pump giant binaries to the browser will lead to JavaScript leveraging its strengths and getting even better.
  - bogwog 7y ago
    > I think people starting to pump giant binaries to the browser As if that's not already happening today with obfuscated and minified javascript
    - krapp 7y ago
      Those aren't technically binaries, as much as people want to cling to the metaphor of javascript as "bytecode" and pretend no distinction exists between the two.
      - bogwog 7y ago
        > and pretend no distinction exists between the two. What's the distinction then? That obfuscated javascript can be looked at by people who don't know how to use a hex editor?
        krapp 7y ago
        Javascript-as-bytecode is a metaphor, not a technical description. Javascript is not actually bytecode in the same way that a .java file is not java bytecode.
        bogwog 7y ago
        Okay. Thanks for that.
dmitriid 7y ago
Ok. It's here to stay. What's the progress on the two dozen post-MVP features? The "arrival" of WebAsm to w3c only means that w3c had finally woken up from eternal slumber and realized that everyone has already implemented The listed features.
Unit-336 7y ago
For those who are asking themselves what WASM does differently than Java, .NET or other native extensions like ActiveX or NaCl, here's the best rationale doc I found on this topic: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf https://github.com/WebAssembly/spec/blob/master/papers/pldi2...
- miohtama 7y ago
  Thank you. This is the most exhaust ive article on WebAssembly design goals I have read.
magsnus 7y ago
I really hope this can become a viable alternative to the JS-frameworks we have today for webapps and that more apps can be served via the web.
- tiborsaas 7y ago
  In what way viable alternative? JS performance is pretty good if you think of an admin interface or any business dashboard UI full of charts and stuff. React for example shifting towards functional programming makes FE apps simpler and predictable. If you dislike the HTML/CSS UI layer then WA is indeed an alternative. However you need to reimplement everything, like text selection, right click, focus, accessibility, dropdowns, etc, because all you have is a <canvas> to draw on. But! WA will eventually have DOM access, that will definitely open up the landscape to create new frontend frameworks.
- gavinray 7y ago
  There are already several libraries that allow you to write React-like SPAs in the browser via WASM. The two largest are Yew (Rust), Vugu (Vue-esque but with Go instead of JS), and Blazor (C#) https://github.com/yewstack/yew https://github.com/yewstack/yew https://github.com/vugu/vugu https://github.com/vugu/vugu https://github.com/aspnet/Blazor https://github.com/aspnet/Blazor All are perfectly viable for production apps as of today and not much more difficult than writing React, given you have some familiarity with their implementation language.
cryptozeus 7y ago
Why are people saying with wasm coming JavaScript will have tough time ? Think about it as flash vs JavaScript. They can happily co exist or u can choose one of the other. Don’t assume that wasm is the hammer for every nail.
6gvONxR4sf7o 7y ago
Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extensions or even scrape the web without a BigCo webcrawler's level of infra investment. Is everything going to turn into an opaque single page app? Technically, webassembly is really cool, but I worry about where the browser is headed.
- EvanAnderson 7y ago
  Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can interact with. You'll have to agree to let them run arbitrary code on your machine to even view the "website". There will be no "browse w/o Javascript" option in that future. The kind of jerks who liked adding Javascript to block right-clicking, blocking "Paste" into password fields, etc, are going to absolutely love using the browser-in-a-browser product to deliver their "website". For the inevitable replies: Yes-- you can already do this with minified Javascript. WASM, being targeted for performance, is just going to make this kind of asshattery faster.
  - linuxftw 7y ago
    Smart phone apps already do this.
    - jhallenworld 7y ago
      Emulate Android or IOS in the browser- that way you only have to write an app, and not bother with a website.. All it will take is for ADK to a have button that produces a wasm version of your app.
postit 7y ago
It amuses me we're circle backing to have applets all over again.
- tiborsaas 7y ago
  This time we did it better, cheers.
  - erokar 7y ago
    That remains to be determined.
- chippy 7y ago
  I really liked applets. It was Flash more than security concerns that killed them I think
cylon13 7y ago
What's the debugging situation like for developing WASM apps? I'm doing a lot of TypeScript+WebGL work right now, and though TS is fairly nice, my use case requires being aware of not allocating too many new objects frequently, and that kind of control would be easier in something like C++ or Rust. I've been thinking of hacking together a small test project with WASM+WebGL to see what it's like, but I get the sense it might still be more hassle than it's worth to use in production. Currently I can easily set breakpoints in my TS code, I can see how much memory is allocated by which functions, how much time is spent in each function, etc. very easily. If there's a way to do these kinds of things with WASM in another language, that would be fantastic.
- echeese 7y ago
  The tools are still being worked on but the Chrome team made a pretty big step by adding DWARF support to the debugger: https://twitter.com/ChromeDevTools/status/1192803818024710145 https://twitter.com/ChromeDevTools/status/119280381802471014... EDIT: Here's an article from yesterday about this: https://developers.google.com/web/updates/2019/12/webassembly https://developers.google.com/web/updates/2019/12/webassembl...
utf985 7y ago
I'm interested in how will WebAssembly affect the functionality of browser addons such as ad and script blockers?
dm33tri 7y ago
What I'm thrilled to see is an optimization of binary sizes in compilers and libraries. Maybe <1MB native apps will become common (or few MB of code for single webpage will become standard)
shiado 7y ago
Does anybody know the state of the art for wasm tooling? I have used emscripten but are there any excellent 'higher level' tools? The worst part was writing the interface between the wasm and JS.
Crontab 7y ago
This sounds interesting, but personally, I am worried that this will just turn into yet another browser technology that will be used to abuse and track users. I really hope I am wrong.
deleted 7y ago
[deleted]
batterystd 7y ago
So what was webassemnly until now?
chx 7y ago
How's the DOM manipulation coming along?
smattiso 7y ago
Good. Javascript needs to die. It was far simpler to build performant multi-device UIs 15 years ago than it is today. Building UIs natively on iOS and Android is so much simpler than building for the web. Technical question: 1.) What is the speed of WebAssembly on iOS WebKit and Android WebView? 2.) Is it feasible to write an entire app UI in something like Qt and target WebAssembly? 3.) Android, iOS, Windows versions of the app are Qt apps natively or possibly through the device's WebKit. Is this possible today? Is there a better UI library than Qt for this?
- MuffinFlavored 7y ago
  > Building UIs natively on iOS and Android is so much simpler than building for the web. I can get lit-element with no build process going to prototype something in a single .html file in probably 30 seconds. I don't think XCode/iOS developers can compete with the simplicity. Define initial state, alter it through events, pull data through fetch(), write HTML. I know for a fact iOS development isn't that simple.
  - saagarjha 7y ago
    Swift Playgrounds, when they work, can compete with that somewhat.
arghwhat 7y ago
W3C endorsing it has nothing at all to do with whether or not it is here to stay.
dang 7y ago
The submitted title was "It's official, WebAssembly is here to stay". That broke the site guidelines by editorializing. Please don't do that.
mrandish 7y ago
Does WebAssembly threaten app store business models by allowing devs to distribute apps directly via browser (thereby saving the app store 'tax')? For example, if Adobe delivers its new mobile Photoshop directly via iPad Safari will Apple have a way of 'nerfing' WebAssembly to stop them?
nojvek 7y ago
The design goals of WebAssembly are the following: Fast, safe, and portable semantics: * Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware. * Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches. * Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally. * Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike. * Language-independent: does not privilege any particular language, programming model, or object model. * Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments. * Open: programs can interoperate with their environment in a simple and universal manner. Efficient and portable representation: * Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats. * Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately. * Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation. * Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen. * Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks. * Portable: makes no architectural assumptions that are not broadly supported across modern hardware. If webassembly is truly able to meet this goals, together with good debugging and tools, it will become the the universal way to represent computation across devices and platforms. Really cool.
- skunkworker 7y ago
  Two of the most exciting applications I've come across so far are allowing for in-browser audio encoding with a provided encoder and distributing WASM binaries to run on edge servers. About 5 years ago I tried to use an optimized javascript file to encode some audio in browser before uploading, it was painfully slow and very hardware intensive. But using wasm in the vmsg [1], it distributes the LAME encoder allowing for in-browser MP3 encoding. And secondly cloudflare allows for their workers to be written in WASM, allowing for more processor intensive apps (like resizing an image) to be completely on the edge. I see it as eventually fulfilling the portability goals that java applets in the browsers use to have, but instead of one you have many companies agreeing on the implementation. [1] https://github.com/Kagami/vmsg https://github.com/Kagami/vmsg [2] https://blog.cloudflare.com/webassembly-on-cloudflare-workers/ https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
apatheticonion 7y ago
<script type="module" src="app.wasm"></script> Please

385 points by lottamus 7y ago

dm33tri 7y ago

Write once, run everywhere. I bet in few years we will run wasm natively on processor.

giancarlostoro 7y ago
Didn't Apple do some CPU that runs JavaScript in a more optimized fashion? It wouldn't surprise me, which is odd cause for years I heard that was the plan for Java, but regular processors got faster and faster and the VM stayed.
- grenoire 7y ago
  There have been ARM chips with added instructions for faster JavaScript processing due to some very odd and non-standard behaviour for common operations. See https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... for more deets.
oefrha 7y ago
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
kevingadd 7y ago
WASM is poorly designed for execution directly in-silicon. It's not that kind of IR. You'd lower it into some other representation no matter what, so why not x86 or ARM? The hardware already exists and the development tools exist too.
- sitkack 7y ago
  The instructions in your binaries aren't directly executed either, they get lowered into uOps.
  - aseipp 7y ago
    That's not really relevant to the suitability of WASM in hardware, though. uops are an implementation detail of microarchitectures; even if you do not introduce the uop design into your architecture, x86, ARM, etc ISAs are still efficient to implement in logic for a number of reasons. For example, instructions in a traditional ISA normally encode things like the register operands they reference as part of encoded instruction. The bits corresponding to the register operands are carefully designed to index into another piece of memory, the register file. This means decoding the operands from an instruction and referencing the relevant registers is extremely cheap in hardware, because you simply slice a few bits out of an existing wire and do a lookup/relative increment/whatever. Similarly, things like relative jumps are encoded directly as offsets that get added to an instruction pointer, which again is extremely cheap. In contrast, WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing an instruct pointer register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' or inlining the table values to work around before being executed, or, alternatively, you'd have to just bite the bullet and put limits on their size, and eat the cost of the indirection. Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that information and translate it to direct jump operations. At this point, you are just implementing a compiler, and if you choose to do it in hardware, you are willingly trying to shoot yourself in the foot (or the face), and it will end badly. You're far better off calling a spade a spade and compiling, in software, to a representation that actually can be implemented efficiently in hardware. But you could of course hide this compiler in the firmware to make it "seem" like WebAssembly is the native ISA, and the small surface area of the specification can help ensure you do it safely and correctly. This is probably for the best anyway, because it's dramatically harder to design correct hardware vs correct software.
thesuperbigfrog 7y ago
WASM machines--the next (hopefully) better version of Lisp machines (https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine)! It looks like Gary Bernhardt was pretty spot on in his talk "The Birth and Death of JavaScript": (https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...)
- monocasa 7y ago
  Lisp machines didn't go away because of some conspiracy, they just stopped making sense. The vast majority of the benefit was that since they ran on (and were compared to other) 1980s minicomputer hardware without instruction caches, pulling the interpreter into microcode meant that the interpreter's overhead wasn't competing with data fetches on the von Neumann memory bus. Instruction caches (and JITs to a degree) solve the same problem in much more general ways. That's why Azul went out of their way to create an appliance to run Java code with custom CPUs, and ended up with a pretty standard RISC for the most part. All of that applies to WASM machines too.
GlitchMr 7y ago
I don't think that will happen. The design of WebAssembly (in particular not having GOTOs) isn't really hardware-implementation friendly. I would rather expect hardware JVM or BPF implementation than WASM.
goto11 7y ago
This was also attempted for Java bytecode but didn't really pan out. I think the benefit just wasn't there compared to JIT compiling for a regular processor. The processes would have to translate the wasm into some form of register-based operations anyway, and a JIT compiler might be able to do this more efficiently since it can see a bigger picture than the processor.
- int_19h 7y ago
  JVM bytecode is very high-level though (it deals with objects, and has opcodes for method calls etc). Wasm is in this interesting spot where it's relatively low-level, but high-level enough to allow proper sandboxing. It strikes me that the arrangements to accommodate that, like call indirection via tables, could be optimized on CPU level. Not necessarily in a sense of a CPU that directly runs wasm, but rather a CPU architecture which is optimized to be a target for JIT or AOT compilers from wasm.
  - marcthe12 7y ago
    I wonder it's small enough to have the interpreter in kernel space
Sharlin 7y ago
Just like we these days run JVM bytecode natively on processors.
Ididntdothis 7y ago
I know. And we all use Java native CPUs right now.

tmountain 7y ago

What's the horizon for WebAssembly capable browsers gaining enough marketshare that it becomes a viable compilation target?

dangoor 7y ago
Looks like it probably already is a viable target for many apps (at 88%+ share): https://caniuse.com/#search=wasm https://caniuse.com/#search=wasm
no_wizard 7y ago
Unless you have to support internet explorer for any reason, that would be today: https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm
oefrha 7y ago
https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm Pretty much all relevant browsers support wasm (and I suspect data for the few non-compliant Chinese browsers may be outdated, they’re definitely not last released in 2016 or 2017). Do you have some other idea of wasm-capable?
- pastage 7y ago
  Our buisness instances are 30% IE, luckily not even that is enough to get anyone to care about IE around here.
  - oefrha 7y ago
    At least you can rest assured it’ll never get wasm support.
austincheney 7y ago
WASM has been available in all modern browsers for a few years. Availability isn't whats limiting adoption. Here are the limitations as I see them: * Sandbox. WASM is a sandbox. Think of WASM as a language agnostic replacement for Flash. It is an island in a webpage isolated from that page. This is great for security so that the opaque binary running in that WASM island cannot modify the page in such ways as to violate the same origin policy, such as turning a button into a hyperlink with a user's personal details attached as query parameters on a malicious third party URL. It also means code executing in WASM cannot interact with the surrounding page, which means it isn't a JavaScript replacement. The developers of the WASM standard have been very clear that WASM will not ever be a JavaScript replacement. To be fair there is work being done, several years in the making, to provide web-like technologies to WASM instances, such as a DOM. This enhancement eases some concerns of overhead, see the next bullet point, but they won't break security or escape the sandbox. This enhancement might go so far as allowing the containing page interaction with the WASM instance, but I suspect this would be limited, if at all, and only cross the sandbox barrier in one direction. There is huge interest in WASM and page interaction, but this is all coming from developers who want alternatives to JavaScript. There is no prevailing business interest in advanced WASM interaction. * Overhead. Since WASM is a self-contained sandbox the incoming binary needs everything an application binary would otherwise need to execute as an application. For example if a WASM instance wants to pretend to be web page instance then it has to include its own DOM library, interaction code, presentation, and absolutely everything else. If accessibility is a concern you would likely have to reinvent how that works in your WASM instance. While this is of great interest for developers who hate JavaScript there isn't a lot of business value in that. * Performance. So far WASM has not been able to significantly outperform JavaScript. In many cases WASM code performs slower than JavaScript. Without a large performance differentiation there is little business justification to invest in WASM. Flash's claim to fame is that for most of Flash's life it did significantly outperform JavaScript by an order of magnitude. JavaScript never got faster than Flash, but it did almost completely close the performance gap. Once JavaScript got fast Flash started dying. --- There is potential business value in WASM, but you have to be willing to abandon any consideration that you are executing in a web page. Selling the idea to business owners that you are executing in a web page, but you need to imagine that you aren't is a tough sell. Here are some ideas that might work better in WASM than the typical web environment: * Document interaction with digital signatures from physical tokens. * Streaming media players with embedded DRM. * Certificate negotiation for an end-to-end encrypted messaging tunnel transmitted via web page.

markstos 7y ago

This is bad for frontend JavaScript being "open" for review, right? Companies will ask their developers to deliver WASM resources in the name of performance. As a notable side-effect, it will become harder to review how websites work. Yes, I'm sure there will be reverse-compilation tools for WASM, but still.

nicoburns 7y ago
Complex websites are already delivering minified source. This isn't really meaningfully different. Luckily with so much open source code, it's less important to be able to inspect live websites these days.
williamdclt 7y ago
It's pretty rare companies ask their devs for a specific tech. The execs don't really have any idea what is the difference between JS and WASM, or what is WASM, or what is JS. And minified JS isn't particularly more reviewable I think
icey 7y ago
So much frontend JS has been packed and minified now that I’m not sure it will make that much difference. Reviewing Open Source code is still a far superior way to understand how code works, imo.
- sprash 7y ago
  Unminified javascript is far easier to understand than disassembled code which originated from compiled C++ or Rust. It is possible to disable half of the paywalls on the web just by looking at the JS code. I can see why certain parties would push really hard to introduce Webassembly. The performance argument is just a pretext because today's jit compilers for Javascript are really good.
  - arthurcolle 7y ago
    > It is possible to disable half of the paywalls on the web just by looking at the JS code. Shhh! Don't tell them!

dmvinson 7y ago

This feels like another step away from the free and open web many people are clamoring for. Distributing opaque binaries with websites instead of Javascript is a step past even the obfuscated minified javascript files meant to be confusing. At least those can still be debugged, stepped through, and explored freely by the end user if they want to learn or reverse engineer. Is there any tool or standard being worked on to make .wasm files coherent for users who have to run the code to view websites? This feels like a step backwards in so many ways, even if it is a technological marvel.

mbrock 7y ago
Doesn’t that reasoning also imply that GNU and Linux are awfully opaque and not free nor open, since they are typically distributed as binaries?
- re-actor 7y ago
  If the binaries were the only way to access GNU or Linux then yes, obviously. That's not the case now is it.
  - mbrock 7y ago
    Right, because when you distribute free software in binary form, you make sure to make the source code available with a copyright license disclaimer allowing redistribution. This applies exactly to WebAssembly software just as it does with Java software. Software freedom is compatible with binary distribution.
- neckardt 7y ago
  No, because GNU and Linux are bound by license restrictions which require the unobfuscated source code to be made available. If all websites made their source available as well as distributing the binary, there wouldn't be a problem.
  - deleted 7y ago
    [deleted]

duxup 7y ago

Does anyone have any good intro resources for WebAssembly for noobs? I've read articles here and there seen some in person demos, and honestly struggle to understand what it is / how it would / works relative to the current state of JavaScript frameworks. Often I'm approaching it from a JavaScript framework (React/Vue/Angular) approach as I'm a bit of a noob to the industry and that's generally my day job working on web applications.... and while I read about WebAssembly I wonder about state management and someone tells me "oh you still need to something to do that" and I'm a bit lost on ... how that would work / why I would or wouldn't use one of those frameworks anyway, etc. So many examples I've seen are one off simplified (and for good reason I like those for demos) widgets but ... I'm not sure I've seen them as an application / understand how that would work. Obviously I'm missing a lot here and feel like on HN I'm often talking to folks who aren't so much front end web devs who are excited about the efficiencies and such but ... not sure how this plays out in a practical sense / relative to the state of web applications as they are now.

rdudekul 7y ago
You may like Lin Clark's posts on the subject: https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/ https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse... https://hacks.mozilla.org/category/code-cartoons/ https://hacks.mozilla.org/category/code-cartoons/
- StreamBright 7y ago
  I don't think it is a particularly great explanation of what WASM is. >> Wait, so what is WebAssembly? >> WebAssembly is a way of taking code written in programming languages other than JavaScript and running that code in the browser. So when people say that WebAssembly is fast, what they are comparing it to is JavaScript. A better definition: > WASM is a binary instruction format for a stack-based virtual machine[1] This goes into some details that could answer the question raised in this thread: > WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript. More useful details: >> Engineers from the four major browser vendors have risen to the challenge and collaboratively designed a portable low-level bytecode called WebAssembly. It offers compact representation, efficient validation and compilation, and safe low to no-overhead execution. Rather than committing to a specific programming model, WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web. WebAssembly has been designed with a formal semantics from the start. [2] More details from Wikipedia: >> Wasm does not replace JavaScript; in order to use Wasm in browsers, users may use Emscripten SDK to compile C++ (or any other LLVM-supported language such as D or Rust) source code into a binary file which runs in the same sandbox as regular JavaScript code. ... There is no direct Document Object Model (DOM) access; however, it is possible to create proxy functions for this. [3] I hope this helps. 1. https://webassembly.org https://webassembly.org 2. https://dl.acm.org/citation.cfm?doid=3140587.3062363 https://dl.acm.org/citation.cfm?doid=3140587.3062363 3. https://en.wikipedia.org/wiki/WebAssembly https://en.wikipedia.org/wiki/WebAssembly

bogwog 7y ago

Hopefully this also means that Javascript is going away for good

k__ 7y ago
I think people starting to pump giant binaries to the browser will lead to JavaScript leveraging its strengths and getting even better.
- bogwog 7y ago
  > I think people starting to pump giant binaries to the browser As if that's not already happening today with obfuscated and minified javascript
  - krapp 7y ago
    Those aren't technically binaries, as much as people want to cling to the metaphor of javascript as "bytecode" and pretend no distinction exists between the two.
    - bogwog 7y ago
      > and pretend no distinction exists between the two. What's the distinction then? That obfuscated javascript can be looked at by people who don't know how to use a hex editor?
      - krapp 7y ago
        Javascript-as-bytecode is a metaphor, not a technical description. Javascript is not actually bytecode in the same way that a .java file is not java bytecode.
        bogwog 7y ago
        Okay. Thanks for that.

dmitriid 7y ago

Ok. It's here to stay. What's the progress on the two dozen post-MVP features? The "arrival" of WebAsm to w3c only means that w3c had finally woken up from eternal slumber and realized that everyone has already implemented The listed features.

Unit-336 7y ago

For those who are asking themselves what WASM does differently than Java, .NET or other native extensions like ActiveX or NaCl, here's the best rationale doc I found on this topic: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf https://github.com/WebAssembly/spec/blob/master/papers/pldi2...

miohtama 7y ago
Thank you. This is the most exhaust ive article on WebAssembly design goals I have read.

magsnus 7y ago

I really hope this can become a viable alternative to the JS-frameworks we have today for webapps and that more apps can be served via the web.

tiborsaas 7y ago
In what way viable alternative? JS performance is pretty good if you think of an admin interface or any business dashboard UI full of charts and stuff. React for example shifting towards functional programming makes FE apps simpler and predictable. If you dislike the HTML/CSS UI layer then WA is indeed an alternative. However you need to reimplement everything, like text selection, right click, focus, accessibility, dropdowns, etc, because all you have is a <canvas> to draw on. But! WA will eventually have DOM access, that will definitely open up the landscape to create new frontend frameworks.
gavinray 7y ago
There are already several libraries that allow you to write React-like SPAs in the browser via WASM. The two largest are Yew (Rust), Vugu (Vue-esque but with Go instead of JS), and Blazor (C#) https://github.com/yewstack/yew https://github.com/yewstack/yew https://github.com/vugu/vugu https://github.com/vugu/vugu https://github.com/aspnet/Blazor https://github.com/aspnet/Blazor All are perfectly viable for production apps as of today and not much more difficult than writing React, given you have some familiarity with their implementation language.

cryptozeus 7y ago

Why are people saying with wasm coming JavaScript will have tough time ? Think about it as flash vs JavaScript. They can happily co exist or u can choose one of the other. Don’t assume that wasm is the hammer for every nail.

6gvONxR4sf7o 7y ago

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extensions or even scrape the web without a BigCo webcrawler's level of infra investment. Is everything going to turn into an opaque single page app? Technically, webassembly is really cool, but I worry about where the browser is headed.

EvanAnderson 7y ago
Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can interact with. You'll have to agree to let them run arbitrary code on your machine to even view the "website". There will be no "browse w/o Javascript" option in that future. The kind of jerks who liked adding Javascript to block right-clicking, blocking "Paste" into password fields, etc, are going to absolutely love using the browser-in-a-browser product to deliver their "website". For the inevitable replies: Yes-- you can already do this with minified Javascript. WASM, being targeted for performance, is just going to make this kind of asshattery faster.
- linuxftw 7y ago
  Smart phone apps already do this.
  - jhallenworld 7y ago
    Emulate Android or IOS in the browser- that way you only have to write an app, and not bother with a website.. All it will take is for ADK to a have button that produces a wasm version of your app.

postit 7y ago

It amuses me we're circle backing to have applets all over again.

tiborsaas 7y ago
This time we did it better, cheers.
- erokar 7y ago
  That remains to be determined.
chippy 7y ago
I really liked applets. It was Flash more than security concerns that killed them I think

cylon13 7y ago

What's the debugging situation like for developing WASM apps? I'm doing a lot of TypeScript+WebGL work right now, and though TS is fairly nice, my use case requires being aware of not allocating too many new objects frequently, and that kind of control would be easier in something like C++ or Rust. I've been thinking of hacking together a small test project with WASM+WebGL to see what it's like, but I get the sense it might still be more hassle than it's worth to use in production. Currently I can easily set breakpoints in my TS code, I can see how much memory is allocated by which functions, how much time is spent in each function, etc. very easily. If there's a way to do these kinds of things with WASM in another language, that would be fantastic.

echeese 7y ago
The tools are still being worked on but the Chrome team made a pretty big step by adding DWARF support to the debugger: https://twitter.com/ChromeDevTools/status/1192803818024710145 https://twitter.com/ChromeDevTools/status/119280381802471014... EDIT: Here's an article from yesterday about this: https://developers.google.com/web/updates/2019/12/webassembly https://developers.google.com/web/updates/2019/12/webassembl...

utf985 7y ago

I'm interested in how will WebAssembly affect the functionality of browser addons such as ad and script blockers?

dm33tri 7y ago

What I'm thrilled to see is an optimization of binary sizes in compilers and libraries. Maybe <1MB native apps will become common (or few MB of code for single webpage will become standard)

shiado 7y ago

Does anybody know the state of the art for wasm tooling? I have used emscripten but are there any excellent 'higher level' tools? The worst part was writing the interface between the wasm and JS.

Crontab 7y ago

This sounds interesting, but personally, I am worried that this will just turn into yet another browser technology that will be used to abuse and track users. I really hope I am wrong.

deleted 7y ago

[deleted]

batterystd 7y ago

So what was webassemnly until now?

chx 7y ago

How's the DOM manipulation coming along?

smattiso 7y ago

Good. Javascript needs to die. It was far simpler to build performant multi-device UIs 15 years ago than it is today. Building UIs natively on iOS and Android is so much simpler than building for the web. Technical question: 1.) What is the speed of WebAssembly on iOS WebKit and Android WebView? 2.) Is it feasible to write an entire app UI in something like Qt and target WebAssembly? 3.) Android, iOS, Windows versions of the app are Qt apps natively or possibly through the device's WebKit. Is this possible today? Is there a better UI library than Qt for this?

MuffinFlavored 7y ago
> Building UIs natively on iOS and Android is so much simpler than building for the web. I can get lit-element with no build process going to prototype something in a single .html file in probably 30 seconds. I don't think XCode/iOS developers can compete with the simplicity. Define initial state, alter it through events, pull data through fetch(), write HTML. I know for a fact iOS development isn't that simple.
- saagarjha 7y ago
  Swift Playgrounds, when they work, can compete with that somewhat.

arghwhat 7y ago

W3C endorsing it has nothing at all to do with whether or not it is here to stay.

dang 7y ago

The submitted title was "It's official, WebAssembly is here to stay". That broke the site guidelines by editorializing. Please don't do that.

mrandish 7y ago

Does WebAssembly threaten app store business models by allowing devs to distribute apps directly via browser (thereby saving the app store 'tax')? For example, if Adobe delivers its new mobile Photoshop directly via iPad Safari will Apple have a way of 'nerfing' WebAssembly to stop them?

nojvek 7y ago

The design goals of WebAssembly are the following: Fast, safe, and portable semantics: * Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware. * Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches. * Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally. * Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike. * Language-independent: does not privilege any particular language, programming model, or object model. * Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments. * Open: programs can interoperate with their environment in a simple and universal manner. Efficient and portable representation: * Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats. * Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately. * Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation. * Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen. * Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks. * Portable: makes no architectural assumptions that are not broadly supported across modern hardware. If webassembly is truly able to meet this goals, together with good debugging and tools, it will become the the universal way to represent computation across devices and platforms. Really cool.

skunkworker 7y ago
Two of the most exciting applications I've come across so far are allowing for in-browser audio encoding with a provided encoder and distributing WASM binaries to run on edge servers. About 5 years ago I tried to use an optimized javascript file to encode some audio in browser before uploading, it was painfully slow and very hardware intensive. But using wasm in the vmsg [1], it distributes the LAME encoder allowing for in-browser MP3 encoding. And secondly cloudflare allows for their workers to be written in WASM, allowing for more processor intensive apps (like resizing an image) to be completely on the edge. I see it as eventually fulfilling the portability goals that java applets in the browsers use to have, but instead of one you have many companies agreeing on the implementation. [1] https://github.com/Kagami/vmsg https://github.com/Kagami/vmsg [2] https://blog.cloudflare.com/webassembly-on-cloudflare-workers/ https://blog.cloudflare.com/webassembly-on-cloudflare-worker...

apatheticonion 7y ago