13 ms·

Missing the Point of WebAssembly

199 points by ryukafalz 3y ago

singularity2001 3y ago
how to handle gc strings when most tools don't support wasm stringref?
- davexunit 3y ago
  Yeah the strings situation isn't so good right now. stringref is really good imo but different factions in the wasm group are opposed. The best way to represent strings right now is (array (mut i8)) for UTF-8 or WTF-8 data. In Guile Hoot we are using stringref because it's convenient for the compiler to be able to emit (string.const "foo") and such, but we then perform a post-pass to remove all stringref instructions and replace them with instructions that operate on i8 arrays so the resulting binaries are usable. This approach has the advantage that string contents are visible to wasm so internal string manipulation is fast, but the downside is that strings have to be copied when going across the host/wasm boundary. An alternative approach would be to fully rely on the host to provide strings utilizing extern refs. This avoids the copying at the boundary problem of the first approach, but it has the disadvantage that all string operations need to call the host, so internal string manipulation is slow.
gwbas1c 3y ago
WebAssembly allows you to program web pages in a language other than Javascript. The above statement might gloss over a lot of very important details: But that mindset also misses the point: The critical use case of WebAssembly, and the problem it attempted to solve, right now, is to creating a webpage in a language other than JavaScript. Everything else that the article mentions is an impressive feat on its own, but what WebAssembly could do is very different than what it does now. And the fact that now you can program a website in a language other than Javascript (or TypeScript) is a very tangible accomplishment that people who aren't enamored with computer science can appreciate, understand, and repeat.
- bryanlarsen 3y ago
  There are many places that have been using WASM for purposes similar to the ones in the article for quite a while now. For example, Cloudflare workers have been using WASM for a year and a half.
  - steveklabnik 3y ago
    Workers has supported WASM since 2018: https://blog.cloudflare.com/webassembly-on-cloudflare-workers https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
- jauntywundrkind 3y ago
  I'm both excited about cross-language but also I think the people you describe as potential beneficiaries are those most apt to suffer under the new (anti-)regime. > And the fact that now you can program a website in a language other than Javascript (or TypeScript) is a very tangible accomplishment that people who aren't enamored with computer science can appreciate, understand, and repeat. Industrial software dev has resulted in gross difficult minified bundles & absurdities like vdom that are hard to view-source hack. But there's pretty ok un-minifying & it's surprisingly possible to get really far, if a user wants to seize the power & do some userscripting. And many in the webdev world have steadily been trying to push back against this rampant industrialization. HTTP2 and ESM were hopefully going to make unbundling more viable, but that's still long suffering (ex: import-maps don't work for workers, https://github.com/WICG/import-maps/issues/2 https://github.com/WICG/import-maps/issues/2), and now that the http cache doesn't work cross-site many of the possible re-use upsides are dead. Still a goal for many though. WebComponents is still a vast un-frameworking potential; in many implementations it unravels the descent into abstraction that React framework begat. Classic web devs have a lot of heart to make the web pro-user, to un-framework things, but the industrial demands are hard to re-satisfy on these better paths & so much momentum is elsewhere. Now compare to the wasm world. We have basically pure machine code running our web in wasm. It's utterly unintelligible. There's dozens of hundred of kb libraries that languages bring in to userland just to do the language thing. I think people will have an incredibly poor time learning the web, think the worst risk wasm has is in scaring people off from view-source, from casually observing & learning anything. Wasm is god smiting the tower of Babel, is a one language breaking & being cast down & a hundred different tribes speaking their own language. So much good will come from this diversity, we'll see so many different styles & tries from so many camps, and that will be a benefit, but it will in my view be drastically harder for those "who aren't enamored with computer science can appreciate, understand, and repeat." Intelligibility is the loser, when Babel falls.
neilalexander 3y ago
It is strange to me to see so much talk about all of the places WebAssembly could live, like IoT devices and edge lambdas and cross-architecture binaries, places that don't really need these problems to be solved, and yet so little talk about whether or not it can finally unshackle the web from the mess that is JavaScript. As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity.
- danielvaughn 3y ago
  It can perform a lot of computational work, but yeah it can't yet interface directly with the DOM. I'm not sure about whether it can access the network or other things, but I don't believe that it can.
  - deleted 3y ago
    [deleted]
  - edgyquant 3y ago
    Are there plans to add DOM support? That seems pretty critical for what I had thought wasm was supposed to be myself.
    - danielvaughn 3y ago
      I'm not sure. All I know is that there are some hurdles to get past. One of them is that several DOM APIs were created specifically for JavaScript, which is...really disheartening.
    - davexunit 3y ago
      Wasm allows for importing host functions. Those host functions could provide DOM access. With Wasm GC it is possible to pass external references (DOM nodes, promises, etc.) to and from Wasm. What this looks like in practice is that a thin JS bootstrap script instantiates the Wasm module, passing along a set of JS functions that map to the declared Wasm imports and then the program is effectively driven from Wasm at that point.
MichaelMug 3y ago
Where can I find more information about managed data types in WebAssembly?
- davexunit 3y ago
  GC managed types? Wasm GC spec: https://webassembly.github.io/gc/core/index.html https://webassembly.github.io/gc/core/index.html Heap types in particular: https://webassembly.github.io/gc/core/syntax/types.html#heap-types https://webassembly.github.io/gc/core/syntax/types.html#heap... V8 blog post about GC: https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting
  - singularity2001 3y ago
    now that it will be cheaper and more natural to pass data back and forth with JavaScript, are we likely to see Wasm/GC progressively occupying more space in web applications? is there any tracking issue to see when JavaScript will finally be able to read and write Wasm/GC objects? The last time I checked any such attempt would result in an error
    - davexunit 3y ago
      Part of Wasm's capability security model is that JS objects are opaque to Wasm and Wasm objects are opaque to JS. This is a good thing and it doesn't prevent interop. Everyone asks about DOM nodes, so let's use that as an example. In Wasm, you could import a function known locally as $documentGetElementById. The host (JS) could then instantiate the module and provide Document.prototype.getElementById.bind(document) as the implementation of that import. $documentGetElementById's return type would be (ref extern), an opaque reference to a heap object from the host that can now be freely passed around the Wasm module or back to the host. You could then import any other DOM functions that you need to inspect/manipulate these objects. On the flip side, if you have a Wasm object reference in JS, you need to call some exported Wasm function(s) to inspect/manipulate it.
      - singularity2001 3y ago
phendrenad2 3y ago
Wrong. WASM is just a bytecode format. There's nothing new here compared to JVM, Parrot, CLR, whatever other VM bytecode formats have been dreamed up. A lot of people have imagined that WASM (or eBPF, but that's another can of worms) somehow has some magic sauce that enables it to guarantee correctness or process isolation. The truth is your sandbox is only as good as the weakest link in (1) Your sandbox runtime (2) Your RPC/API call protocol that you're using to control the outside world from within your sandbox, which everyone has to build from scratch.
- rdtsc 3y ago
  Sure it is bytecode but runs in the browser. That's the magic bit. Clients don't have to install .net, java, etc. And because it can be a target for some compiled languages, we can play cool games built in C and such in the browser. It also has this property that it makes for very cool demos. It may be useful or not in larger production environments, but it's hard to deny that it looks cool when being showed off. The danger is when someone in charge becomes enamored by it and now the whole 20 person team is spending the next two years rewriting a production system in it.
  - phendrenad2 3y ago
    Most of the exuberance over WASM (including in this article) is over the potential for running it outside of the browser, such as (apparently) in IoT devices (this article) or as a Docker replacement[1]. For the record, I think WASM is a good idea in the browser (but is still of limited usability until they add direct DOM manipulation, and I feel like someone is intentionally blocking that) [1] - https://news.ycombinator.com/item?id=34078737 https://news.ycombinator.com/item?id=34078737
  - gwervc 3y ago
    > Sure it is bytecode but runs in the browser. About half if not more posts are about WASI (WebAssembly outside the browser). There really isn't anything new to justifying the level of hype; bytecode or code running in the browser already have been done and eventually removed decades ago (respectively Java applets and ActiveX).
scotty79 3y ago
WebAssembly is bringing the opacity of the apps to the web. Too many people learned how the sausage is made by clicking "View Source". Of course the ship has mostly sailed already with all the layers of abstraction but WebAssembly will be a nice funeral wreath.
zilti 3y ago
I still hope for WASM to get its own rendering facility, and to ultimately enable what JavaFX almost did: make true desktop applications run in the browser, enabling users to drag them out of the browser to have them as actual, integrated desktop programs.
- actionfromafar 3y ago
  Why don't I like this idea? Another OS in the OS.
titzer 3y ago
Andy is spot-on, as usual. Wasm is a software-defined abstraction boundary, possibly the most bullet-proof software-defined abstraction boundary yet to date, given the formal specification and machine-checked proofs of correctness. It has memory sandboxing properties that are easily and efficiently implementable on hardware, and it is low-level enough to run low-level languages at speeds very close to native compilation. Others in the thread make analogies to things like the JVM, CLR, Parrot, Ocaml bytecode, and other things. None of those things have the rigor that Wasm has or are low-level enough to be an abstraction over hardware. And all of those come with ambient capabilities or language concepts that implicitly couple applications with the runtime system and/or other applications. Wasm by its API-less core spec does not. This was 100% intentional. Andy mentioned WALI briefly in the article. We designed WALI to be a similar kind of "just one step up from the bottom" abstraction; if you're running on Linux, then the Wasm engine exposes a memory-sandboxed Linux syscall set with the exact same semantics (effectively pass-through), that allows building abstractions and security one layer up (outside of the engine).
- simonebrunozzi 3y ago
  Have you ever considered building something like "Core War" [0] as a way to help people learn WebAssembly while having fun? I played with it in the late 80s and that's how I learned some Assembly before I was a teenager. [0]: https://en.wikipedia.org/wiki/Core_War https://en.wikipedia.org/wiki/Core_War Edit: I meant Red Code, but that led to Assembly.
- GeorgeTirebiter 3y ago
  Given WASM's goodness, has anyone built a WASM-cpu? that is, WASM as the assembly language (instead of x86, arm, risc-v)? Heck, does that even make sense?
  - aseipp 3y ago
    It could be done but it likely wouldn't perform well or be very useful (because the software surrounding the application also needs to exist.) The IR notably has a lot of indirections in the way e.g. function calls are represented (indirect call through a table which then refers to the module it needs to call), it's stack based, stuff like that. Realistically speaking you are just better off targeting a compiler to whatever instruction set you have, because writing a (basic) compiler isn't too difficult. You can even just use wasm2c and then run a C compiler on it, assuming one exists for your target...
thot_experiment 3y ago
I agree with this, but even if you internalize this it's still very easy to miss the point of web assembly. People often talk about web assembly with hope that it will "free them from javascript". This is missing the point, the beauty of web assembly is that you can keep your scaffolding in javascript, something it's extremely good at, and have your performance too by calling into "native code" as a sort of half-ffi. In short I think compiling whole ass programs into wasm is trash, but when you compile little libraries, or even individual functions and then call them transparently from JS, that's when it really shines. Being able to "natively" perform computations on data, and then spit the results back into a terse, expressive language like javascript in such a tightly integrated way is heterogeneous programming at it's best.
taeric 3y ago
I find this explanation to still be non-compelling. I'm willing to believe I will be wrong and that this will still be the future. I just can't bring myself to think that people today will do any better of a job at defining what and how computing pieces will fit together any better than a few of the other attempts in the past. More, I'm not at all clear that this is something we even need to solve. Standardized interconnect? Great idea. There will almost certainly be many such standardized connections. Standardized compute? I'm less sold. A large part of the decisions that go into how some compute is done is about making tradeoffs appropriate for a use case. Not finding the universally correct tradeoff. Worse, if this is about sneaking compute into otherwise static data, as the example of fonts indicates, then a big no thank you from me. I am not too worried about "accidentally Turing complete," all told. But I also don't see the point in giving up and aiming for it everywhere. The idea that you could maybe have portable extensions for stuff like GIMP is somewhat compelling. But... we have come a long way with safely allowing plugins without needing a whole new definition. This reminds me of the microkernel debate and how it ignores loadable modules for the kernel.
irq-1 3y ago
> There is little point in using WebAssembly if you control both sides of a boundary Mozilla is using this to secure native dependencies: the WASM boundary ensures the memory and function access is correct. https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... > The core implementation idea behind wasm sandboxing is that you can compile C/C++ into wasm code, and then you can compile that wasm code into native code for the machine your program actually runs on.
edelsohn 3y ago
I'm surprised that he didn't mention Nebulet microkernel running WASM.
krackers 3y ago
Every day the predictions from that "Birth and Death of Javascript" talk become closer to reality
apatheticonion 3y ago
For the library world, WASM aims to offer an alternative to dynamically loaded C libraries - which it doesn't really do yet. For the container world, WASM aims to offer an architecture agnostic universal binary format that can be run anywhere - which it doesn't really do yet. For the web world, WASM aims to offer ~~not exactly sure~~. People say it's not a replacement for JavaScript and refuse to consider it as at least an additive alternative. So I guess WASM in the web is something like an enhanced Web Worker that allows hot paths to be optimized using lower level languages? That said, WASM in the browser doesn't support threads (and likely won't because of restrictive security permissions on the web making memory shared between threads impractical). Perhaps the use case for WASM is simply enabling the consumption of existing C/C++ libraries on the web (like ffmpeg) that would otherwise be impractical to port to JavaScript? When you think about it, WASM was announced almost a decade ago. Golang had just released version 1. JavaScript didn't have Promises or ES Modules in the specification. Mozilla announced it was backing Rust and it had its first stable release. Feels like WASM hasn't really progressed that much in that time. For me, I would love a world where web technology powered _applications_ (not blogs posts or static sites) were PWAs backed by efficient WASM implementations (think; Slack, Discord, VSCode, JIRA, etc). Instead we get everything written as Electron apps and even if you want to use WASM, you're limited to a single thread that can't even create a div. I guess having amazing, efficient, cross platform desktop application experiences enabled by capable web technologies would compete too effectively with native apps, Flutter, WinUI or whatever other competing interests exist. If anything, I would consider calling that scenario an actual "Web 3.0" - but it's probably a pipe dream at this point.
- circuit10 3y ago
  “People say it's not a replacement for JavaScript and refuse to consider it as at least an additive alternative.” It’s not a complete replacement yet but you can write the vast majority of your code in WASM and use JS as glue code if you want. “That said, WASM in the browser doesn't support threads” That’s… not true? It has been supported in all major browsers for years
  - apatheticonion 3y ago
mediumsmart 3y ago
Having a point to miss would be great news for WebAssembly.
zubairq 3y ago
I learnt something important about webassembly today from this. Thank you!

199 points by ryukafalz 3y ago

singularity2001 3y ago

how to handle gc strings when most tools don't support wasm stringref?

davexunit 3y ago
Yeah the strings situation isn't so good right now. stringref is really good imo but different factions in the wasm group are opposed. The best way to represent strings right now is (array (mut i8)) for UTF-8 or WTF-8 data. In Guile Hoot we are using stringref because it's convenient for the compiler to be able to emit (string.const "foo") and such, but we then perform a post-pass to remove all stringref instructions and replace them with instructions that operate on i8 arrays so the resulting binaries are usable. This approach has the advantage that string contents are visible to wasm so internal string manipulation is fast, but the downside is that strings have to be copied when going across the host/wasm boundary. An alternative approach would be to fully rely on the host to provide strings utilizing extern refs. This avoids the copying at the boundary problem of the first approach, but it has the disadvantage that all string operations need to call the host, so internal string manipulation is slow.

gwbas1c 3y ago

WebAssembly allows you to program web pages in a language other than Javascript. The above statement might gloss over a lot of very important details: But that mindset also misses the point: The critical use case of WebAssembly, and the problem it attempted to solve, right now, is to creating a webpage in a language other than JavaScript. Everything else that the article mentions is an impressive feat on its own, but what WebAssembly could do is very different than what it does now. And the fact that now you can program a website in a language other than Javascript (or TypeScript) is a very tangible accomplishment that people who aren't enamored with computer science can appreciate, understand, and repeat.

bryanlarsen 3y ago
There are many places that have been using WASM for purposes similar to the ones in the article for quite a while now. For example, Cloudflare workers have been using WASM for a year and a half.
- steveklabnik 3y ago
  Workers has supported WASM since 2018: https://blog.cloudflare.com/webassembly-on-cloudflare-workers https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
jauntywundrkind 3y ago
I'm both excited about cross-language but also I think the people you describe as potential beneficiaries are those most apt to suffer under the new (anti-)regime. > And the fact that now you can program a website in a language other than Javascript (or TypeScript) is a very tangible accomplishment that people who aren't enamored with computer science can appreciate, understand, and repeat. Industrial software dev has resulted in gross difficult minified bundles & absurdities like vdom that are hard to view-source hack. But there's pretty ok un-minifying & it's surprisingly possible to get really far, if a user wants to seize the power & do some userscripting. And many in the webdev world have steadily been trying to push back against this rampant industrialization. HTTP2 and ESM were hopefully going to make unbundling more viable, but that's still long suffering (ex: import-maps don't work for workers, https://github.com/WICG/import-maps/issues/2 https://github.com/WICG/import-maps/issues/2), and now that the http cache doesn't work cross-site many of the possible re-use upsides are dead. Still a goal for many though. WebComponents is still a vast un-frameworking potential; in many implementations it unravels the descent into abstraction that React framework begat. Classic web devs have a lot of heart to make the web pro-user, to un-framework things, but the industrial demands are hard to re-satisfy on these better paths & so much momentum is elsewhere. Now compare to the wasm world. We have basically pure machine code running our web in wasm. It's utterly unintelligible. There's dozens of hundred of kb libraries that languages bring in to userland just to do the language thing. I think people will have an incredibly poor time learning the web, think the worst risk wasm has is in scaring people off from view-source, from casually observing & learning anything. Wasm is god smiting the tower of Babel, is a one language breaking & being cast down & a hundred different tribes speaking their own language. So much good will come from this diversity, we'll see so many different styles & tries from so many camps, and that will be a benefit, but it will in my view be drastically harder for those "who aren't enamored with computer science can appreciate, understand, and repeat." Intelligibility is the loser, when Babel falls.

neilalexander 3y ago

It is strange to me to see so much talk about all of the places WebAssembly could live, like IoT devices and edge lambdas and cross-architecture binaries, places that don't really need these problems to be solved, and yet so little talk about whether or not it can finally unshackle the web from the mess that is JavaScript. As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity.

danielvaughn 3y ago
It can perform a lot of computational work, but yeah it can't yet interface directly with the DOM. I'm not sure about whether it can access the network or other things, but I don't believe that it can.
- deleted 3y ago
  [deleted]
- edgyquant 3y ago
  Are there plans to add DOM support? That seems pretty critical for what I had thought wasm was supposed to be myself.
  - danielvaughn 3y ago
    I'm not sure. All I know is that there are some hurdles to get past. One of them is that several DOM APIs were created specifically for JavaScript, which is...really disheartening.
  - davexunit 3y ago
    Wasm allows for importing host functions. Those host functions could provide DOM access. With Wasm GC it is possible to pass external references (DOM nodes, promises, etc.) to and from Wasm. What this looks like in practice is that a thin JS bootstrap script instantiates the Wasm module, passing along a set of JS functions that map to the declared Wasm imports and then the program is effectively driven from Wasm at that point.

MichaelMug 3y ago

Where can I find more information about managed data types in WebAssembly?

davexunit 3y ago
GC managed types? Wasm GC spec: https://webassembly.github.io/gc/core/index.html https://webassembly.github.io/gc/core/index.html Heap types in particular: https://webassembly.github.io/gc/core/syntax/types.html#heap-types https://webassembly.github.io/gc/core/syntax/types.html#heap... V8 blog post about GC: https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting
- singularity2001 3y ago
  now that it will be cheaper and more natural to pass data back and forth with JavaScript, are we likely to see Wasm/GC progressively occupying more space in web applications? is there any tracking issue to see when JavaScript will finally be able to read and write Wasm/GC objects? The last time I checked any such attempt would result in an error
  - davexunit 3y ago
    Part of Wasm's capability security model is that JS objects are opaque to Wasm and Wasm objects are opaque to JS. This is a good thing and it doesn't prevent interop. Everyone asks about DOM nodes, so let's use that as an example. In Wasm, you could import a function known locally as $documentGetElementById. The host (JS) could then instantiate the module and provide Document.prototype.getElementById.bind(document) as the implementation of that import. $documentGetElementById's return type would be (ref extern), an opaque reference to a heap object from the host that can now be freely passed around the Wasm module or back to the host. You could then import any other DOM functions that you need to inspect/manipulate these objects. On the flip side, if you have a Wasm object reference in JS, you need to call some exported Wasm function(s) to inspect/manipulate it.
    - singularity2001 3y ago

phendrenad2 3y ago

Wrong. WASM is just a bytecode format. There's nothing new here compared to JVM, Parrot, CLR, whatever other VM bytecode formats have been dreamed up. A lot of people have imagined that WASM (or eBPF, but that's another can of worms) somehow has some magic sauce that enables it to guarantee correctness or process isolation. The truth is your sandbox is only as good as the weakest link in (1) Your sandbox runtime (2) Your RPC/API call protocol that you're using to control the outside world from within your sandbox, which everyone has to build from scratch.

rdtsc 3y ago
Sure it is bytecode but runs in the browser. That's the magic bit. Clients don't have to install .net, java, etc. And because it can be a target for some compiled languages, we can play cool games built in C and such in the browser. It also has this property that it makes for very cool demos. It may be useful or not in larger production environments, but it's hard to deny that it looks cool when being showed off. The danger is when someone in charge becomes enamored by it and now the whole 20 person team is spending the next two years rewriting a production system in it.
- phendrenad2 3y ago
  Most of the exuberance over WASM (including in this article) is over the potential for running it outside of the browser, such as (apparently) in IoT devices (this article) or as a Docker replacement[1]. For the record, I think WASM is a good idea in the browser (but is still of limited usability until they add direct DOM manipulation, and I feel like someone is intentionally blocking that) [1] - https://news.ycombinator.com/item?id=34078737 https://news.ycombinator.com/item?id=34078737
- gwervc 3y ago
  > Sure it is bytecode but runs in the browser. About half if not more posts are about WASI (WebAssembly outside the browser). There really isn't anything new to justifying the level of hype; bytecode or code running in the browser already have been done and eventually removed decades ago (respectively Java applets and ActiveX).

scotty79 3y ago

WebAssembly is bringing the opacity of the apps to the web. Too many people learned how the sausage is made by clicking "View Source". Of course the ship has mostly sailed already with all the layers of abstraction but WebAssembly will be a nice funeral wreath.

zilti 3y ago

I still hope for WASM to get its own rendering facility, and to ultimately enable what JavaFX almost did: make true desktop applications run in the browser, enabling users to drag them out of the browser to have them as actual, integrated desktop programs.

actionfromafar 3y ago
Why don't I like this idea? Another OS in the OS.

titzer 3y ago

Andy is spot-on, as usual. Wasm is a software-defined abstraction boundary, possibly the most bullet-proof software-defined abstraction boundary yet to date, given the formal specification and machine-checked proofs of correctness. It has memory sandboxing properties that are easily and efficiently implementable on hardware, and it is low-level enough to run low-level languages at speeds very close to native compilation. Others in the thread make analogies to things like the JVM, CLR, Parrot, Ocaml bytecode, and other things. None of those things have the rigor that Wasm has or are low-level enough to be an abstraction over hardware. And all of those come with ambient capabilities or language concepts that implicitly couple applications with the runtime system and/or other applications. Wasm by its API-less core spec does not. This was 100% intentional. Andy mentioned WALI briefly in the article. We designed WALI to be a similar kind of "just one step up from the bottom" abstraction; if you're running on Linux, then the Wasm engine exposes a memory-sandboxed Linux syscall set with the exact same semantics (effectively pass-through), that allows building abstractions and security one layer up (outside of the engine).

simonebrunozzi 3y ago
Have you ever considered building something like "Core War" [0] as a way to help people learn WebAssembly while having fun? I played with it in the late 80s and that's how I learned some Assembly before I was a teenager. [0]: https://en.wikipedia.org/wiki/Core_War https://en.wikipedia.org/wiki/Core_War Edit: I meant Red Code, but that led to Assembly.
GeorgeTirebiter 3y ago
Given WASM's goodness, has anyone built a WASM-cpu? that is, WASM as the assembly language (instead of x86, arm, risc-v)? Heck, does that even make sense?
- aseipp 3y ago
  It could be done but it likely wouldn't perform well or be very useful (because the software surrounding the application also needs to exist.) The IR notably has a lot of indirections in the way e.g. function calls are represented (indirect call through a table which then refers to the module it needs to call), it's stack based, stuff like that. Realistically speaking you are just better off targeting a compiler to whatever instruction set you have, because writing a (basic) compiler isn't too difficult. You can even just use wasm2c and then run a C compiler on it, assuming one exists for your target...

thot_experiment 3y ago

I agree with this, but even if you internalize this it's still very easy to miss the point of web assembly. People often talk about web assembly with hope that it will "free them from javascript". This is missing the point, the beauty of web assembly is that you can keep your scaffolding in javascript, something it's extremely good at, and have your performance too by calling into "native code" as a sort of half-ffi. In short I think compiling whole ass programs into wasm is trash, but when you compile little libraries, or even individual functions and then call them transparently from JS, that's when it really shines. Being able to "natively" perform computations on data, and then spit the results back into a terse, expressive language like javascript in such a tightly integrated way is heterogeneous programming at it's best.

taeric 3y ago

I find this explanation to still be non-compelling. I'm willing to believe I will be wrong and that this will still be the future. I just can't bring myself to think that people today will do any better of a job at defining what and how computing pieces will fit together any better than a few of the other attempts in the past. More, I'm not at all clear that this is something we even need to solve. Standardized interconnect? Great idea. There will almost certainly be many such standardized connections. Standardized compute? I'm less sold. A large part of the decisions that go into how some compute is done is about making tradeoffs appropriate for a use case. Not finding the universally correct tradeoff. Worse, if this is about sneaking compute into otherwise static data, as the example of fonts indicates, then a big no thank you from me. I am not too worried about "accidentally Turing complete," all told. But I also don't see the point in giving up and aiming for it everywhere. The idea that you could maybe have portable extensions for stuff like GIMP is somewhat compelling. But... we have come a long way with safely allowing plugins without needing a whole new definition. This reminds me of the microkernel debate and how it ignores loadable modules for the kernel.

irq-1 3y ago

> There is little point in using WebAssembly if you control both sides of a boundary Mozilla is using this to secure native dependencies: the WASM boundary ensures the memory and function access is correct. https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... > The core implementation idea behind wasm sandboxing is that you can compile C/C++ into wasm code, and then you can compile that wasm code into native code for the machine your program actually runs on.

edelsohn 3y ago

I'm surprised that he didn't mention Nebulet microkernel running WASM.

krackers 3y ago

Every day the predictions from that "Birth and Death of Javascript" talk become closer to reality

apatheticonion 3y ago

For the library world, WASM aims to offer an alternative to dynamically loaded C libraries - which it doesn't really do yet. For the container world, WASM aims to offer an architecture agnostic universal binary format that can be run anywhere - which it doesn't really do yet. For the web world, WASM aims to offer ~~not exactly sure~~. People say it's not a replacement for JavaScript and refuse to consider it as at least an additive alternative. So I guess WASM in the web is something like an enhanced Web Worker that allows hot paths to be optimized using lower level languages? That said, WASM in the browser doesn't support threads (and likely won't because of restrictive security permissions on the web making memory shared between threads impractical). Perhaps the use case for WASM is simply enabling the consumption of existing C/C++ libraries on the web (like ffmpeg) that would otherwise be impractical to port to JavaScript? When you think about it, WASM was announced almost a decade ago. Golang had just released version 1. JavaScript didn't have Promises or ES Modules in the specification. Mozilla announced it was backing Rust and it had its first stable release. Feels like WASM hasn't really progressed that much in that time. For me, I would love a world where web technology powered _applications_ (not blogs posts or static sites) were PWAs backed by efficient WASM implementations (think; Slack, Discord, VSCode, JIRA, etc). Instead we get everything written as Electron apps and even if you want to use WASM, you're limited to a single thread that can't even create a div. I guess having amazing, efficient, cross platform desktop application experiences enabled by capable web technologies would compete too effectively with native apps, Flutter, WinUI or whatever other competing interests exist. If anything, I would consider calling that scenario an actual "Web 3.0" - but it's probably a pipe dream at this point.

circuit10 3y ago
“People say it's not a replacement for JavaScript and refuse to consider it as at least an additive alternative.” It’s not a complete replacement yet but you can write the vast majority of your code in WASM and use JS as glue code if you want. “That said, WASM in the browser doesn't support threads” That’s… not true? It has been supported in all major browsers for years
- apatheticonion 3y ago

mediumsmart 3y ago

Having a point to miss would be great news for WebAssembly.

zubairq 3y ago

I learnt something important about webassembly today from this. Thank you!