Live data from Hacker News

WebAssembly support now shipping in all major browsers

blog.mozilla.org

21–30 of 346 posts

Re: WebAssembly support now shipping in all major browsers

#21

Can't wait for DOM interop and get away from JS on frontend. Seriously JS should not be the lingua franca of the web :)

>> Seriously JS should not be the lingua franca of the web But neither should this. Really, keep your code off my computer as much as possible.

I think it's darkly humorous that I have to install browser plugins to stop sites from mining monero in my browser. It's like websites are those creepy spider things in the Matrix, except instead of sticking humans in pods to harvest their biochemical energy, they're just running up our home electricity bills by maxing our CPUs.

Re: WebAssembly support now shipping in all major browsers

#22

Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not havi…

My understanding is that SIMD support has a proposal that most people are happy with, and will be landing in 2018.

Re: WebAssembly support now shipping in all major browsers

#23
post #15
post #7

Java applets 2.0, we are back to square one, yet again. People don't learn. The web dev community have just managed to force browsermakers to unify web development on browser side JS, and throw Java applets, activex, and action script to the bucket, just to have a kind of JVM being made a part of the web standard, and forced upon us yet again.

There are some clear and defining differences between Java applets and webassembly. The core problems with Java were that the security sucked, and that applets were non-native and didn't use the dom. I doubt there is any desire in web developers to overuse canvasses and do layout in wasm, and the security model should hopefully be as successful as JS's has been over the years.

> The core problems with Java were that the security sucked

The core problem with Java applets was that they were Java applets

An option to keep the source of the web app closed will fragment the web dev community yet again.

Re: WebAssembly support now shipping in all major browsers

#24
post #17

Earlier quoted context omitted.

Seems to be on the roadmap: http://webassembly.org/docs/future-features/

Good to see. By the way, we also need multithreading and shared memory to efficiently support structurally shared immutable data structures across multiple cores.

Shared memory is part of the threading tracking issue.

Re: WebAssembly support now shipping in all major browsers

#25
post #6
post #2

Ok, now we need GC and DOM interop. Because reinventing layouts is pain.

In order to port other languages (Haskell, Go, Python) to target WASM, we definitely need the possibility of writing a GC in WASM. But to build an efficient GC, we need multithreading and synchronization/memory barrier primitives.

You can already compile your language's runtime to wasm; this includes the GC. The downsides is that now you're adding all that to your binary size.

"GC support" means being able to integrate with JS's GC, basically, so that your language's wasm runtime could use it instead of your own, saving bytes.

Re: WebAssembly support now shipping in all major browsers

#26
post #19
post #3

Earlier quoted context omitted.

IIRC you can do GC within WebAssembly (though it's less nice and awkward as I've been told). But DOM interop is needed. Can't wait to get my fingers on the DOM via native C code :)

It doesn't sound like that will be possible. DOM interop is baked into the Garbage Collection task[0]. It sounds like there's a dependency there, somewhere. [0]: https://github.com/WebAssembly/design/issues/1079 edit: Scratch all of that above. I stand corrected. Here's the DOM proposal: https://github.com/WebAssembly/host-bindings/

Historically, people have thought that the GC and DOM stuff is intertwined, but the latest DOM proposal doesn't require the GC proposal.

Re: WebAssembly support now shipping in all major browsers

#27
post #21

Earlier quoted context omitted.

>> Seriously JS should not be the lingua franca of the web But neither should this. Really, keep your code off my computer as much as possible.

I think it's darkly humorous that I have to install browser plugins to stop sites from mining monero in my browser. It's like websites are those creepy spider things in the Matrix, except instead of sticking humans in pods to harvest their biochemical energy, they're just running up our home electricity bills by maxing our CPUs.

What plugins do you recommend for this?

Re: WebAssembly support now shipping in all major browsers

#28
post #19

Earlier quoted context omitted.

It doesn't sound like that will be possible. DOM interop is baked into the Garbage Collection task[0]. It sounds like there's a dependency there, somewhere. [0]: https://github.com/WebAssembly/design/issues/1079 edit: Scratch all of that above. I stand corrected. Here's the DOM proposal: https://github.com/WebAssembly/host-bindings/

Historically, people have thought that the GC and DOM stuff is intertwined, but the latest DOM proposal doesn't require the GC proposal.

Do you have a link to the separated proposals? It certainly seems entwined on the official roadmap.

Re: WebAssembly support now shipping in all major browsers

#29
post #28

Earlier quoted context omitted.

Historically, people have thought that the GC and DOM stuff is intertwined, but the latest DOM proposal doesn't require the GC proposal.

Do you have a link to the separated proposals? It certainly seems entwined on the official roadmap.

https://github.com/WebAssembly/host-bindings/

Re: WebAssembly support now shipping in all major browsers

#30
post #23
post #15

Earlier quoted context omitted.

There are some clear and defining differences between Java applets and webassembly. The core problems with Java were that the security sucked, and that applets were non-native and didn't use the dom. I doubt there is any desire in web developers to overuse canvasses and do layout in wasm, and the security model should hopefully be as successful as JS's has been over the years.

> The core problems with Java were that the security sucked The core problem with Java applets was that they were Java applets An option to keep the source of the web app closed will fragment the web dev community yet again.

That option is about the same as it is today: you can access it, but it will be hard to follow. Just like minified Javascript.
Post reply on HN