Live data from Hacker News

WebAssembly Interface Types: Interoperate with All the Things

hacks.mozilla.org

11–20 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#11
post #5
post #3

I'm gonna go out on a limb here and expose my n00bishness, and honestly a lot of that article has my head spinning as I google a lot of terms ;) I've only done web development for a year now and I've seen some cool WebAssembly demos but mostly those are demos of various frameworks (or no framework) reusing random WebAssembly components. It's cool, but I'm missing from a large web application stance how WebAssembly is…

Web assembly is generally an optimization, not an app alternative. Think of it the way you would the C bindings Node.js has. If you've got a compute-heavy code path, writing it in C (or Rust etc) and shipping it as web assembly could be a dramatic perf improvement, but there's not really a substantive benefit to writing your entire app with it.

> but there's not really a substantive benefit to writing your entire app with it.

Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that.

So while the concrete performance boost may not be meaningful in writing an entire web app in C, Rust, Go, Python or w/e - to the developer happiness the boost may be huge for those devs that want it.

Re: WebAssembly Interface Types: Interoperate with All the Things

#12
Super happy to see WebAssembly Interface Types in development!

At Wasmer (disclaimer, I'm the founder!) we've been creating integrations with a lot different languages (C, C++, Rust, Python, Ruby, PHP, C# and R) and we agree that this is a pain point and an important problem to solve. We're excited that Mozilla is also pushing this forward.

If you want to start using WebAssembly anywhere: https://wasmer.io/

Keep up the good work! Let's bring WebAssembly everywhere!

Re: WebAssembly Interface Types: Interoperate with All the Things

#13
I'm very happy to see the WebIDL proposal replaced with something generalized.

The article brings up an interesting point:

Webassembly really could enable seamless cross-language integration in the future.

Writing a project in Rust, but really want to use that popular face detector written in Python?

And maybe the niche language tokenizer written in PHP?

And sprinkle ffmpeg on top, without the hassle of target-compatible compilation and worrying about use after free vulnerabilities?

No problem use one of the many WASM runtimes popping up (like [1], [2]) and combine all those libraries by using their pre-compiled WASM packages distributed on a package repo like WAPM [2], with auto-generated bindings that provide a decent API from your host language.

Sounds too good to be true? Probably, and there are plenty of issues to solve.

But it sounds like a future where we could prevent a lot of the re-writes and duplication across the open source world by just tapping into the ecosystems of other languages.

[1] https://wapm.io/ [2] https://github.com/CraneStation/wasmtime [2] https://wapm.io/

Re: WebAssembly Interface Types: Interoperate with All the Things

#14
post #3

I'm gonna go out on a limb here and expose my n00bishness, and honestly a lot of that article has my head spinning as I google a lot of terms ;) I've only done web development for a year now and I've seen some cool WebAssembly demos but mostly those are demos of various frameworks (or no framework) reusing random WebAssembly components. It's cool, but I'm missing from a large web application stance how WebAssembly is…

Maybe that article can help about real world use case : https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-r...

Re: WebAssembly Interface Types: Interoperate with All the Things

#15
post #3

I'm gonna go out on a limb here and expose my n00bishness, and honestly a lot of that article has my head spinning as I google a lot of terms ;) I've only done web development for a year now and I've seen some cool WebAssembly demos but mostly those are demos of various frameworks (or no framework) reusing random WebAssembly components. It's cool, but I'm missing from a large web application stance how WebAssembly is…

Maybe that article can help about real world use case : https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-r...

Thank you.

Re: WebAssembly Interface Types: Interoperate with All the Things

#16
post #5

Earlier quoted context omitted.

Web assembly is generally an optimization, not an app alternative. Think of it the way you would the C bindings Node.js has. If you've got a compute-heavy code path, writing it in C (or Rust etc) and shipping it as web assembly could be a dramatic perf improvement, but there's not really a substantive benefit to writing your entire app with it.

> but there's not really a substantive benefit to writing your entire app with it. Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that. So while the concrete performance boost may not be meaningful in writing a…

Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.

Re: WebAssembly Interface Types: Interoperate with All the Things

#17
Note that Wasmtime is the engine starring in the blog post and demos :-).

Of course, cross-language interfaces will always have tradeoffs. But we see Interface Types extending the space where the tradeoffs are worthwhile, especially in combination with wasm's sandboxing.

Re: WebAssembly Interface Types: Interoperate with All the Things

#18

I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable seamless cross-language integration in the future. Writing a project in Rust, but really want to use that popular face detector written in Python? And maybe the niche language tokenizer written in PHP? And sprinkle ffmpeg on top, without the hassle of target-compat…

JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language".

Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc. And all of those will feel like a cousin to JavaScript, just as anything on the JVM feels similar to Java, on Parrot feels similar to Perl 6, and on the CLR feels similar to C#. WASM's choice of data structures, control flow, and data representations will be strongly influenced by the requirements of the major JavaScript engines (in Firefox, Chrome, and maybe WebKit). This is already the case when it comes to control flow semantics.

Re: WebAssembly Interface Types: Interoperate with All the Things

#19

I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable seamless cross-language integration in the future. Writing a project in Rust, but really want to use that popular face detector written in Python? And maybe the niche language tokenizer written in PHP? And sprinkle ffmpeg on top, without the hassle of target-compat…

Besides the technology questions, there are also non-technical considerations too. Who do you want governing the package repo you host all your code in?

Re: WebAssembly Interface Types: Interoperate with All the Things

#20
post #16

Earlier quoted context omitted.

> but there's not really a substantive benefit to writing your entire app with it. Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that. So while the concrete performance boost may not be meaningful in writing a…

Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.

Fwiw, you can - just perhaps with not pure WASM and perf.

My next app I'm planning on using a Rust WASM DOM framework, and I know there are some in Go as well. This is primarily for developer UX.

Post reply on HN