WebAssembly support now shipping in all major browsers

Post by pjmlp » Tue, Nov 14, 2017, 1:29 PM UTC

tonyg wrote: post #78

pjmlp wrote: post #56

Earlier quoted context omitted.

I think it would still be possible to implement Scheme with the current specification, which is on my snowy weekends to do list for the upcoming Winter. How far I would get before losing interest or facing those issues, I don't know.

It's possible , yes, but it isn't possible to do particularly efficiently. If you want separate compilation, it gets even worse. (Separate compilation is where proper tail calls come in very handy.)

Post by wtetzner » Tue, Nov 14, 2017, 1:29 PM UTC

steveklabnik wrote: post #25

amelius wrote: post #6

Earlier quoted context omitted.

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.

Post by taf2 » Tue, Nov 14, 2017, 1:34 PM UTC

tzahola wrote: post #104

etatoby wrote: post #91

Great. We will soon have an entire JVM running inside each browser's tab, just to run an animated slider. Maybe even more than one. Plus a .NET VM, several Python and Ruby interpreters, and so on. Because webmasters will keep loading ready-made plugins from CDNs, exactly like they are doing now, except that the new generation of web software will carry their own interpreter or runtime with them, because the developer…

I'd like to interject for a moment here, and pitch my idea about what I call the "Web 4.0". It's basically a binary equivalent of HTML, without the many inconveniences of HTML for content providers. Web 4.0 pages are obfuscated WebAssembly payloads, that draw their contents via WebGL. This way, adblocking becomes impossible, as the actual content and ads are within the same opaque WebGL framebuffer. Stealing copyrigh…

Post by indescions_2017 » Tue, Nov 14, 2017, 1:40 PM UTC

KeitIG wrote: post #34

A good occasion to watch Gary Bernhardt's talk "The Birth & Death of JavaScript" [0] again, where he talks about the precursor of WebAssembly: asm.js and the future implication it "could" have in the future in a really humorous way. A few years old but still relevant. You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure. [0] https://www.destroyallsoftware.com/talks/the-birth-and…

Post by scaryclam » Tue, Nov 14, 2017, 1:41 PM UTC

jazoom wrote: post #44

phkahler wrote: post #38

Earlier quoted context omitted.

Red herring. People install or explicitly download code they want to run. The general public doesn't even realize that most web pages are full of code (js not html) and most developers have gotten so used to it they feel entitled. The goal should be to try harder to use less code, not enable native execution. I understand, engineers like to think about what is possible (wouldn't it be cool if..!) but sometime they ne…

99%+ of people don't think like you and don't care about the distinction between code on the browser and code on the OS. "A red herring is something that misleads or distracts from a relevant or important issue. It may be either a logical fallacy or a literary device that leads readers or audiences towards a false conclusion." I don't see how my comment is a red herring. Computers are for running code. That's what th…