I get what components are supposed to do, but how does wasm currently talk with the browser and javascript code? Can it manipulate the DOM and execute asynchronously (like promises) or is it just a black box that receives some data and returns other data synchronously?
By default, a WebAssembly module has no access to any host APIs — particularized for the web platform, a running module will have no way of accessing the DOM by default.
When instantiating a module, it can use module imports [1], which can be used to access the DOM through JavaScript calls.
WebAssembly's type system supports just a handful of numeric types and opaque external reference types. How does WIT map its richer type system (which includes things like strings and records) onto these underlying types in a language-agnostic way?
* define a VM, but not offer a public direct API
* define a language that could be interpreted, compiled or JIT-compiled to the VM
* implement the VM so that it could run standalone or in browsers
* claim "write once, run anywhere"
The WASM model appears to be almost identical, with the addition of:
* offer compilation/translation from common existing languages
Why should we prefer the WASM/WASI model to Java? Why should we believe it will be more successful?
And perhaps more deeply, re-wrapping system APIs (e.g. POSIX) in WASM-specific modules seems incredibly time-inefficient (all those commitees, all that reimplemenation...). What if anything is going to be done to provide WASM/WASI with direct system access (outside the browser) ?
If you could Applet.instantiate() as easily as WebAssembly.instantiate() and have Java methods immediately available from JavaScript, I have no doubt that it would be as successful as WASM is. The advantage of WASM is that it’s already integrated with JavaScript VMs in a way that Java never was. Though I suppose it’s possible if someone wants to get V8 running JVM bytecode!
Yes—in most cases the technology itself doesn’t matter as much as how it can be deployed. The popularity of JavaScript itself is testament to that (though the technology has caught up quite a bit there).
Maybe the real reason has to do with security, then? That was the justification for removing Java support from browsers, leaving the door open for WASM to take its place.
- NaCL (as I understand it) essentially enshrined a particular version of llvm bytecode as its data format. This made it overcomplicated, and made it very difficult (technically and politically) for other browsers to implement any of it. It was difficult to compile to, and only supported chrome (which was at the time much less dominant than it is now). But webassembly is like NaCL 3.0 anyway. (2.0 was asmjs). Webassembly is NaCL's successor, not its rival.
- Flash was always a firehose of security vulnerabilities, and using it tied the future of the web to an (essentially) proprietary format put out by a single company. Flash never worked well on mobile - when it worked at all it turned your phone into a pocket heater. It didn't help that so many banner ads were distributed via flash. And given how badly flash integrated with the browser's scheduler that meant a background tab turned your computer into a space heater. Ultimately flash was killed by adobe's failure to ship a good enough product.
- Java in the browser had nearly as many security issues as flash did. And it took seconds for the jvm to start up. When it worked at all that is - java applets relied on the user to have a reasonably up-to-date version of the JVM installed (and appropriate browser extensions). Even as a developer it was a pain to get java applets working. And for what benefit? So we could have ugly non-native controls? It could have worked if browser vendors all shipped a properly sandboxed lightweight JVM like they started to do with flash. But nobody used applets anyway because they barely worked on anyone's computers.
Webassembly has taken all of the lessons from this to heart and taken 2 really important steps that no competing system has achieved:
1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. As a result it is orders of magnitude more secure than flash or java.
2. Webassembly got buy-in from browser vendors. Because the browsers are in charge of their respective wasm virtual machines, they're extremely well integrated with the rest of the browser. Wasm has solid JS APIs, it works everywhere including mobile, it starts up instantly (unlike java), and its tied to browsers' update mechanisms.
Yeah, politics were involved. But the outcome is much better than we would have achieved with flash or java. And I'm very grateful for the outcome. I don't want to need proprietary junk from Adobe and Oracle to make the web work.
1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area.
Which is mostly sort of great in a browser context. But WASI appears to be pushing WASM for use outside the browser context, and for this to really make sense, the restruction in your #1 would need to be severely relaxed and/or substantial and large modules added to facilitate interaction with the underlying host system.
Of course some of this happened at the browser level already: web audio, web usb as the two main examples. But as that keeps happening, the "tiny surface area" feature also gets a little harder to claim.
See, you cleverly left out PNaCL and used the bounds checking argument for WebAssembly, which doesn't apply at all to data structures stored on the same linear memory segment.
As for the rest I won't even bother to dismantle yet again.
I feel like Web Assembly is hard to understand if you don't have a background in systems programming.
Coming from web dev what are some good resources to get me to a point where i can better bridge the gap?
I just started learning Rust a few days ago (Doing adventofcode in Rust) but i don't really know what path to take to be able to build something useful with Web Assembly
isn't webassemly just a compile-target? Like JVM-bytecode or real x86 assembly?
If so, then you are not really supposed to understand web assembly. Just like x86 assembly it's just what your language, like rust, compiles to. If you want to understand it, then I suppose it's hard unless you have a background in systems programming since it's so low-level. It's the nature of the game and web-dev is quite removed from low-level coding.
I don't have an experience with web assembly, it's just how I understood the concept.
Webassembly is like a virtual machine without any standard library but permits custom embedders. As you could imagine that makes it limiting and is in part what things like WASI and Webassembly Components are trying to address.
If you're coming from web dev, I would think of it as a "foreign function interface" from javascript. You're calling a function defined in some other language. Here's a function, in WAT format (Web Assembly Text), that returns the number 42:
Go to https://mbebenita.github.io/WasmExplorer/ and paste that in the middle box, then click assemble, then download, and you'll have a local file called "test.wasm".
Then, since you already do web dev, get that test.wasm file and a new page accessible from a local web server. The new page should have this in it:
<script>
// should log 42 to the console
WebAssembly.instantiateStreaming(fetch('https://path/to/test.wasm')).then(prog => {
console.log(prog.instance.exports.testfunction());
});
</script>
Everything else is facades, layers, and tools on top of that. But that should help clear up what's at the bottom from a web-dev/js perspective. And also what the "2 halves" are. One half being, in your case, that the Rust compiles down eventually to WASM that you host somewhere. The other half being that you need to be able to call into that generated code from your JS.
This pretty much summarizes what a clusterfuck WebAssembly is.
It should be possible to just paste the 6 wasm lines into a <script type=wasm> block. This is what made the web successful. Not having to have tooling to build things.
Yeah. You can use a base64 data uri, but that's not great either. There is a proposal for <script type="module">, but it looks untouched for several years: https://github.com/WebAssembly/proposals/issues/12
I understand where you are coming from and something like you just mentioned would be a nice feature. However, it does seem worth mentioning that most people are not going to want to write code in web assembly text format. The current tooling exists so you can load binary data which wouldn’t embed well into a script tag. The primary use case is compiling code written in other languages that often have a runtime that comes with them. Because of that the payloads are often much larger than anything you would want in a script tag as well. There is also more to it than just loading a script. You get to have shared memory buffers and you have control over what to share between the JS and WASM env. This configuration is simplest with JS. It’s a very small amount of code to load WASM and configure these things.
If web assembly text format was just a more performant scripting language then I’d go with your proposal. Since it is meant to be a visual representation of WASM binary format and that binary code is more useful when it can be configured, I don’t mind the current implementation.
Somehow the formats that WebAssembly is deemed being better of, managed to do it via object tags or script source attributes, but naturally in HTML 5 everything is better except when not.
I found going through the AssemblyScript setup and tutorials really helped me understand WASM without first having to wrap my head around C++ or Rust toolchains. AssemblyScript is a TypeScript dialect that compiles to WASM instead of JavaScript: https://www.assemblyscript.org/
What I find really interesting about AssemblyScript is the potential for homographic code between JS and WASM. I'd prefer to see languages like AssemblyScript that are designed for WASM first, rather than shoe-horning existing languages like C++--and thus, their existing library ecosystems--into WASM. Yes, there is a lot of extant code that people are interested in porting, but that's not the end of the world and I'm not too keen on the bloat it creates or having to debug the teetering tower of tools that it represents if some impedence mismatch causes problems along the way.
With homographic AssemblyScript and TypeScript, I start to imagine a time when you can run an app on your phone, serialize the whole state of it, push it off to another user or your PC or something, and pick up where you left off. Maybe you'd do it for more compute power. Maybe you'd do it to share state on a collaboration. I don't know. But it's a fascinating idea that I'd really like to see one day.
If it helps, I have a couple decades experience as a systems programmer and I find it hard to understand how to interface my code with JS. Web dev with its constantly shifting frameworks is baffling to me.
I found the book The Art Of Web Assembly [1] to really help me understand it better. A lot of other books seem to focus on a specific part of the tool chain. This one shows you all of the examples in web assembly text language. While I wouldn’t want to write a program in it, reading it with the context provided by the author really helped me understand what is going on. It also helped me understand why so many things are the way they are in the current iteration of the WASM world.
I think that's one of the things that confuses people. WASM is, in some respects, very similar to ASM. In other respects, it's very similar to a language VM, but has a name that makes that non-obvious. Will likely get more confusing as they add things that normal ASM doesn't do, like GC, direct JS call interop, more data types, etc.
I think that what actually confuses people is presenting WASM as something completely new, without even briefly discussing all the kinds of approaches to polyglot bytecode formats since the early 1960's.
So those not versed into the matter fail to understand the overall picture as it isn't given to them.
Rust has probably the most batteries included, with explanation, of most of the languages that compile to WASM right now. It has a lot of tooling that takes some of the underlying pain out of interfacing with JS. There's even an online guide for it:
I had a look at both WebAssembly and Rust a few months back, in the hope they could help me write some nice, fast graphics filters that I could then compile out and use via Wasm in a 2d canvas. Entirely do-able, but beyond my limits of understanding and patience.
Since then, I've stuck with what I know (Javascript) and branched instead into consuming Wasm written by others (in whatever language) on the frontend for my own experiments - for instance Rapier[1] which is a physics engine written in Rust, and some of the MediaPipe ML models[2].
I think this could be a massive step forward for computing. Imagine if you will an add-on ecosystem for image editors like Krita or video editors like KdenLive. Add-ons could be distruted as a single package and can be run anywhere regardless of the system architecture or software plugin architecture, even within web applications. Write once, run anywhere.
Isn't the memory barrier a huge penalty? (WASM can only access it's own memory, never the hosts.) I've been thinking about how WebAssembly could work server side to host websites, but every step seems to be copy bytes into or out of the VM.
That's exactly what is happening. It is just that this time it may actually work. For one thing, the industry as a whole (including Microsoft) is supportive of the standard and we have the benefit of 25+ years of hindsight
From what I've seen of wit (called "witx" back when I last used it) it seems to be pretty skewed towards using Rust as inspiration for its design, even though it's meant to be language agnostic. The syntax is not far off from being a one-to-one copy of Rust.
Some examples: `foo: bar` for type annotations, `->` for return types, `enum { a, b }` for C-style enums, `variant { a(b, c) }` for tagged unions, `type a = b` for type aliases, `_` for placeholder types. Its implementation of WASI even uses `-> expected<_, errno>` for most of its return signatures, imitating Rust's Result.
I really like Rust's type system and syntax, and none of these design decisions are bad in their own right, I just get the impression that other language communities are not having enough influence in the design of WebAssembly compared to Rust.
I think that is a really valid observation, and I would like to point out a couple of things:
- the WIT language decisions will end up impacting people writing WIT syntax by hand. I am not sure how large that audience is right now (and I am not dismissing the initial comment), but I really hope we could get good enough tooling that could directly generate WIT (in its eventual binary format) based on annotated source code.
- an equally valid observation here is that we need people from multiple programming languages looking at generating _idiomatic bindings_ based on the WIT format, which is what end users will interact with when using components. (Currently there are binding generators for Rust and C/C++, with hopefully Grain following soon enough.)
AssemblyScript maintainer here. Can confirm, other language communities have practically zero influence on the design. In fact, AS was present during "specification" and has been completely annihilated for disagreeing with what the chairing majority has come up with there. It's particularly ironic that the Component Model suddenly targets Web integration again, or that this is now coined "language neutral". In relation, the syntax is more of a minor detail.
Earlier I posted an article by Don Box comparing SOM and COM, and I mentioned that WebAssembly is going through a similar evolution, and might benefit from some of the lessons of COM and SOM:
COM vs SOM: The Component Object Model and Some Other Model (1999) (archive.org)
This article comparing SOM and COM was written by Don Box. (first archived in January 1999, but doesn't say when published):
The Component Object Model and Some Other Model: A comparison of technologies revisited yet again:
Don Box wrote an excellent in-depth book about COM: "Essential COM": "Nobody explains COM better than Don Box" -Charlie Kindel, COM Guy, Microsoft Corporation.
Here's a synopsis of COM I wrote in response to "Can someone link to a synopsis describing what "COM" is? It's hard to search for. (e.g. microsoft com visual studio)":
Don't get me wrong: I'm not advocating everybody jump on the COM bandwagon! I just think it's interesting and useful to know where it came from, how it evolved, what different layers were built on top of it, and how it compared to the alternatives at the time it was designed. And it's still pretty widely used, and will probably never go away.
It certainly had a lot of problems and limitations, and OLE/ActiveX/DCOM/DirectX/etc took it way too far, then Mozilla XP/COM cloned it and also took it way too far (and then back again: see "decomification" and "decomtamination"), but it really was a pretty elegant and successful solution to the problems it was designed to address at the time.
COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages.
It was the outcome of the C / C++ / Visual Basic language wars at Microsoft.
[...]
Also some stuff about Netscape's Internet Foundation Classes:
Wow, a blast from the past! 1996, what a year that was.
Sun was freaking out about Microsoft, and announced Java Beans as their vaporware "alternative" to ActiveX. JavaScript had just come onto the scene, then Netscape announced they were going to reimplement Navigator in Java, so they dove into the deep end and came up with IFC, which designed by NeXTStep programmers. A bunch of the original Java team left Sun and formed Marima, and developed the Castanet network push distribution system, and the Bongo user interface editor (like HyperCard for Java, calling the Java compiler incrementally to support dynamic script editing).
[...]
There was also a previous discussion about Mozilla's WebAsembly System Interface:
Mozilla announces WebAssembly System Interface, what JVM should have been (theregister.co.uk):
DonHopkins on April 22, 2019 | parent | context | favorite | on: Mozilla announces WebAssembly System Interface, wh...
>"WebAssembly has been designed to scale from tiny devices to large server farms or CDNs..."
What's ironic is that the "tiny devices" and even "high end professional desktop workstation and server devices" that Java was originally designed to run on when it was started in 1990 were MUCH tinier than the devices considered "tiny" today.
How many more times faster is a typical smartphone today (Raspberry Pi 3: 2,451 MIPS, ARM Cortex A73: 71,120 MIPS) that a 1990 SparcStation 2 pizzabox (28.5 MIPS, $15,000-$27,000)?
This is an excellent collection of SOM/COM resources, thanks a lot for that!
Perhaps not surprising, but COM/DCOM has been a recurring reference when talking about the WebAssembly component model.
Another useful resource from the past that influenced quite a few Wasm component discussions (h/t to Luke Wagner for sharing it) is one about Knit [1], which as intended as a _component definition and linking language_ for C.
Hi, author of the article here. Happy to have a discussion about the WebAssembly component model and current implementations.
I get what components are supposed to do, but how does wasm currently talk with the browser and javascript code? Can it manipulate the DOM and execute asynchronously (like promises) or is it just a black box that receives some data and returns other data synchronously?
By default, a WebAssembly module has no access to any host APIs — particularized for the web platform, a running module will have no way of accessing the DOM by default.
When instantiating a module, it can use module imports [1], which can be used to access the DOM through JavaScript calls.
[1]: https://webassembly.github.io/spec/core/syntax/modules.html#...
WebAssembly's type system supports just a handful of numeric types and opaque external reference types. How does WIT map its richer type system (which includes things like strings and records) onto these underlying types in a language-agnostic way?
I guess they will need to rediscover the Common Language Subset of the Common Language Runtime and re-sell it as an invention.
So ... the Java model was:
The WASM model appears to be almost identical, with the addition of:
Why should we prefer the WASM/WASI model to Java? Why should we believe it will be more successful?
And perhaps more deeply, re-wrapping system APIs (e.g. POSIX) in WASM-specific modules seems incredibly time-inefficient (all those commitees, all that reimplemenation...). What if anything is going to be done to provide WASM/WASI with direct system access (outside the browser) ?
If you could Applet.instantiate() as easily as WebAssembly.instantiate() and have Java methods immediately available from JavaScript, I have no doubt that it would be as successful as WASM is. The advantage of WASM is that it’s already integrated with JavaScript VMs in a way that Java never was. Though I suppose it’s possible if someone wants to get V8 running JVM bytecode!
So your argument there is "well, I can access WASM from javascript more easily that I could access Java" ? That's it?
Yes—in most cases the technology itself doesn’t matter as much as how it can be deployed. The popularity of JavaScript itself is testament to that (though the technology has caught up quite a bit there).
Except it actually was, as there was an interop API for applets to interact with DOM and vice-versa.
You're right, and not just the DOM: https://docs.oracle.com/javase/tutorial/deployment/applet/in...
Maybe the real reason has to do with security, then? That was the justification for removing Java support from browsers, leaving the door open for WASM to take its place.
Politics,
https://en.m.wikipedia.org/wiki/Google_Native_Client
https://adobe-flash.github.io/crossbridge/
https://www.usenix.org/conference/usenixsecurity20/presentat...
There's also technical reasons galore:
- NaCL (as I understand it) essentially enshrined a particular version of llvm bytecode as its data format. This made it overcomplicated, and made it very difficult (technically and politically) for other browsers to implement any of it. It was difficult to compile to, and only supported chrome (which was at the time much less dominant than it is now). But webassembly is like NaCL 3.0 anyway. (2.0 was asmjs). Webassembly is NaCL's successor, not its rival.
- Flash was always a firehose of security vulnerabilities, and using it tied the future of the web to an (essentially) proprietary format put out by a single company. Flash never worked well on mobile - when it worked at all it turned your phone into a pocket heater. It didn't help that so many banner ads were distributed via flash. And given how badly flash integrated with the browser's scheduler that meant a background tab turned your computer into a space heater. Ultimately flash was killed by adobe's failure to ship a good enough product.
- Java in the browser had nearly as many security issues as flash did. And it took seconds for the jvm to start up. When it worked at all that is - java applets relied on the user to have a reasonably up-to-date version of the JVM installed (and appropriate browser extensions). Even as a developer it was a pain to get java applets working. And for what benefit? So we could have ugly non-native controls? It could have worked if browser vendors all shipped a properly sandboxed lightweight JVM like they started to do with flash. But nobody used applets anyway because they barely worked on anyone's computers.
Webassembly has taken all of the lessons from this to heart and taken 2 really important steps that no competing system has achieved:
1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. As a result it is orders of magnitude more secure than flash or java.
2. Webassembly got buy-in from browser vendors. Because the browsers are in charge of their respective wasm virtual machines, they're extremely well integrated with the rest of the browser. Wasm has solid JS APIs, it works everywhere including mobile, it starts up instantly (unlike java), and its tied to browsers' update mechanisms.
Yeah, politics were involved. But the outcome is much better than we would have achieved with flash or java. And I'm very grateful for the outcome. I don't want to need proprietary junk from Adobe and Oracle to make the web work.
Which is mostly sort of great in a browser context. But WASI appears to be pushing WASM for use outside the browser context, and for this to really make sense, the restruction in your #1 would need to be severely relaxed and/or substantial and large modules added to facilitate interaction with the underlying host system.
Of course some of this happened at the browser level already: web audio, web usb as the two main examples. But as that keeps happening, the "tiny surface area" feature also gets a little harder to claim.
See, you cleverly left out PNaCL and used the bounds checking argument for WebAssembly, which doesn't apply at all to data structures stored on the same linear memory segment.
As for the rest I won't even bother to dismantle yet again.
CLR and IBM TIMI already offered that one, among others older than Java.
I feel like Web Assembly is hard to understand if you don't have a background in systems programming.
Coming from web dev what are some good resources to get me to a point where i can better bridge the gap?
I just started learning Rust a few days ago (Doing adventofcode in Rust) but i don't really know what path to take to be able to build something useful with Web Assembly
isn't webassemly just a compile-target? Like JVM-bytecode or real x86 assembly?
If so, then you are not really supposed to understand web assembly. Just like x86 assembly it's just what your language, like rust, compiles to. If you want to understand it, then I suppose it's hard unless you have a background in systems programming since it's so low-level. It's the nature of the game and web-dev is quite removed from low-level coding.
I don't have an experience with web assembly, it's just how I understood the concept.
Webassembly is like a virtual machine without any standard library but permits custom embedders. As you could imagine that makes it limiting and is in part what things like WASI and Webassembly Components are trying to address.
If you're coming from web dev, I would think of it as a "foreign function interface" from javascript. You're calling a function defined in some other language. Here's a function, in WAT format (Web Assembly Text), that returns the number 42:
Go to https://mbebenita.github.io/WasmExplorer/ and paste that in the middle box, then click assemble, then download, and you'll have a local file called "test.wasm".
Then, since you already do web dev, get that test.wasm file and a new page accessible from a local web server. The new page should have this in it:
Everything else is facades, layers, and tools on top of that. But that should help clear up what's at the bottom from a web-dev/js perspective. And also what the "2 halves" are. One half being, in your case, that the Rust compiles down eventually to WASM that you host somewhere. The other half being that you need to be able to call into that generated code from your JS.
This pretty much summarizes what a clusterfuck WebAssembly is.
It should be possible to just paste the 6 wasm lines into a <script type=wasm> block. This is what made the web successful. Not having to have tooling to build things.
Yeah. You can use a base64 data uri, but that's not great either. There is a proposal for <script type="module">, but it looks untouched for several years: https://github.com/WebAssembly/proposals/issues/12
I understand where you are coming from and something like you just mentioned would be a nice feature. However, it does seem worth mentioning that most people are not going to want to write code in web assembly text format. The current tooling exists so you can load binary data which wouldn’t embed well into a script tag. The primary use case is compiling code written in other languages that often have a runtime that comes with them. Because of that the payloads are often much larger than anything you would want in a script tag as well. There is also more to it than just loading a script. You get to have shared memory buffers and you have control over what to share between the JS and WASM env. This configuration is simplest with JS. It’s a very small amount of code to load WASM and configure these things.
If web assembly text format was just a more performant scripting language then I’d go with your proposal. Since it is meant to be a visual representation of WASM binary format and that binary code is more useful when it can be configured, I don’t mind the current implementation.
Somehow the formats that WebAssembly is deemed being better of, managed to do it via object tags or script source attributes, but naturally in HTML 5 everything is better except when not.
I found going through the AssemblyScript setup and tutorials really helped me understand WASM without first having to wrap my head around C++ or Rust toolchains. AssemblyScript is a TypeScript dialect that compiles to WASM instead of JavaScript: https://www.assemblyscript.org/
What I find really interesting about AssemblyScript is the potential for homographic code between JS and WASM. I'd prefer to see languages like AssemblyScript that are designed for WASM first, rather than shoe-horning existing languages like C++--and thus, their existing library ecosystems--into WASM. Yes, there is a lot of extant code that people are interested in porting, but that's not the end of the world and I'm not too keen on the bloat it creates or having to debug the teetering tower of tools that it represents if some impedence mismatch causes problems along the way.
With homographic AssemblyScript and TypeScript, I start to imagine a time when you can run an app on your phone, serialize the whole state of it, push it off to another user or your PC or something, and pick up where you left off. Maybe you'd do it for more compute power. Maybe you'd do it to share state on a collaboration. I don't know. But it's a fascinating idea that I'd really like to see one day.
If it helps, I have a couple decades experience as a systems programmer and I find it hard to understand how to interface my code with JS. Web dev with its constantly shifting frameworks is baffling to me.
I found the book The Art Of Web Assembly [1] to really help me understand it better. A lot of other books seem to focus on a specific part of the tool chain. This one shows you all of the examples in web assembly text language. While I wouldn’t want to write a program in it, reading it with the context provided by the author really helped me understand what is going on. It also helped me understand why so many things are the way they are in the current iteration of the WASM world.
[1]https://www.amazon.com/dp/1718501447
It is basically the same thing as JVM or CLR (specially in regards to the CLR), just with more marketing appeal.
I think that's one of the things that confuses people. WASM is, in some respects, very similar to ASM. In other respects, it's very similar to a language VM, but has a name that makes that non-obvious. Will likely get more confusing as they add things that normal ASM doesn't do, like GC, direct JS call interop, more data types, etc.
I think that what actually confuses people is presenting WASM as something completely new, without even briefly discussing all the kinds of approaches to polyglot bytecode formats since the early 1960's.
So those not versed into the matter fail to understand the overall picture as it isn't given to them.
You can use AssemblyScript instead of Rust
Rust has probably the most batteries included, with explanation, of most of the languages that compile to WASM right now. It has a lot of tooling that takes some of the underlying pain out of interfacing with JS. There's even an online guide for it:
https://rustwasm.github.io/book/
I had a look at both WebAssembly and Rust a few months back, in the hope they could help me write some nice, fast graphics filters that I could then compile out and use via Wasm in a 2d canvas. Entirely do-able, but beyond my limits of understanding and patience.
Since then, I've stuck with what I know (Javascript) and branched instead into consuming Wasm written by others (in whatever language) on the frontend for my own experiments - for instance Rapier[1] which is a physics engine written in Rust, and some of the MediaPipe ML models[2].
[1] - Rapier getting started page - https://rapier.rs/docs/user_guides/javascript/getting_starte...
[2] - MediaPipe face mesh model getting started page - https://google.github.io/mediapipe/solutions/face_mesh#javas...
You are better off learning WebGL and Houdini for that.
Components in bytecode format with support for C++, where have I seen it?
https://docs.microsoft.com/en-us/dotnet/standard/clr
https://docs.microsoft.com/en-us/cpp/dotnet/dotnet-programmi...
Oh it goes a lot further back than that!
https://news.ycombinator.com/item?id=29593432
Indeed, very nice overview.
I think this could be a massive step forward for computing. Imagine if you will an add-on ecosystem for image editors like Krita or video editors like KdenLive. Add-ons could be distruted as a single package and can be run anywhere regardless of the system architecture or software plugin architecture, even within web applications. Write once, run anywhere.
i've been working on the "C++ API" side of this if you're interested :)
- https://github.com/celtera/avendish
- https://ossia.io/posts/reflection/
coupled with the definition of a common ABI, the holy grail of reusability may start to be closer
Isn't the memory barrier a huge penalty? (WASM can only access it's own memory, never the hosts.) I've been thinking about how WebAssembly could work server side to host websites, but every step seems to be copy bytes into or out of the VM.
Where have I heard this before ....
1995 called; it wants its tag line back.
I did consider making a reference to Java but I decided against it as I thought it would be received in the spirit it was intended.
That's exactly what is happening. It is just that this time it may actually work. For one thing, the industry as a whole (including Microsoft) is supportive of the standard and we have the benefit of 25+ years of hindsight
From what I've seen of wit (called "witx" back when I last used it) it seems to be pretty skewed towards using Rust as inspiration for its design, even though it's meant to be language agnostic. The syntax is not far off from being a one-to-one copy of Rust.
Some examples: `foo: bar` for type annotations, `->` for return types, `enum { a, b }` for C-style enums, `variant { a(b, c) }` for tagged unions, `type a = b` for type aliases, `_` for placeholder types. Its implementation of WASI even uses `-> expected<_, errno>` for most of its return signatures, imitating Rust's Result.
I really like Rust's type system and syntax, and none of these design decisions are bad in their own right, I just get the impression that other language communities are not having enough influence in the design of WebAssembly compared to Rust.
I think that is a really valid observation, and I would like to point out a couple of things:
- the WIT language decisions will end up impacting people writing WIT syntax by hand. I am not sure how large that audience is right now (and I am not dismissing the initial comment), but I really hope we could get good enough tooling that could directly generate WIT (in its eventual binary format) based on annotated source code.
- an equally valid observation here is that we need people from multiple programming languages looking at generating _idiomatic bindings_ based on the WIT format, which is what end users will interact with when using components. (Currently there are binding generators for Rust and C/C++, with hopefully Grain following soon enough.)
AssemblyScript maintainer here. Can confirm, other language communities have practically zero influence on the design. In fact, AS was present during "specification" and has been completely annihilated for disagreeing with what the chairing majority has come up with there. It's particularly ironic that the Component Model suddenly targets Web integration again, or that this is now coined "language neutral". In relation, the syntax is more of a minor detail.
Earlier I posted an article by Don Box comparing SOM and COM, and I mentioned that WebAssembly is going through a similar evolution, and might benefit from some of the lessons of COM and SOM:
COM vs SOM: The Component Object Model and Some Other Model (1999) (archive.org)
https://web.archive.org/web/19990127184653/http://www.develo...
https://news.ycombinator.com/item?id=20266450
https://news.ycombinator.com/item?id=20266627
https://web.archive.org/web/19990127184653/http://www.develo...
https://en.wikipedia.org/wiki/Component_Object_Model
https://web.archive.org/web/19990117055950/http://www.develo...
https://en.wikipedia.org/wiki/IBM_System_Object_Model
https://en.wikipedia.org/wiki/Don_Box
https://archive.org/details/essentialcom00boxd
https://donhopkins.com/home/interval/pluggers/win32.html
https://donhopkins.com/home/interval/pluggers/com.html
https://donhopkins.com/home/interval/pluggers/ole.html
https://donhopkins.com/home/interval/pluggers/olecontrols.ht...
https://donhopkins.com/home/interval/pluggers/activex.html
https://news.ycombinator.com/item?id=12975257
https://wiki.mozilla.org/Gecko:DeCOMtamination
https://news.ycombinator.com/item?id=12968830
https://bugzilla.mozilla.org/buglist.cgi?query_format=specif...
Also, here's a description of the origins of COM that I posted earlier:
https://news.ycombinator.com/item?id=12975257
Also some stuff about Netscape's Internet Foundation Classes:
https://news.ycombinator.com/item?id=19837817
There was also a previous discussion about Mozilla's WebAsembly System Interface:
Mozilla announces WebAssembly System Interface, what JVM should have been (theregister.co.uk):
https://news.ycombinator.com/item?id=19716179
https://www.theregister.com/2019/03/29/mozilla_wasi_spec/
https://news.ycombinator.com/item?id=19717416
http://www.wikiwand.com/en/Instructions_per_second
This is an excellent collection of SOM/COM resources, thanks a lot for that!
Perhaps not surprising, but COM/DCOM has been a recurring reference when talking about the WebAssembly component model. Another useful resource from the past that influenced quite a few Wasm component discussions (h/t to Luke Wagner for sharing it) is one about Knit [1], which as intended as a _component definition and linking language_ for C.
[1]: https://www.cs.utah.edu/flux/papers/knit-osdi00/