WebAssembly Interface Types: Interoperate with All the Things
hacks.mozilla.org
WebAssembly Interface Types: Interoperate with All the Things
1–10 of 119 posts
Re: WebAssembly Interface Types: Interoperate with All the Things
#2Oh, this is wonderful. Getting closer to that multilang WASM world.
Re: WebAssembly Interface Types: Interoperate with All the Things
#3I'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 supposed to work, specifically when it comes to stuff like you see in some frameworks with state management across components and etc. Is there an example of that?
Re: WebAssembly Interface Types: Interoperate with All the Things
#4So this is what they've been up to!
How well will this interact with the upcoming (hopefully before the heatdeath of the universe) rich gc types extension?
Re: WebAssembly Interface Types: Interoperate with All the Things
#5I'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.
Re: WebAssembly Interface Types: Interoperate with All the Things
#6I'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.
Another benefit I suppose is that you can choose from many more languages. Whether that is substantive or not depends on the person, I guess.
Re: WebAssembly Interface Types: Interoperate with All the Things
#7I'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.
That's a use case, but there are many others, as the article mentions, like lightweight isolation for server side apps or writing your frontend app in a different language (not pragmatic today, but could be in the future).
Re: WebAssembly Interface Types: Interoperate with All the Things
#8So this is what they've been up to! How well will this interact with the upcoming (hopefully before the heatdeath of the universe) rich gc types extension?
Interface types will make it easy for two modules to interface with each other, regardless of whether both sides use GC, just one side does, or neither side does. And even within GC types, different languages have different ways of representing strings, and Interface Types can allow them to talk to each other.
Re: WebAssembly Interface Types: Interoperate with All the Things
#9Glad to see this being worked on. The difference between a heap vs. runtime managed object is a huge perf gap for tightly interoperating JS and WASM. At my company, we built a specific object representation that would allow zero copy, through array buffer sharing, views of C++ data from Javascript. Sounds very similar to this.
Re: WebAssembly Interface Types: Interoperate with All the Things
#10I'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.
Another benefit is initial page load times, if your page has a lot of JS it can take a pretty significant amount of time to parse it.
i.e. Figma said it reduced page load times by a factor of 3, though they were using WASM to replace existing asm.js code.
https://www.figma.com/blog/webassembly-cut-figmas-load-time-...