18 ms·

Compiling to WebAssembly: It’s Happening

306 points by mnemonik 11y ago

jokoon 11y ago
So does it just do what NaCL was already doing, or at least is the objective the same? I'm more worried about more specific things like hardware access (GPU, mouse inputs, networking, windowing) It seems wasm runs at native speeds and take full advantage of optimization, but can it really be a solution fits all? There must be some things wasm can't do. And so far, since JS did almost everything, I don't see the point of wasm if it can't do what other language can.
- azakai 11y ago
  The main difference is that NaCl used a plugin API (PPAPI). WebAssembly, like asm.js, can access JavaScript, and so it has indirect access to DOM APIs, with no new powers over the existing web. The main point of wasm, from my perspective, is startup speed. wasm will allow much smaller downloads of large codebases, and much faster parsing (due to the binary format). For small programs this might not matter, but for big ones, it's a huge deal.
vvanders 11y ago
Exciting stuff. Just further solidifies in my mind that C/C++ is one of the few languages that will run everywhere.
tuyguntn 11y ago
Does this mean anyone can write Python to wasm converter then run it on browser, looks like LLVM backend?
- amirouche 11y ago
  It's more like CPython to wasm or http://pypyjs.org/ http://pypyjs.org/ -> wasm
- klodolph 11y ago
  Someone could write a "PyWasm". You could then ship your Python code as a wasm blob, but you'd have to include all of the standard library parts which you use, which are probably significant. The library could be a separate resource, so clients can cache it separately.
c0nfused 11y ago
Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. I always feel like the most obvious use for it is to start writing truly hateful and abusive code. I'm sure this is because I'm getting old.
- nwah1 11y ago
  The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.
  - klodolph 11y ago
    I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your Fortran code, and mix it into a C program, run from a Bourne shell, running in terminal emulator written in C and a WM written in Lisp. You can replace any part with a part written in a different language. JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.
    - nostrademons 11y ago
      Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those that the frameworks were written in. There's a reason that C became the dominant language during the 80s and early 90s: it's because Win32, UNIX, and MacOS >=7 were all written in it. That's a large part of what Worse is Better was about. Richard Gabriel founded a company to write software for Lisp Machines, pivoted it to run Lisp on commodity hardware, found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business. The renaissance for other languages was really during the web era, when everything just spit out HTML and it didn't matter what the server was written in. Once customers started demanding rich interactivity on the client, there was a strong incentive to write everything in Javascript, and then a strong incentive to write the servers in Javascript too, and then a strong incentive to use Javascript for other things like native apps and IoT devices too.
saosebastiao 11y ago
Does anybody know if there are plans for an API for garbage collection? The WASM spec as it currently exists seems to be only useful for non-GC languages, and it would be a shame if we ended up shipping a new GC implementation for every page that we load. Perhaps something that would allow compilers to tap into the native JS GC?
- swolchok 11y ago
  What would the GC scan? What do pointers look like? At the assembly layer, you have the flexibility to not have a C runtime (and therefore no C stack), and you might be doing fun things like having tagged pointers that the GC would have to know about. In short, the WASM layer is IMO the wrong layer for GC. I think the closest-layered applicable solution is caching & pinning guarantees for common libraries, which may already be addressed by the same solutions for common JS libraries (use a common CDN & let the browser caching keep it pinned).
  - icebraining 11y ago
    The GC would scan whatever the program told it to scan, by using its API, like the Boehm GC library: https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector I think it only makes sense, seeing as interaction with the native JS VM will be inevitable for a long time.
    - Arelius 11y ago
      Perhaps then you should just use the Boehm GC library then.
- kevingadd 11y ago
  There are long term plans for a GC rooting API that will let you interact with the JS heap and the DOM, yes.
- plaguuuuuu 11y ago
  Could see languages/libraries with auto pointers and stuff getting more popular.
jacobolus 11y ago
Is there (or are there any plans to add) a WebAssembly -> asm.js compiler, so that I can write some code by hand in WebAssembly and still get it to run fast in old browsers? Or are there features of WebAssembly that would be impossible to add in asm.js? The reason I ask is that asm.js is really painful and cumbersome to write by hand and wasm seems substantially nicer, but I only have small bits of numerical hot loops which I want to use wasm/asm.js for, and I have no desire to bring a bunch of code written in C into my little project.
- erickt 11y ago
  Yes there is. That's the wasm2asm project Alon mentioned in the post.
  - jacobolus 11y ago
    Whoops, I read right past that line. :-) Thanks, I’ll take a look. For anyone interested, the code is in wasm2asm.h: https://github.com/WebAssembly/binaryen/blob/master/src/wasm2asm.h https://github.com/WebAssembly/binaryen/blob/master/src/wasm...
- azakai 11y ago
  I agree asm.js isn't fun to write by hand, but wasm is also primarily a compiler target. You might not necessarily find it easier to write (its text format isn't defined or even sketched out yet, so it's impossible to guess). If you just want to compile a few small functions with hot loops, it might be easiest to write them in C, and use a new option in emscripten that makes it easy to get just the output from those functions (no libc, no runtime support, etc.), see https://gist.github.com/kripken/910bfe8524bdaeb7df9a https://gist.github.com/kripken/910bfe8524bdaeb7df9a and https://gist.github.com/wycats/4845049dcf0f6571387a https://gist.github.com/wycats/4845049dcf0f6571387a
  - jacobolus 11y ago
    Both of the proposed syntaxes I’ve seen for wasm text format (an s-expression syntax and a C-like syntax) seem pretty nice. The sexp format in particular seems like it would be a great target for simple bits of purpose-specific code generation (for code that doesn’t need a “compiler” per se).
eecks 11y ago
WebAssembly lets people write in C++, Ruby, Python, etc and for that code to work in the browser like Javascript does at the moment. Am I correct?
- purplerabbit 11y ago
  Yes, that's correct.
  - jokoon 11y ago
    What about opengl and hardware inputs for instance? What kind of standard libraries will be available ?
    - kevingadd 11y ago
      WebAssembly will (with a few small exceptions) use existing web APIs.
- Klathmon 11y ago
  Yes, but it is a very limited subset of the whole "web ecosystem". In its first version, it will not be able to access any/most web APIs directly (so you won't be writing a web app in 100% C++ any time soon). The goal is to allow "Computationally intensive" bits of code to be compiled, while leaving JS to act as the glue for it all.
- azakai 11y ago
  Mostly. The initial target is C++ and similar languages, and it will not have DOM access, but using suitable libraries (libc, SDL, etc., for example emscripten's) you can write a normal C++ program and have it run in the browser. You can also run Ruby and Python in the browser by just compiling their C or C++ VMs. But that won't still work "like JavaScript" - their objects won't be native VM objects in the browser, it won't use the browser's GC, they won't be observable in the browser's debugger, etc. So far all of that was already possible, and done, with asm.js. In the future, it is a goal to work to do GC object integration, so that something like Ruby or Python could actually compile down to something with native VM objects, and that would also allow calling DOM APIs directly. (This will likely still require a compiled VM, though.)
wilg 11y ago
Does code written in WebAssembly have access to the DOM somehow? How will that work?
- Klathmon 11y ago
  In the current proposal there is no way for WebAssembly to directly access the DOM (or any other "Web API" objects). Basically you will need to drop back down into javascript and handle that there (basically how asm.js does it now). But there is a proposal to eventually integrate direct DOM access into Web Assembly, but that's for after they get it up and running.
  - mozumder 11y ago
    If they wanted to do it right, then an HTTP requests itself should serve a compiled HTML binary based on an AST. The binary version of HTML.
    - deleted 11y ago
      [deleted]
    - jcfrei 11y ago
      I would consider that the worst scenario. If each website was its own binary application it would undo the open source aspect of websites (even though that's only partly true today due to all the obscured javascript). But maybe that would actually be desirable for all companies which rely on advertising revenue and want to prevent any modification of their web content (such as removal of ads). It'll be interesting to see how the web develops in the future. WebAssembly definitely seems to give more control to the author.
      - mozumder 11y ago
        Just because it's a binary AST doesn't mean it's closed.
    - skissane 11y ago
wilg 11y ago
In the recent press tour about Swift, Apple seems to be really gung-ho about people using Swift everywhere. Since Swift is built on LLVM and there's direct LLVM support for WebAssembly, I wonder if Apple will get behind WebAssembly so they can get Swift in the browser.
- bobajeff 11y ago
  If I'm not mistaken Webkit is implementing experimental WebAssembly support. It appears to be the only implementation being worked on upstream out of all the major browser engines right now.
klodolph 11y ago
This seems like the modern trend, and I like it. I'm going to compare this to the recent developments with OpenGL and Vulkan. With OpenGL, you ship textual source code for your shaders written in GLSL, and you have to hope that the compiler on your client's machine does the right thing! With Vulkan and SPIR-V, the compiler is taken out of the equation, and you can use whatever language you want to write shaders, validate them ahead of time, and ship the validated binary blobs to the client. Incidentally, I'm looking forward to WebGL 2. I really miss being able to use texture arrays, integers, and instancing.
yoavm 11y ago
I suspect too many web applications are going use WebAssembly to obscure their code and the way they work, thus making it impossible to learn by studying their code. As someone who learned programming mostly by looking at other people's code, I'm afraid the web will change in a way that would make it a lot harder to do so.
- icholy 11y ago
  Do you really read other people's minified/obfuscated js?
  - yoavm 11y ago
    It was far less common to minify JS code when I started doing that, but yeah, even now I much rather have minified JS code than no code at all.
    - MichaelGG 11y ago
      So decompile or disassemble WebAssembly?
- m0dc 11y ago
  Being able to view source is a design goal of WebAssembly, according to [0]. If an organization doesn't want you reading their JS, there are already plenty of tools to make it nearly impossible as-is. Do you really learn anything from reading minified, obfuscated code? At some point you're just reverse engineering, which is obviously still possible with WebAssembly. 'Open source by default' is a problem to be solved at a cultural level, not a technical one. [0] https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
- shurcooL 11y ago
  Basically, you took it for granted that web had source as the binary, unlike the rest of the world (native binaries are not the source). You'll still be able to find and read source of open source web projects, like like you can for open source non-web projects. > 'Open source by default' is a problem to be solved at a cultural level, not a technical one. Highly agree.
geon 11y ago
Is there any progress on making the compilers utilize the js gc instead of including their own entire runtime?
- kevingadd 11y ago
  This is largely blocked by the ecmascript committee's incredible slowness in introducing key features like Weak References, but it will happen eventually.
shurcooL 11y ago
I'm very interested in compiling Go to WebAssembly. Based on what I read, it seems that so far you can primarily try it with C/C++ code. If one were to build a Go -> WebAssembly compiler, what are good routes to take? I can see there's going to be multiple possibilities.
- frame_perfect 11y ago
  Will be a huge pain in the ass. Go's compiler uses Plan 9, and WebAssembly uses LLVM.
  - adrusi 11y ago
    There is llgo[1] which is an implementation of go on top of the llvm toolchain. But if I'm not mistaken, WebAssembly won't accept just any llvm bitcode. It's similar to how emscripten will work with the bitcode that clang outputs, but not other llvm compilers like rust or ghc. [1]: http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT
etiene 11y ago
YES YES YES!!! OMG! THANK YOU <3 <3 <3 I've been waiting so long for this! Maybe my dream of running native Lua on the browser will come true? Will I already be able to run Lua's interpreter now? :D :D Gonna look deeper into this as soon as I have time, omg so excited <3
- corysama 11y ago
  The Lua interpreter was one of the earliest test cases for the C++ to JS compiler. https://kripken.github.io/lua.vm.js/lua.vm.js.html https://kripken.github.io/lua.vm.js/lua.vm.js.html
  - etiene 11y ago
    ohh!! I know this project! I thought it had nothing to do with web assembly, thank you for the heads up
n00b101 11y ago
So the current toolchain involves using emscripten to generate asm.js and then using binaryen to convert asm.js to WebAssembly. Unfortunately emscripten depends on a fork of LLVM (FastComp), with no plans for a proper LLVM asm.js backend. Are there plans for a properly WebAssembly LLVM backend that does not depend on forking LLVM (like emscripten)?
- kevingadd 11y ago
  WebAssembly's LLVM backend is currently under development in LLVM trunk by multiple people.
- sunfish 11y ago
  Yes: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/WebAssembly/ http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/We...
al2o3cr 11y ago
WebAssembly sounds interesting, you could use it to write little apps that embed into a page. And call them "applets". Nobody's ever done that before, right? :trollface:
kalsk 11y ago
This sounds like an odd question, but I honestly need somebody to explain this to me...what is the motivation behind the modern trend to put everything on the web? Is there something you get by running your program from a browser that you don't get from downloading and running an elf or a text file, or is this entire trend based around appealing to users who don't actually know how to use their computers?
- simcop2387 11y ago
  You get a largely cross platform, consistent UI that can easily talk to outside services without being configured. All of these things help make the application work consistently across the many devices that exist now (Computers, smart phones, tablets, mp3 players, refrigerators[1], etc.) so you really can develop once and deploy everywhere. It also does seriously help the users that don't know how to use their refrigerator[2] so they can look up recipies and plan shopping trips. [1] http://www.digitalafro.com/samsung-smart-fridge-serves-up-recipe-ideas-and-coupons/ http://www.digitalafro.com/samsung-smart-fridge-serves-up-re... [2] https://productforums.google.com/forum/#!topic/calendar/UhfpcwO0X0c https://productforums.google.com/forum/#!topic/calendar/Uhfp...
- 1ris 11y ago
  It's the current fad. But nothing new. Since the beginning of computing the tides go from thin-clients and fat-clients back and forth. Currently fat-clients are en-vouge.
  - sangnoir 11y ago
    And here I was thinking (mobile) apps were the current fad.
  - TeMPOraL 11y ago
    Are they? The current trend is to have everything done server-side, thus making sure the users get minimum value possible out of software they use.
- vasco 11y ago
  You want to reach as many people as you can, and nowadays people are pretty proficient with using a browser to go to a web page. If you can reduce the number of steps between you and your users, I'd say that's a good thing. Right now that can mean putting everything on the web, in the future, who knows.
iandanforth 11y ago
My experience is that the barrier to entry for JavaScript is not that it's a new language, but that you have to learn async thinking and are restricted to a single thread. Does WebAssembly address either of those points?
- amelius 11y ago
  Regarding threads, I don't think so. And even if they would address threads, then there's still the problem of a shared address space between threads to be solved, and the implementation of mutexes, etc.
tevlon84 11y ago
Hi Alon, thank you for sharing. I am a Computer Science Master student and i would like to contribute to the development. The git looks really full and i don`t know where to start.
- azakai 11y ago
  Which area were you interested to contribute to? For Binaryen specifically, this bug could be a good starting point: https://github.com/WebAssembly/binaryen/issues/2 https://github.com/WebAssembly/binaryen/issues/2 Other issues in the tracker there as well. Bigger topics are to make progress on wasm2asm, and to start an implementation of the current binary format (link is in the design repo), which Binaryen needs to support.
  - tevlon84 11y ago
    ok. Thanks, i'll have a look.
ajarmst 11y ago
I'm sorry, but I'm not following. What's the problem this is supposed to solve?
hDeraj 11y ago
I see WebAssembly this way: WebAssembly is to JavaScript what WebGL is to Canvas
mei0Iesh 11y ago
Finally! Maybe now someone can build a web app that enhances the reading and discover of documents. Each browser could be a repository of text files, each with an address, so you can have words in the text pointing to another document's address.
andrewchambers 11y ago
Web browsers are turning into giant, poorly designed operating systems. My current operating system can already run binaries, this is reinventing the wheel in a massively over engineered way.
- gnuvince 11y ago
  And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but rather getting a packaging system that is cross-platform and easy for users to use. My own preference would be something based off of Nix so that you can avoid many problems related to library versions and whatnot, but anything where a user could be pretty much guaranteed that if he clicks "install", he'll be able to use his application in the next couple of minutes.
  - andrewchambers 11y ago
    I think you are right, this is a high technical debt solution for letting lay persons install software more easily. App stores already did a pretty good job at this anyway, and have the added benefit of curation. The number of layers of in our software stacks grow faster than Moore's law can handle.
    - zurn 11y ago
      Mobile app stores are junkyards with terrible discoverability and they have a captive audience.
    - pcwalton 11y ago
      > App stores already did a pretty good job at this anyway Then why isn't the Mac App Store (to name an example) a runaway success?
currentoor 11y ago
I'm hoping for a day where I get two threads in my JS runtime. Now that would be nice...
exabrial 11y ago
Cool, but why not just use, you know, Java bytecode? Existing toolchains, compilers, runtimes, virtual machines could all be reused I'm sure. Actually there are a hundred different great virtual machines that could be used... Why, yet, another?
- stephen_g 11y ago
  All the compiler backend/code generation is using LLVM, and the VMs are all pre-existing (JavaScript with some extensions), so there is a huge amount of existing code being used here.

306 points by mnemonik 11y ago

So does it just do what NaCL was already doing, or at least is the objective the same? I'm more worried about more specific things like hardware access (GPU, mouse inputs, networking, windowing) It seems wasm runs at native speeds and take full advantage of optimization, but can it really be a solution fits all? There must be some things wasm can't do. And so far, since JS did almost everything, I don't see the point of wasm if it can't do what other language can.

azakai 11y ago
The main difference is that NaCl used a plugin API (PPAPI). WebAssembly, like asm.js, can access JavaScript, and so it has indirect access to DOM APIs, with no new powers over the existing web. The main point of wasm, from my perspective, is startup speed. wasm will allow much smaller downloads of large codebases, and much faster parsing (due to the binary format). For small programs this might not matter, but for big ones, it's a huge deal.

vvanders 11y ago

Exciting stuff. Just further solidifies in my mind that C/C++ is one of the few languages that will run everywhere.

tuyguntn 11y ago

Does this mean anyone can write Python to wasm converter then run it on browser, looks like LLVM backend?

amirouche 11y ago
It's more like CPython to wasm or http://pypyjs.org/ http://pypyjs.org/ -> wasm
klodolph 11y ago
Someone could write a "PyWasm". You could then ship your Python code as a wasm blob, but you'd have to include all of the standard library parts which you use, which are probably significant. The library could be a separate resource, so clients can cache it separately.

c0nfused 11y ago

Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. I always feel like the most obvious use for it is to start writing truly hateful and abusive code. I'm sure this is because I'm getting old.

nwah1 11y ago
The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.
- klodolph 11y ago
  I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your Fortran code, and mix it into a C program, run from a Bourne shell, running in terminal emulator written in C and a WM written in Lisp. You can replace any part with a part written in a different language. JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.
  - nostrademons 11y ago
    Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those that the frameworks were written in. There's a reason that C became the dominant language during the 80s and early 90s: it's because Win32, UNIX, and MacOS >=7 were all written in it. That's a large part of what Worse is Better was about. Richard Gabriel founded a company to write software for Lisp Machines, pivoted it to run Lisp on commodity hardware, found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business. The renaissance for other languages was really during the web era, when everything just spit out HTML and it didn't matter what the server was written in. Once customers started demanding rich interactivity on the client, there was a strong incentive to write everything in Javascript, and then a strong incentive to write the servers in Javascript too, and then a strong incentive to use Javascript for other things like native apps and IoT devices too.

saosebastiao 11y ago

Does anybody know if there are plans for an API for garbage collection? The WASM spec as it currently exists seems to be only useful for non-GC languages, and it would be a shame if we ended up shipping a new GC implementation for every page that we load. Perhaps something that would allow compilers to tap into the native JS GC?

swolchok 11y ago
What would the GC scan? What do pointers look like? At the assembly layer, you have the flexibility to not have a C runtime (and therefore no C stack), and you might be doing fun things like having tagged pointers that the GC would have to know about. In short, the WASM layer is IMO the wrong layer for GC. I think the closest-layered applicable solution is caching & pinning guarantees for common libraries, which may already be addressed by the same solutions for common JS libraries (use a common CDN & let the browser caching keep it pinned).
- icebraining 11y ago
  The GC would scan whatever the program told it to scan, by using its API, like the Boehm GC library: https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector I think it only makes sense, seeing as interaction with the native JS VM will be inevitable for a long time.
  - Arelius 11y ago
    Perhaps then you should just use the Boehm GC library then.
kevingadd 11y ago
There are long term plans for a GC rooting API that will let you interact with the JS heap and the DOM, yes.
plaguuuuuu 11y ago
Could see languages/libraries with auto pointers and stuff getting more popular.

jacobolus 11y ago

Is there (or are there any plans to add) a WebAssembly -> asm.js compiler, so that I can write some code by hand in WebAssembly and still get it to run fast in old browsers? Or are there features of WebAssembly that would be impossible to add in asm.js? The reason I ask is that asm.js is really painful and cumbersome to write by hand and wasm seems substantially nicer, but I only have small bits of numerical hot loops which I want to use wasm/asm.js for, and I have no desire to bring a bunch of code written in C into my little project.

erickt 11y ago
Yes there is. That's the wasm2asm project Alon mentioned in the post.
- jacobolus 11y ago
  Whoops, I read right past that line. :-) Thanks, I’ll take a look. For anyone interested, the code is in wasm2asm.h: https://github.com/WebAssembly/binaryen/blob/master/src/wasm2asm.h https://github.com/WebAssembly/binaryen/blob/master/src/wasm...
azakai 11y ago
I agree asm.js isn't fun to write by hand, but wasm is also primarily a compiler target. You might not necessarily find it easier to write (its text format isn't defined or even sketched out yet, so it's impossible to guess). If you just want to compile a few small functions with hot loops, it might be easiest to write them in C, and use a new option in emscripten that makes it easy to get just the output from those functions (no libc, no runtime support, etc.), see https://gist.github.com/kripken/910bfe8524bdaeb7df9a https://gist.github.com/kripken/910bfe8524bdaeb7df9a and https://gist.github.com/wycats/4845049dcf0f6571387a https://gist.github.com/wycats/4845049dcf0f6571387a
- jacobolus 11y ago
  Both of the proposed syntaxes I’ve seen for wasm text format (an s-expression syntax and a C-like syntax) seem pretty nice. The sexp format in particular seems like it would be a great target for simple bits of purpose-specific code generation (for code that doesn’t need a “compiler” per se).

eecks 11y ago

WebAssembly lets people write in C++, Ruby, Python, etc and for that code to work in the browser like Javascript does at the moment. Am I correct?

purplerabbit 11y ago
Yes, that's correct.
- jokoon 11y ago
  What about opengl and hardware inputs for instance? What kind of standard libraries will be available ?
  - kevingadd 11y ago
    WebAssembly will (with a few small exceptions) use existing web APIs.
Klathmon 11y ago
Yes, but it is a very limited subset of the whole "web ecosystem". In its first version, it will not be able to access any/most web APIs directly (so you won't be writing a web app in 100% C++ any time soon). The goal is to allow "Computationally intensive" bits of code to be compiled, while leaving JS to act as the glue for it all.
azakai 11y ago
Mostly. The initial target is C++ and similar languages, and it will not have DOM access, but using suitable libraries (libc, SDL, etc., for example emscripten's) you can write a normal C++ program and have it run in the browser. You can also run Ruby and Python in the browser by just compiling their C or C++ VMs. But that won't still work "like JavaScript" - their objects won't be native VM objects in the browser, it won't use the browser's GC, they won't be observable in the browser's debugger, etc. So far all of that was already possible, and done, with asm.js. In the future, it is a goal to work to do GC object integration, so that something like Ruby or Python could actually compile down to something with native VM objects, and that would also allow calling DOM APIs directly. (This will likely still require a compiled VM, though.)

wilg 11y ago

Does code written in WebAssembly have access to the DOM somehow? How will that work?

Klathmon 11y ago
In the current proposal there is no way for WebAssembly to directly access the DOM (or any other "Web API" objects). Basically you will need to drop back down into javascript and handle that there (basically how asm.js does it now). But there is a proposal to eventually integrate direct DOM access into Web Assembly, but that's for after they get it up and running.
- mozumder 11y ago
  If they wanted to do it right, then an HTTP requests itself should serve a compiled HTML binary based on an AST. The binary version of HTML.
  - deleted 11y ago
    [deleted]
  - jcfrei 11y ago
    I would consider that the worst scenario. If each website was its own binary application it would undo the open source aspect of websites (even though that's only partly true today due to all the obscured javascript). But maybe that would actually be desirable for all companies which rely on advertising revenue and want to prevent any modification of their web content (such as removal of ads). It'll be interesting to see how the web develops in the future. WebAssembly definitely seems to give more control to the author.
    - mozumder 11y ago
      Just because it's a binary AST doesn't mean it's closed.
  - skissane 11y ago

wilg 11y ago

In the recent press tour about Swift, Apple seems to be really gung-ho about people using Swift everywhere. Since Swift is built on LLVM and there's direct LLVM support for WebAssembly, I wonder if Apple will get behind WebAssembly so they can get Swift in the browser.

bobajeff 11y ago
If I'm not mistaken Webkit is implementing experimental WebAssembly support. It appears to be the only implementation being worked on upstream out of all the major browser engines right now.

klodolph 11y ago

This seems like the modern trend, and I like it. I'm going to compare this to the recent developments with OpenGL and Vulkan. With OpenGL, you ship textual source code for your shaders written in GLSL, and you have to hope that the compiler on your client's machine does the right thing! With Vulkan and SPIR-V, the compiler is taken out of the equation, and you can use whatever language you want to write shaders, validate them ahead of time, and ship the validated binary blobs to the client. Incidentally, I'm looking forward to WebGL 2. I really miss being able to use texture arrays, integers, and instancing.

yoavm 11y ago

I suspect too many web applications are going use WebAssembly to obscure their code and the way they work, thus making it impossible to learn by studying their code. As someone who learned programming mostly by looking at other people's code, I'm afraid the web will change in a way that would make it a lot harder to do so.

icholy 11y ago
Do you really read other people's minified/obfuscated js?
- yoavm 11y ago
  It was far less common to minify JS code when I started doing that, but yeah, even now I much rather have minified JS code than no code at all.
  - MichaelGG 11y ago
    So decompile or disassemble WebAssembly?
m0dc 11y ago
Being able to view source is a design goal of WebAssembly, according to [0]. If an organization doesn't want you reading their JS, there are already plenty of tools to make it nearly impossible as-is. Do you really learn anything from reading minified, obfuscated code? At some point you're just reverse engineering, which is obviously still possible with WebAssembly. 'Open source by default' is a problem to be solved at a cultural level, not a technical one. [0] https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
shurcooL 11y ago
Basically, you took it for granted that web had source as the binary, unlike the rest of the world (native binaries are not the source). You'll still be able to find and read source of open source web projects, like like you can for open source non-web projects. > 'Open source by default' is a problem to be solved at a cultural level, not a technical one. Highly agree.

geon 11y ago

Is there any progress on making the compilers utilize the js gc instead of including their own entire runtime?

kevingadd 11y ago
This is largely blocked by the ecmascript committee's incredible slowness in introducing key features like Weak References, but it will happen eventually.

shurcooL 11y ago

I'm very interested in compiling Go to WebAssembly. Based on what I read, it seems that so far you can primarily try it with C/C++ code. If one were to build a Go -> WebAssembly compiler, what are good routes to take? I can see there's going to be multiple possibilities.

frame_perfect 11y ago
Will be a huge pain in the ass. Go's compiler uses Plan 9, and WebAssembly uses LLVM.
- adrusi 11y ago
  There is llgo[1] which is an implementation of go on top of the llvm toolchain. But if I'm not mistaken, WebAssembly won't accept just any llvm bitcode. It's similar to how emscripten will work with the bitcode that clang outputs, but not other llvm compilers like rust or ghc. [1]: http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT

etiene 11y ago

YES YES YES!!! OMG! THANK YOU <3 <3 <3 I've been waiting so long for this! Maybe my dream of running native Lua on the browser will come true? Will I already be able to run Lua's interpreter now? :D :D Gonna look deeper into this as soon as I have time, omg so excited <3

corysama 11y ago
The Lua interpreter was one of the earliest test cases for the C++ to JS compiler. https://kripken.github.io/lua.vm.js/lua.vm.js.html https://kripken.github.io/lua.vm.js/lua.vm.js.html
- etiene 11y ago
  ohh!! I know this project! I thought it had nothing to do with web assembly, thank you for the heads up

n00b101 11y ago

So the current toolchain involves using emscripten to generate asm.js and then using binaryen to convert asm.js to WebAssembly. Unfortunately emscripten depends on a fork of LLVM (FastComp), with no plans for a proper LLVM asm.js backend. Are there plans for a properly WebAssembly LLVM backend that does not depend on forking LLVM (like emscripten)?

kevingadd 11y ago
WebAssembly's LLVM backend is currently under development in LLVM trunk by multiple people.
sunfish 11y ago
Yes: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/WebAssembly/ http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/We...

al2o3cr 11y ago

WebAssembly sounds interesting, you could use it to write little apps that embed into a page. And call them "applets". Nobody's ever done that before, right? :trollface:

kalsk 11y ago

This sounds like an odd question, but I honestly need somebody to explain this to me...what is the motivation behind the modern trend to put everything on the web? Is there something you get by running your program from a browser that you don't get from downloading and running an elf or a text file, or is this entire trend based around appealing to users who don't actually know how to use their computers?

simcop2387 11y ago
You get a largely cross platform, consistent UI that can easily talk to outside services without being configured. All of these things help make the application work consistently across the many devices that exist now (Computers, smart phones, tablets, mp3 players, refrigerators[1], etc.) so you really can develop once and deploy everywhere. It also does seriously help the users that don't know how to use their refrigerator[2] so they can look up recipies and plan shopping trips. [1] http://www.digitalafro.com/samsung-smart-fridge-serves-up-recipe-ideas-and-coupons/ http://www.digitalafro.com/samsung-smart-fridge-serves-up-re... [2] https://productforums.google.com/forum/#!topic/calendar/UhfpcwO0X0c https://productforums.google.com/forum/#!topic/calendar/Uhfp...
1ris 11y ago
It's the current fad. But nothing new. Since the beginning of computing the tides go from thin-clients and fat-clients back and forth. Currently fat-clients are en-vouge.
- sangnoir 11y ago
  And here I was thinking (mobile) apps were the current fad.
- TeMPOraL 11y ago
  Are they? The current trend is to have everything done server-side, thus making sure the users get minimum value possible out of software they use.
vasco 11y ago
You want to reach as many people as you can, and nowadays people are pretty proficient with using a browser to go to a web page. If you can reduce the number of steps between you and your users, I'd say that's a good thing. Right now that can mean putting everything on the web, in the future, who knows.

iandanforth 11y ago

My experience is that the barrier to entry for JavaScript is not that it's a new language, but that you have to learn async thinking and are restricted to a single thread. Does WebAssembly address either of those points?

amelius 11y ago
Regarding threads, I don't think so. And even if they would address threads, then there's still the problem of a shared address space between threads to be solved, and the implementation of mutexes, etc.

tevlon84 11y ago

Hi Alon, thank you for sharing. I am a Computer Science Master student and i would like to contribute to the development. The git looks really full and i don`t know where to start.

azakai 11y ago
Which area were you interested to contribute to? For Binaryen specifically, this bug could be a good starting point: https://github.com/WebAssembly/binaryen/issues/2 https://github.com/WebAssembly/binaryen/issues/2 Other issues in the tracker there as well. Bigger topics are to make progress on wasm2asm, and to start an implementation of the current binary format (link is in the design repo), which Binaryen needs to support.
- tevlon84 11y ago
  ok. Thanks, i'll have a look.

ajarmst 11y ago

I'm sorry, but I'm not following. What's the problem this is supposed to solve?

hDeraj 11y ago

I see WebAssembly this way: WebAssembly is to JavaScript what WebGL is to Canvas

mei0Iesh 11y ago

Finally! Maybe now someone can build a web app that enhances the reading and discover of documents. Each browser could be a repository of text files, each with an address, so you can have words in the text pointing to another document's address.

andrewchambers 11y ago

Web browsers are turning into giant, poorly designed operating systems. My current operating system can already run binaries, this is reinventing the wheel in a massively over engineered way.

gnuvince 11y ago
And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but rather getting a packaging system that is cross-platform and easy for users to use. My own preference would be something based off of Nix so that you can avoid many problems related to library versions and whatnot, but anything where a user could be pretty much guaranteed that if he clicks "install", he'll be able to use his application in the next couple of minutes.
- andrewchambers 11y ago
  I think you are right, this is a high technical debt solution for letting lay persons install software more easily. App stores already did a pretty good job at this anyway, and have the added benefit of curation. The number of layers of in our software stacks grow faster than Moore's law can handle.
  - zurn 11y ago
    Mobile app stores are junkyards with terrible discoverability and they have a captive audience.
  - pcwalton 11y ago
    > App stores already did a pretty good job at this anyway Then why isn't the Mac App Store (to name an example) a runaway success?

currentoor 11y ago

I'm hoping for a day where I get two threads in my JS runtime. Now that would be nice...

exabrial 11y ago

Cool, but why not just use, you know, Java bytecode? Existing toolchains, compilers, runtimes, virtual machines could all be reused I'm sure. Actually there are a hundred different great virtual machines that could be used... Why, yet, another?

stephen_g 11y ago
All the compiler backend/code generation is using LLVM, and the VMs are all pre-existing (JavaScript with some extensions), so there is a huge amount of existing code being used here.