Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Interface Types: Interoperate with All the Things

hacks.mozilla.org

Post reply on HN
Print view View original

51–60 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#51

Post by the8472 »

icebraining wrote: post #43
the8472 wrote: post #37

Earlier quoted context omitted.

> At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win? That stuff only works if you limit yourself to exclusively run in a wasm runtime. If you want to compile to any other platform you still need C glue code.

If you're distributing an executable (not a library), you can just AOT compile the generated wasm to machine code. For example, the WasmExplorer already lets you compile C++ -> wasm -> x86 assembly: https://mbebenita.github.io/WasmExplorer/?state=%7B%22option...

I doubt you get the same performance as direct compilation. LLVM ir carries lots of annotations useful to optimizing passes, e.g. aliasing information.

Re: WebAssembly Interface Types: Interoperate with All the Things

#52

Post by pjmlp »

Rusky wrote: post #35
pjmlp wrote: post #32

Earlier quoted context omitted.

It is more politics than anything else, with WASM being the new cool kid on the block.

You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.

Please, what wonderful feature does WASM have that neither JVM nor CLR are capable of?

Or for that matter, the myriad of bytecode formats devised since UNCOL, like the IBM and UNISYS's language environments on their mainframes.

Re: WebAssembly Interface Types: Interoperate with All the Things

#53

Post by pjmlp »

the8472 wrote: post #39
pjmlp wrote: post #28

Earlier quoted context omitted.

DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/

Rendering UIs in webgl is fairly user-hostile. No accessability, no extensions, no custom styles, ...

Yes it keeps coming up, yet Flash will have its revenge.

Re: WebAssembly Interface Types: Interoperate with All the Things

#54

Post by pjmlp »

icebraining wrote: post #46
pjmlp wrote: post #28

Earlier quoted context omitted.

DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/

I looked into their WebAssembly demo, but it doesn't seem to use WebGL, just a regular DOM (with an ungodly number of elements).

That was just an example, maybe not the best one.

I should just have linked something done in Unity instead.

Re: WebAssembly Interface Types: Interoperate with All the Things

#55

Post by pjmlp »

mrec wrote: post #38
pjmlp wrote: post #28

Earlier quoted context omitted.

DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/

For a smallish subset of use cases, maybe. But replacing the DOM with a canvas-based UI for general use would be reinventing many of the problems of Flash.

Many designers and game devs see it otherwise.

Re: WebAssembly Interface Types: Interoperate with All the Things

#56

Post by nerdponx »

mrec wrote: post #34
RussianCow wrote: post #22

Earlier quoted context omitted.

I mostly agree with you, but it's important to point out that the big difference between WASM and the runtimes you mentioned is that WASM works in the browser, so you get out-of-the-box support for the world's biggest app platform. That's something that no other cross-platform runtime has achieved in any meaningful way, as far as I know.

Java used to work in the browser a quarter-century ago, albeit not very well. Even .NET sort of worked in the browser for both the people who enabled Silverlight. I do believe WASM is different, in a good way, but not just because it works in a browser.

This probably a good subject for a separate thread, but I do wonder why JVM-in-browser failed so hard. I know there were "security issues" but surely those weren't any worse than the JS security issues we have today?

Re: WebAssembly Interface Types: Interoperate with All the Things

#57

Post by sunfish »

the8472 wrote: post #51
icebraining wrote: post #43

Earlier quoted context omitted.

If you're distributing an executable (not a library), you can just AOT compile the generated wasm to machine code. For example, the WasmExplorer already lets you compile C++ -> wasm -> x86 assembly: https://mbebenita.github.io/WasmExplorer/?state=%7B%22option...

I doubt you get the same performance as direct compilation. LLVM ir carries lots of annotations useful to optimizing passes, e.g. aliasing information.

The twist is, you can produce wasm from LLVM, including running the full mid-level optimizer first, which is the part of LLVM where those annotations and aliasing information are most valuable.

Re: WebAssembly Interface Types: Interoperate with All the Things

#58

Post by bpye »

the8472 wrote: post #51
icebraining wrote: post #43

Earlier quoted context omitted.

If you're distributing an executable (not a library), you can just AOT compile the generated wasm to machine code. For example, the WasmExplorer already lets you compile C++ -> wasm -> x86 assembly: https://mbebenita.github.io/WasmExplorer/?state=%7B%22option...

I doubt you get the same performance as direct compilation. LLVM ir carries lots of annotations useful to optimizing passes, e.g. aliasing information.

If this turns out to be useful then what's stopping us adding similar annotations in a custom section for Webassembly?

Re: WebAssembly Interface Types: Interoperate with All the Things

#59

Post by adev_ »

mrec wrote: post #34
RussianCow wrote: post #22

Earlier quoted context omitted.

I mostly agree with you, but it's important to point out that the big difference between WASM and the runtimes you mentioned is that WASM works in the browser, so you get out-of-the-box support for the world's biggest app platform. That's something that no other cross-platform runtime has achieved in any meaningful way, as far as I know.

Java used to work in the browser a quarter-century ago, albeit not very well. Even .NET sort of worked in the browser for both the people who enabled Silverlight. I do believe WASM is different, in a good way, but not just because it works in a browser.

> Java used to work in the browser a quarter-century ago, albeit not very well. Even .NET sort of worked in the browser for both the people who enabled Silverlight.

Not Really. They worked With a plugin side to the browser and not really IN the browser.

And that makes a big difference. Nor Java Applet, nor Sliverlight not even Flash were offering a smooth, integrated experience with in web page or application.

I have seen flash applet crashing more than I can count. JVM applet launch was cumbersome at best and bringing the beauty (irony) of Java-style GUI in my browser. Sliverlight remained a joke unusable outside of Windows.

WebAssembly made something unthinkable before: Make all Web Browsers Manufacturers agreed on a Standard for a Virtual Machine and implementing it.

Post reply on HN