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.<p>I always feel like the most obvious use for it is to start writing truly hateful and abusive code.<p>I'm sure this is because I'm getting old.
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.
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.
In the recent press tour about Swift, Apple seems to be really gung-ho about people using Swift everywhere.<p>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.
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?<p>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.
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 <i>everything</i> 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?
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?
So does it just do what NaCL was already doing, or at least is the objective the same?<p>I'm more worried about more specific things like hardware access (GPU, mouse inputs, networking, windowing)<p>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.
Hi Alon,<p>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.
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.<p>Are there plans for a properly WebAssembly LLVM backend that does not depend on forking LLVM (like emscripten)?
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.<p>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.
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?
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.<p>Does WebAssembly address either of those points?
WebAssembly sounds interesting, you could use it to write little apps that embed into a page.<p>And call them "applets". Nobody's ever done that before, right? :trollface:
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.
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.
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