Live data from Hacker News

Compiling to WebAssembly: It’s Happening

hacks.mozilla.org

11–20 of 225 posts

Re: Compiling to WebAssembly: It’s Happening

#11
post #3

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.

The main use for it (for me at least) is to write fast numerical code (physics modeling, audio processing, image processing, machine learning, 3D rendering, statistical analysis, etc.) in a deterministically fast way against an easy-to-reason-about programming model with an ability to manually allocate memory and structure data, instead of hoping that every browser’s heuristic-driven JIT will be able to optimize some high-level code the same way.

Most of the program logic can remain standard Javascript, but the little kernels of hot numerical code can be much more effectively optimized.

This gives Javascript/browsers the ability to handle problems which were previously only possible to tackle with native C programs.

Re: Compiling to WebAssembly: It’s Happening

#12

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?

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

Re: Compiling to WebAssembly: It’s Happening

#13
post #10

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 loop…

Yes there is. That's the wasm2asm project Alon mentioned in the post.

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/wasm...

Re: Compiling to WebAssembly: It’s Happening

#14
post #6
post #3

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.

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.

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.

Re: Compiling to WebAssembly: It’s Happening

#17
post #3

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.

What makes WebAssembly like Flash? Please elaborate.

You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse.

The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force you to write code in Lisp, or if you wanted to write in C you would get end up with a bit of a nightmare on your hands. The Lisp machines were beautiful and integrated and the source code was everywhere, but they weren't for everybody, and in the end it was the diversity of Windows, Unix, and Mac OS that replaced them.

WebAssembly is Unix, JavaScript is a Lisp machine.

Re: Compiling to WebAssembly: It’s Happening

#18
post #15

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?

Yes, that's correct.

What about opengl and hardware inputs for instance? What kind of standard libraries will be available ?

Re: Compiling to WebAssembly: It’s Happening

#19
post #2

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

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.

Re: Compiling to WebAssembly: It’s Happening

#20

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?

There are long term plans for a GC rooting API that will let you interact with the JS heap and the DOM, yes.
Post reply on HN