13 ms·

Bringing the web up to speed with WebAssembly

167 points by yugoja 9y ago

austincheney 9y ago
WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Everything running from WASM is in an isolated sandbox. For obvious security reasons this isn't likely to change.
- hdhzy 9y ago
  > Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. I disagree. Flash could draw things without interacting with DOM thorough JS. Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong aim to compile C/C++ for the web, so you don't need to rewrite anything.
  - ChrisSD 9y ago
    There are various drawing surfaces on the web that don't involve interacting with the DOM (canvas, webgl, etc). I'm not sure what you mean about the IDE? Webassembly won't restrict what source language you use so you'll be able to use any IDE that supports your chosen language. And that would include Flash and its tools if someone writes a compiler.
    - hdhzy 9y ago
      I mean Flash had a dedicated IDE. WebAssembly can be compared to ABC (ActionScript Bytecode) not to Flash.
  - drdrey 9y ago
    WebAssembly is a compilation target (like JVM Bytecode). You need an IDE for the source language, not the target.
    - panopticon 9y ago
      That's his/her point; they were trying to point out why Flash and WebAssembly aren't analogous.. Flash was a cohesive toolchain; not a build target.
    - hdhzy 9y ago
      Exactly. So the patent can compare WebAssembly to ActionScript byte code or swf binary format not to Flash.
- yaantc 9y ago
  > ..., to the web And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, which are not in the WA scope. But for some embedded use cases this is not a blocker: the API is there at the C level, one just need to expose it to the WA runtime (which could be automated, see SWIG and the like). A secure format, with some strong backers and high performance open source implementations has a lot of potential. I'm very curious about the footprint of the loader/compiler/runtime: it should be ok for most Linux embedded systems, but how low-end could it go as a secure ISA agnostic code distribution system? For your second point, JavaScript is also sandboxed. On principle, there is no reason that in time the API offered to JS today won't become available to the WA runtime in the future --- although I've no idea if there's any actual work along those lines, I don't follow web front-end tech too closely.
  - austincheney 9y ago
    > For your second point, JavaScript is also sandboxed. There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on.... To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO. WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.
    - ChrisSD 9y ago
      Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc. See the design documents: https://github.com/WebAssembly/design/blob/master/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...
- markdog12 9y ago
  > Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently. http://webassembly.org/docs/future-features/ http://webassembly.org/docs/future-features/
  - austincheney 9y ago
    I did not see native DOM interaction in that document and the thing it linked to is 404.
    - jfbastien 9y ago
      Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat... It now links to here: https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079 The person maintaining that mirror went back to grad school, I'll see who maintains it now. Apologies for the 404.
- vvanders 9y ago
  Well anything that lets me run Lua in the browser[1] is cool by me ;). But yeah, interop is something that you can't just hand-wave away. It needs to be done carefully and with the right semantics and performance. That said I think we well get there and for a certain limited use cases it's already there. [1] https://github.com/vvanders/wasm_lua https://github.com/vvanders/wasm_lua
  - Zelizz 9y ago
    Oh man, with Lua in the browser, I'd actually start to write web stuff again. And we could get a really nice fast port of Love2D running!
    - vvanders 9y ago
      Yeah, probably wouldn't be too hard. I've got Lua things drawing to an HTML5 canvas that runs at 60 FPS on a private project. As long as you don't make 1000's of calls per frame it runs pretty well.
- ams6110 9y ago
  > more secure Is it? How do we know? The attack surface in browsers is huge.
  - jfbastien 9y ago
    A few ways that come to mind: 1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript"). 2. The code is all new, as opposed to what I hear is a hard-to-maintain older codebase which wasn't designed with security in mind. 3. It's very static in that memory accesses are pretty easy to bounds check for the compiler. Implementation-wise there's plenty of interesting things that can be done to tighten security of WebAssembly.
    - AnIdiotOnTheNet 9y ago
      And how long do you think that'll last? As developers stubbornly persist in trying to make desktop applications on the web, they'll demand more and more access to the host, and browser developers will give it to them in an effort to one-up each other. If anyone had actually cared about security on the web we wouldn't be where we are now.
      - jfbastien 9y ago
        Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/
        kuschku 9y ago
        That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG. And we already have a bluetooth stack for the web, USB drivers in JS, etc.
        9y ago
- krapp 9y ago
  >Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are going to open. The sandbox only makes it more attractive.
  - txdv 9y ago
    Yeah, I wonder why OP thinks that the sandbox is bad. Yes, you won't be able to use the filesystem and other std stuff, but you want to do browser stuff in the browser, like creating websockets and coloring your dom nodes in various colors
umamimc 9y ago
My worry is, does this make it easier for the big companies to silo the internet more completely? From a developer POV with regard to performance, this seems great, but from the standpoint of open communication, it seems problematic.
- gsnedders 9y ago
  It doesn't make it any easier than minified, obfuscated JS.
  - jerf 9y ago
    Out of curiosity, is there anybody in the last couple of years who would say that reading the source of websites was a significant component of their learning the web? (By "significant", I don't mean "primary" but I do mean more than "I once popped open a bit of source and found a method I didn't know existed".) Even in 1997, I was using free documentation, not reading websites, which even before minification and such were still often quite ugly to read.
sulizilxia 9y ago
I wonder how this will affect Java in the long term. In the comments about the JDK9 release, there was discussion about the JVM becoming a sort of language-agnostic platform where Java is a small part. It seems WebAssembly is occupying a lot of the same space, but from a sort of opposite direction (in the sense of providing the compilation target first). Java and the JVM obviously aren't going anywhere soon, but the history of javascript, node.js, etc. leads me to suspect WebAssembly could displace the JVM in the long term.
- austincheney 9y ago
  Java is a language. It comes with a standard VM, compile mechanism, and bytecode. Fortunately, the Java platform is well segmented so that the language is a separate technology from those other pieces. Scala, for example, is a language different from Java, but still targets the compile mechanism and JVM. WebAssembly, by contrast, is not a language. It is only a bytecode and conforming container. Java could compile to WebAssembly instead of its standard bytecode and the biggest difference is execution environment. In order for WebAssembly to displace the JVM it would have to run where the JVM can run with appropriate levels of support.
  - sulizilxia 9y ago
    I was a little unclear about this, but I meant Java in the broad sense of the Java ecosystem, including the JVM and the language. I was mostly wondering if languages will move toward WebAssembly as a target instead of the JVM, and what consequences that will have. On the other hand, maybe I had Java the language in mind unconsciously at some level. You're right that you could have Java targeting WebAssembly instead of its standard bytecode, which I hadn't thought about. At least now, it seems like the JVM offers some stuff that WebAssembly doesn't, but I have a hunch it won't stay that way in the long run. There's been a lot of good discussion here about WebAssembly versus the JVM; it seems like lots of people have similar thoughts about this topic.
- kodablah 9y ago
  In many ways, the JVM bytecode is a superset of WASM. That's why I wrote https://github.com/cretz/asmble https://github.com/cretz/asmble.
whoisthemachine 9y ago
WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and verified?) by browsers 2. "Web apps" could potentially go away - leaving web browsers for what they were intended, document sharing
- zach43 9y ago
  I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems. If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?
  - baq 9y ago
    If you google around, you'll find that POCs exist - qt apps on the browser in canvas tags. Accessibility nightmare but otherwise a dream come true in the so called enterprise. Can't wait for this tech to mature a bit more.
  - jfbastien 9y ago
    In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.
flavio81 9y ago
I love Webassembly, because It will eventually remove Javascript's dominance from the web for good.
- revmoo 9y ago
  Not a chance. Also WebAssembly doesn't really replace JS. If anything it will sit alongside it.
- golemotron 9y ago
  Eich's support is poetic.
- primeblue 9y ago
  This is a brilliant result, make this toy broken language compete
bnolsen 9y ago
AKA how to bring more advertising and tracking crap to your browser...I really do hope it's not that.
pedrocr 9y ago
We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?
- jfbastien 9y ago
  Same organizations, different people, and enough time to experiment with (read: suffer pains from) things like asm.js and PNaCl for those people to agree that something like WebAssembly was a good idea.
- fasquoika 9y ago
  >We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. Technologically speaking, this has been possible since the days of p-code. The browser vendors have only just decided that it's something that's actually beneficial
  - always_good 9y ago
    It's also been possible since Javascript.
- gwbas1c 9y ago
  It's called the CLR. (Common language runtime, which is what C# runs on.) The problem is that the CLR forces you into a "one-size-fits-all" garbage collector. It's good for what it does, but if your application needs are different, than the CLR just won't work.
  - pedrocr 9y ago
    There are plenty of VMs out there, the JVM and CLR being the biggest two. Up to now though none were usable on the web.
revmoo 9y ago
I've been a programmer for at least a decade and I understood nothing in this article. Very excited about the concept of being able to write C and compile it down to WebAssembly though.
TheAceOfHearts 9y ago
I was a bit skeptical of WebAssembly when it started popping up, but reading through this and the MDN docs has made me get a bit more excited. In a few years WebAssembly might make for a great environment to learn about lower level programming. I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything. What's the reasonable thing to do when a grow-memory instruction returns -1? How are people using WebAssembly? Are there high-quality polyfills available for older browsers? How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?
- jfbastien 9y ago
  > What's the reasonable thing to do when a grow-memory instruction returns -1? A good assumption is that your WebAssembly binary already has an implementation of malloc which calls grow_memory. It should do something sane, and you shouldn't need to worry: it's similar to having mmap fail on other platforms. What do you do when mmap fail? I usually just give up and abort, but in rare cases I'll do other fancy things. > Are there high-quality polyfills available for older browsers? Work had started in 2015 for a solid polyfill, but now all major browser vendors have shipped WebAssembly so that work wasn't seen as necessary anymore. > How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.? Not that satisfying an answer, but https://github.com/WebAssembly/design/blob/master/FeatureTest.md https://github.com/WebAssembly/design/blob/master/FeatureTes...
- avaer 9y ago
  > I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything. Well... modern assembly is monstrously complex. Probably more so than your favorite high level programming language. Modern assembly is generally not a bare minimum, because it's designed to give compilers the interface to run code fast, not to be easy to program by people. And WebAssembly is a bit of a misnomer since it's not quite your processor's assembly; it's designed to be assembled fast on the client side, while also being memory-safe. Ironically that makes it simpler than actual assembly.
khana 9y ago
"WebAssembly addresses the problem of safe, fast, portable low-level code on the Web" Bad idea. The beauty of HTML/css/js semantics is lost.
grondilu 9y ago
This is probably hand-waving but : instead of implementing threads directly into the WebAssembly language, would it make sense to compile a known micro-kernel to WebAssembly and then compile the C standard library (which, IIRC, implements threads)?
- AnIdiotOnTheNet 9y ago
  Yes. Let's combine the renowned safety of the C standard library with the speed and efficiency of a web browser!
- Rusky 9y ago
  This wouldn't help at all. Kernels (micro or no) can only implement preemption with the help of hardware timers (and, if you want parallelism, hardware cores), which Webassembly cannot access. (The C library does not implement threads; it merely wraps the kernel's implementation of them.) So at some level WebAssembly itself must provide some sort of primitive for threading, or else at best you'll get cooperative coroutines/an event loop.
  - deleted 9y ago
    [deleted]
- gwbas1c 9y ago
  I'd rather see something like async/await before true threads. So much of web programming is network IO bound; that what we really need are primitives that make async programming easier. Threads can come later. The problem is that when async programming is hard due to language or framework difficulties, threads are the easier choice. But then, older code is locked into patterns that are hard to refactor to async/await.
batmansmk 9y ago
Yet, almost one year after its release, nobody makes money directly or indirectly with wasm... despite the beauty of its engineering, I'm starting to worry. Who will continue funding it if nobody uses it?
- tannhaeuser 9y ago
  Exactly. WASM stories always bring up wild fantasies of platform world domination, when in reality there aren't APIs for even the most basic things, let alone practical apps. In a heretical way, I've got to ask why not just use JVM byte codes, an incomparably more established platform at this point with several mature VMs and sophisticated API ecosystem, albeit not necessarily in the graphics space? Why did we want to rid browsers of Java in the first place just to start all over with it?
  - Rusky 9y ago
    Java doesn't provide a sufficient security model for running arbitrary C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all the new use cases will just go back to asm.js instead.
    - pjmlp 9y ago
      Sure it does, https://github.com/graalvm/sulong https://github.com/graalvm/sulong http://dl.acm.org/citation.cfm?id=3132204 http://dl.acm.org/citation.cfm?id=3132204
      - Rusky 9y ago
        That's... not Java or the JVM providing the security model. It's impressive but it's not a comparable solution to WebAssembly.
- ern 9y ago
  It hasn’t got a big installed base yet[1], so it’s hard to justify the investment. Also, remember that experience with Applets/Flash/Silverlight has burned developers, and probably made them fearful. I expect that once a big player makes a move, momentum will build. [1]https://caniuse.com/#search=Wasm https://caniuse.com/#search=Wasm
Animats 9y ago
I suspect that the use cases for WebAssembly will be something like this: - < 10% user-beneficial compute in the browser - 60% ad and tracking obfuscation - 20% annoying scrolling and transitions - 10% hostile code
- justinpombrio 9y ago
  That's about the breakdown for Javascript too, right?
  - Animats 9y ago
    Probably, but only the first use case needs more performance.
- CaptSpify 9y ago
  It's frustrating to watch because it feels like we've learned nothing from the past 10+ years of web development.
  - primeblue 9y ago
    We've learned JavaScript is a toy
- userbinator 9y ago
  Add DRM to the 60% and I'd agree.
- na85 9y ago
  Can't be overstated. Web assembly is going to be a disaster for users in the long run. The helpless feeling as a bunch of people actively destroy the web for no reason other than that it's more convenient for them is so frustrating.
dang 9y ago
Url changed from https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/ https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s..., which points to this. acolyer.org's glosses on papers are excellent and I like reading them myself, but sometimes it's a bit of a struggle knowing where to situate them on HN given the original source rule (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html). Edit: changed my mind. Like I said, a bit of a struggle.
- krallja 9y ago
  I think you made a good choice: acolyer.org posts provide enough additional analysis, comparisons to previous posts, and meta-commentary to stand on their own.
primeblue 9y ago
JavaScript is so 2015, long live C++
Asdfbla 9y ago
Really interesting paper. When I first heard about what WebAssembly was trying to achieve, I naively wondered why people didn't just slap some existing interpreter for bytecode into browsers (JVM, .NET, maybe even adapt LLVM?) and go with that. I knew people had been burned by Java applets, but I was still curious why they invented something new again instead of possibly adapting existing stuff. Of course I accepted that they surely had some good reasons for doing it the way they did, but the paper has some interesting specific points in favor of the Webassembly and against existing stuff like the JVM (easier verification of the bytecode etc.).
dangjc 9y ago
Webassembly is incredibly hard to debug in the browser. Source maps give you a decent stack trace, but you can't evaluate variables. I'm hoping this situation improves.
haberman 9y ago
> nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future. I did not realize that the design was this ambitious! I wonder how lightweight a standalone implementation could be, while still getting competitive performance.

167 points by yugoja 9y ago

WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Everything running from WASM is in an isolated sandbox. For obvious security reasons this isn't likely to change.

hdhzy 9y ago
> Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. I disagree. Flash could draw things without interacting with DOM thorough JS. Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong aim to compile C/C++ for the web, so you don't need to rewrite anything.
- ChrisSD 9y ago
  There are various drawing surfaces on the web that don't involve interacting with the DOM (canvas, webgl, etc). I'm not sure what you mean about the IDE? Webassembly won't restrict what source language you use so you'll be able to use any IDE that supports your chosen language. And that would include Flash and its tools if someone writes a compiler.
  - hdhzy 9y ago
    I mean Flash had a dedicated IDE. WebAssembly can be compared to ABC (ActionScript Bytecode) not to Flash.
- drdrey 9y ago
  WebAssembly is a compilation target (like JVM Bytecode). You need an IDE for the source language, not the target.
  - panopticon 9y ago
    That's his/her point; they were trying to point out why Flash and WebAssembly aren't analogous.. Flash was a cohesive toolchain; not a build target.
  - hdhzy 9y ago
    Exactly. So the patent can compare WebAssembly to ActionScript byte code or swf binary format not to Flash.
yaantc 9y ago
> ..., to the web And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, which are not in the WA scope. But for some embedded use cases this is not a blocker: the API is there at the C level, one just need to expose it to the WA runtime (which could be automated, see SWIG and the like). A secure format, with some strong backers and high performance open source implementations has a lot of potential. I'm very curious about the footprint of the loader/compiler/runtime: it should be ok for most Linux embedded systems, but how low-end could it go as a secure ISA agnostic code distribution system? For your second point, JavaScript is also sandboxed. On principle, there is no reason that in time the API offered to JS today won't become available to the WA runtime in the future --- although I've no idea if there's any actual work along those lines, I don't follow web front-end tech too closely.
- austincheney 9y ago
  > For your second point, JavaScript is also sandboxed. There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on.... To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO. WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.
  - ChrisSD 9y ago
    Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc. See the design documents: https://github.com/WebAssembly/design/blob/master/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...
markdog12 9y ago
> Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently. http://webassembly.org/docs/future-features/ http://webassembly.org/docs/future-features/
- austincheney 9y ago
  I did not see native DOM interaction in that document and the thing it linked to is 404.
  - jfbastien 9y ago
    Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat... It now links to here: https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079 The person maintaining that mirror went back to grad school, I'll see who maintains it now. Apologies for the 404.
vvanders 9y ago
Well anything that lets me run Lua in the browser[1] is cool by me ;). But yeah, interop is something that you can't just hand-wave away. It needs to be done carefully and with the right semantics and performance. That said I think we well get there and for a certain limited use cases it's already there. [1] https://github.com/vvanders/wasm_lua https://github.com/vvanders/wasm_lua
- Zelizz 9y ago
  Oh man, with Lua in the browser, I'd actually start to write web stuff again. And we could get a really nice fast port of Love2D running!
  - vvanders 9y ago
    Yeah, probably wouldn't be too hard. I've got Lua things drawing to an HTML5 canvas that runs at 60 FPS on a private project. As long as you don't make 1000's of calls per frame it runs pretty well.
ams6110 9y ago
> more secure Is it? How do we know? The attack surface in browsers is huge.
- jfbastien 9y ago
  A few ways that come to mind: 1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript"). 2. The code is all new, as opposed to what I hear is a hard-to-maintain older codebase which wasn't designed with security in mind. 3. It's very static in that memory accesses are pretty easy to bounds check for the compiler. Implementation-wise there's plenty of interesting things that can be done to tighten security of WebAssembly.
  - AnIdiotOnTheNet 9y ago
    And how long do you think that'll last? As developers stubbornly persist in trying to make desktop applications on the web, they'll demand more and more access to the host, and browser developers will give it to them in an effort to one-up each other. If anyone had actually cared about security on the web we wouldn't be where we are now.
    - jfbastien 9y ago
      Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/
      - kuschku 9y ago
        That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG. And we already have a bluetooth stack for the web, USB drivers in JS, etc.
        9y ago
krapp 9y ago
>Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are going to open. The sandbox only makes it more attractive.
- txdv 9y ago
  Yeah, I wonder why OP thinks that the sandbox is bad. Yes, you won't be able to use the filesystem and other std stuff, but you want to do browser stuff in the browser, like creating websockets and coloring your dom nodes in various colors

umamimc 9y ago

My worry is, does this make it easier for the big companies to silo the internet more completely? From a developer POV with regard to performance, this seems great, but from the standpoint of open communication, it seems problematic.

gsnedders 9y ago
It doesn't make it any easier than minified, obfuscated JS.
- jerf 9y ago
  Out of curiosity, is there anybody in the last couple of years who would say that reading the source of websites was a significant component of their learning the web? (By "significant", I don't mean "primary" but I do mean more than "I once popped open a bit of source and found a method I didn't know existed".) Even in 1997, I was using free documentation, not reading websites, which even before minification and such were still often quite ugly to read.

sulizilxia 9y ago

I wonder how this will affect Java in the long term. In the comments about the JDK9 release, there was discussion about the JVM becoming a sort of language-agnostic platform where Java is a small part. It seems WebAssembly is occupying a lot of the same space, but from a sort of opposite direction (in the sense of providing the compilation target first). Java and the JVM obviously aren't going anywhere soon, but the history of javascript, node.js, etc. leads me to suspect WebAssembly could displace the JVM in the long term.

austincheney 9y ago
Java is a language. It comes with a standard VM, compile mechanism, and bytecode. Fortunately, the Java platform is well segmented so that the language is a separate technology from those other pieces. Scala, for example, is a language different from Java, but still targets the compile mechanism and JVM. WebAssembly, by contrast, is not a language. It is only a bytecode and conforming container. Java could compile to WebAssembly instead of its standard bytecode and the biggest difference is execution environment. In order for WebAssembly to displace the JVM it would have to run where the JVM can run with appropriate levels of support.
- sulizilxia 9y ago
  I was a little unclear about this, but I meant Java in the broad sense of the Java ecosystem, including the JVM and the language. I was mostly wondering if languages will move toward WebAssembly as a target instead of the JVM, and what consequences that will have. On the other hand, maybe I had Java the language in mind unconsciously at some level. You're right that you could have Java targeting WebAssembly instead of its standard bytecode, which I hadn't thought about. At least now, it seems like the JVM offers some stuff that WebAssembly doesn't, but I have a hunch it won't stay that way in the long run. There's been a lot of good discussion here about WebAssembly versus the JVM; it seems like lots of people have similar thoughts about this topic.
kodablah 9y ago
In many ways, the JVM bytecode is a superset of WASM. That's why I wrote https://github.com/cretz/asmble https://github.com/cretz/asmble.

whoisthemachine 9y ago

WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and verified?) by browsers 2. "Web apps" could potentially go away - leaving web browsers for what they were intended, document sharing

zach43 9y ago
I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems. If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?
- baq 9y ago
  If you google around, you'll find that POCs exist - qt apps on the browser in canvas tags. Accessibility nightmare but otherwise a dream come true in the so called enterprise. Can't wait for this tech to mature a bit more.
- jfbastien 9y ago
  In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.

flavio81 9y ago

I love Webassembly, because It will eventually remove Javascript's dominance from the web for good.

revmoo 9y ago
Not a chance. Also WebAssembly doesn't really replace JS. If anything it will sit alongside it.
golemotron 9y ago
Eich's support is poetic.
primeblue 9y ago
This is a brilliant result, make this toy broken language compete

bnolsen 9y ago

AKA how to bring more advertising and tracking crap to your browser...I really do hope it's not that.

pedrocr 9y ago

We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?

jfbastien 9y ago
Same organizations, different people, and enough time to experiment with (read: suffer pains from) things like asm.js and PNaCl for those people to agree that something like WebAssembly was a good idea.
fasquoika 9y ago
>We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. Technologically speaking, this has been possible since the days of p-code. The browser vendors have only just decided that it's something that's actually beneficial
- always_good 9y ago
  It's also been possible since Javascript.
gwbas1c 9y ago
It's called the CLR. (Common language runtime, which is what C# runs on.) The problem is that the CLR forces you into a "one-size-fits-all" garbage collector. It's good for what it does, but if your application needs are different, than the CLR just won't work.
- pedrocr 9y ago
  There are plenty of VMs out there, the JVM and CLR being the biggest two. Up to now though none were usable on the web.

revmoo 9y ago

I've been a programmer for at least a decade and I understood nothing in this article. Very excited about the concept of being able to write C and compile it down to WebAssembly though.

TheAceOfHearts 9y ago

I was a bit skeptical of WebAssembly when it started popping up, but reading through this and the MDN docs has made me get a bit more excited. In a few years WebAssembly might make for a great environment to learn about lower level programming. I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything. What's the reasonable thing to do when a grow-memory instruction returns -1? How are people using WebAssembly? Are there high-quality polyfills available for older browsers? How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?

jfbastien 9y ago
> What's the reasonable thing to do when a grow-memory instruction returns -1? A good assumption is that your WebAssembly binary already has an implementation of malloc which calls grow_memory. It should do something sane, and you shouldn't need to worry: it's similar to having mmap fail on other platforms. What do you do when mmap fail? I usually just give up and abort, but in rare cases I'll do other fancy things. > Are there high-quality polyfills available for older browsers? Work had started in 2015 for a solid polyfill, but now all major browser vendors have shipped WebAssembly so that work wasn't seen as necessary anymore. > How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.? Not that satisfying an answer, but https://github.com/WebAssembly/design/blob/master/FeatureTest.md https://github.com/WebAssembly/design/blob/master/FeatureTes...
avaer 9y ago
> I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything. Well... modern assembly is monstrously complex. Probably more so than your favorite high level programming language. Modern assembly is generally not a bare minimum, because it's designed to give compilers the interface to run code fast, not to be easy to program by people. And WebAssembly is a bit of a misnomer since it's not quite your processor's assembly; it's designed to be assembled fast on the client side, while also being memory-safe. Ironically that makes it simpler than actual assembly.

khana 9y ago

"WebAssembly addresses the problem of safe, fast, portable low-level code on the Web" Bad idea. The beauty of HTML/css/js semantics is lost.

grondilu 9y ago

This is probably hand-waving but : instead of implementing threads directly into the WebAssembly language, would it make sense to compile a known micro-kernel to WebAssembly and then compile the C standard library (which, IIRC, implements threads)?

AnIdiotOnTheNet 9y ago
Yes. Let's combine the renowned safety of the C standard library with the speed and efficiency of a web browser!
Rusky 9y ago
This wouldn't help at all. Kernels (micro or no) can only implement preemption with the help of hardware timers (and, if you want parallelism, hardware cores), which Webassembly cannot access. (The C library does not implement threads; it merely wraps the kernel's implementation of them.) So at some level WebAssembly itself must provide some sort of primitive for threading, or else at best you'll get cooperative coroutines/an event loop.
- deleted 9y ago
  [deleted]
gwbas1c 9y ago
I'd rather see something like async/await before true threads. So much of web programming is network IO bound; that what we really need are primitives that make async programming easier. Threads can come later. The problem is that when async programming is hard due to language or framework difficulties, threads are the easier choice. But then, older code is locked into patterns that are hard to refactor to async/await.

batmansmk 9y ago

Yet, almost one year after its release, nobody makes money directly or indirectly with wasm... despite the beauty of its engineering, I'm starting to worry. Who will continue funding it if nobody uses it?

tannhaeuser 9y ago
Exactly. WASM stories always bring up wild fantasies of platform world domination, when in reality there aren't APIs for even the most basic things, let alone practical apps. In a heretical way, I've got to ask why not just use JVM byte codes, an incomparably more established platform at this point with several mature VMs and sophisticated API ecosystem, albeit not necessarily in the graphics space? Why did we want to rid browsers of Java in the first place just to start all over with it?
- Rusky 9y ago
  Java doesn't provide a sufficient security model for running arbitrary C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all the new use cases will just go back to asm.js instead.
  - pjmlp 9y ago
    Sure it does, https://github.com/graalvm/sulong https://github.com/graalvm/sulong http://dl.acm.org/citation.cfm?id=3132204 http://dl.acm.org/citation.cfm?id=3132204
    - Rusky 9y ago
      That's... not Java or the JVM providing the security model. It's impressive but it's not a comparable solution to WebAssembly.
ern 9y ago
It hasn’t got a big installed base yet[1], so it’s hard to justify the investment. Also, remember that experience with Applets/Flash/Silverlight has burned developers, and probably made them fearful. I expect that once a big player makes a move, momentum will build. [1]https://caniuse.com/#search=Wasm https://caniuse.com/#search=Wasm

Animats 9y ago

I suspect that the use cases for WebAssembly will be something like this: - < 10% user-beneficial compute in the browser - 60% ad and tracking obfuscation - 20% annoying scrolling and transitions - 10% hostile code

justinpombrio 9y ago
That's about the breakdown for Javascript too, right?
- Animats 9y ago
  Probably, but only the first use case needs more performance.
CaptSpify 9y ago
It's frustrating to watch because it feels like we've learned nothing from the past 10+ years of web development.
- primeblue 9y ago
  We've learned JavaScript is a toy
userbinator 9y ago
Add DRM to the 60% and I'd agree.
na85 9y ago
Can't be overstated. Web assembly is going to be a disaster for users in the long run. The helpless feeling as a bunch of people actively destroy the web for no reason other than that it's more convenient for them is so frustrating.

dang 9y ago

Url changed from https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/ https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s..., which points to this. acolyer.org's glosses on papers are excellent and I like reading them myself, but sometimes it's a bit of a struggle knowing where to situate them on HN given the original source rule (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html). Edit: changed my mind. Like I said, a bit of a struggle.

krallja 9y ago
I think you made a good choice: acolyer.org posts provide enough additional analysis, comparisons to previous posts, and meta-commentary to stand on their own.

primeblue 9y ago

JavaScript is so 2015, long live C++

Asdfbla 9y ago

Really interesting paper. When I first heard about what WebAssembly was trying to achieve, I naively wondered why people didn't just slap some existing interpreter for bytecode into browsers (JVM, .NET, maybe even adapt LLVM?) and go with that. I knew people had been burned by Java applets, but I was still curious why they invented something new again instead of possibly adapting existing stuff. Of course I accepted that they surely had some good reasons for doing it the way they did, but the paper has some interesting specific points in favor of the Webassembly and against existing stuff like the JVM (easier verification of the bytecode etc.).

dangjc 9y ago

Webassembly is incredibly hard to debug in the browser. Source maps give you a decent stack trace, but you can't evaluate variables. I'm hoping this situation improves.

haberman 9y ago

> nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future. I did not realize that the design was this ambitious! I wonder how lightweight a standalone implementation could be, while still getting competitive performance.