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.
WebAssembly support now shipping in all major browsers
21–30 of 346 posts
Re: WebAssembly support now shipping in all major browsers
#22Unfortunately 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…
Re: WebAssembly support now shipping in all major browsers
#23Java 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 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
#24Earlier 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.
Re: WebAssembly support now shipping in all major browsers
#25Ok, 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.
"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
#26Earlier 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/
Re: WebAssembly support now shipping in all major browsers
#27Earlier 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.
Re: WebAssembly support now shipping in all major browsers
#28Earlier 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.
Re: WebAssembly support now shipping in all major browsers
#29Earlier 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.
Re: WebAssembly support now shipping in all major browsers
#30Earlier 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.