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).
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?
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.
> 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.
It was always the goal for WebAssembly code living in the browser to have some form of object model/DOM integration, and interaction with JavaScript objects. What form it would take exactly wasn't clear. But that was never a goal for the original 1.0 specification (MVP), and not even in spec for the current 2.0 draft -- which mostly add a bunch more useful instructions and features, but nothing earth shattering.
The reality is that whatever solution gets accepted has to be supported and continue working for what is effectively ~infinite time, in multiple major browser engines. For custom runtimes it's sort of "whatever", but webpages can live forever so it's taking a lot of time to get right. But there was clearly a lot of value to be had without that, hence 1.0 was the "MVP."
While I don't necessarily agree with the unnecessary, unsupported, casual, & cheap (provided with zero substantiating/contestable support) contempt culture here ("unshackle the web from the mess that is JavaScript", "places that don't really need these problems to be solved")...
WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements.
A preview-2 should be arriving sometime somewhat soon.
It's just hard work. It's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.
Wasm isn't a replacement for JavaScript. I think it's clever to leverage JavaScript as an interface to an ever-changing and extremely broad suite of native browser APIs, and keep Wasm small, fast, and secure.
> 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.
But overall, yeah, it feels like a shiny new toy everyone is excited about and wants to use. Some toys can be fun to play with, but it doesn't mean we have to rewrite production systems in it. Sometimes, or most of the time, toys don't become useful tools.
The main problem is that either you compile a WASM binary or you serve a big language runtime (itself compiled to WASM) all the time: this is what you'd have to do if using C# or Java for example (maybe you can use TeaVM, but maybe you can't).
For some reason browsers didn't want to "balkanize the web" for the really good reason of supporting multiple languages, they wanted to do it for very petty reasons like WebMIDI or wildly differing implementations of LocalStorage (e.g. how much you can put in there), or non-overlapping support for video codecs, etc etc etc.
Yep, we are still generating bindings, but I don’t think that’s going to change anytime soon. WebAssembly to JavaScript is what the C ABI is to Python, with an additional bounce back to JavaScript land.
I think once WasmGC is finished up, that will make shipping a VM inside a VM more viable. Opening up direct access to the DOM would be cool, but if it were up to me, I'd just skip it and render everything inside a <canvas/> and avoid all of the "build an application on top of a document format" crap that makes web apps so weird to make.
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.
A lot of use cases are applications that don't technically require a DOM but maybe just the ability to copy and paste text.
The biggest thing is some kind of graphics capability.
What I think happened, if you look at the web assembly design discussions, is that they made the initially correct decision to limit the scope to be more manageable, but then over the years that decision became something of a religion and even a strange badge of honor.
"Web assembly is not meant to replace JavaScript". It certainly is challenging to try to standardized on anything like device input or graphics APIs, but after say three years, competent and sane designers obviously should have been working on that.
Maybe I am a conspiracy theorist (I am) but I sometimes suspect that Google has deliberately limited the scope of web assembly in order to maintain the control that the dominance of Chrome provides them. Because if things like keyboard/mouse and graphics had some type of web assembly standard, then it would be easy for different runtimes to support them. Then before you know it, you don't need the browser for most things, you can just use your favorite web assembly runtime.
I will go so far as to suggest that this is an antitrust issue and that a technically competent government (of which maybe non exist so far) would have somehow forced the development of an evolvable shared standard like web assembly that is not missing important pieces like graphics.
I see web assembly as the obvious successor to Java. It's been held back by some strange psychology and maybe even intentional sabotage.
While there is valid criticism of JS, I am not sure if I really want binary blobs executed in my browser.
Sure, for applications that really need to strip the overhead of a scripting language, it is very welcome. But for the average website? Not sure about it...
And security is another matter, there is a reason the WebAssembly sandbox is so restrictive.
Webassembly is awesome, but the solution needs to fit the problem.
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.
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.
> There's nothing new here compared to JVM, Parrot, CLR, whatever other VM bytecode formats have been dreamed up.
WASM is far more low-level than those. It does not depend on the semantics of any existing programming language, and while it does sandbox the code it does not focus on providing mechanisms for establishing memory safety other than at the module level. The focus is almost solely on minimizing overhead compared to native code, even the GC implementation is kept as simple and efficient as possible.
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.
> There's nothing new here compared to ... whatever other VM bytecode formats have been dreamed up
Well, there is: it was designed to be easy for already mature V8's codebase to adopt as a low-level IR, with minimal changes (e.g. V8 keeps the JS AST more or less intact during the codegen, it doesn't lower it into 3-address code or anything like that, so WASM too has structured loops and blocks but no general "goto"). Other VMs, I believe, were developed after the bytecode design for them was done.
> 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.
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.
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.
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.
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.
I'd argue that's actually besides the point. Before WebAssembly there were plenty of good ways to write web apps in a language other than JavaScript. Some for example integrate it into the language tooling (like ClojureScript which I have used and have fond memories of), some simply directly used asm.js (which I have also used).
So if the only use case of WebAssembly is to enable that, it is an utterly unexciting piece of incremental improvement.
Maybe we're just splitting hairs on what it means to be "a webpage", but I feel like people are _not_ writing webpages in WebAssembly. Instead, you get video games, interactive animations, photo editing apps, ... Basically, desktop-app like things, but generally without a DOM, without CSS. The look and feel diverges quite strongly, a user kind of intuits they're no longer in a regular web-app.
To my frustration, WebAssembly is not replacing JS/TS and it's abominable toolchains, it ends up delivering a new suite of experiences, by adding another layer of abominable toolchains.
There's also low level "helper"-libraries getting developed in WASM, e.g. a database implementation, but wondering if that ever takes off, managing bindings is rough and library size/bootstrapping can end up bloated. And it certainly does't get us out of JS/TS-dev land.
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.
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), 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.
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.
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.
[+] [-] titzer|2 years ago|reply
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).
[+] [-] GeorgeTirebiter|2 years ago|reply
[+] [-] simonebrunozzi|2 years ago|reply
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
Edit: I meant Red Code, but that led to Assembly.
[+] [-] subtra3t|2 years ago|reply
[+] [-] neilalexander|2 years ago|reply
[+] [-] aseipp|2 years ago|reply
It was always the goal for WebAssembly code living in the browser to have some form of object model/DOM integration, and interaction with JavaScript objects. What form it would take exactly wasn't clear. But that was never a goal for the original 1.0 specification (MVP), and not even in spec for the current 2.0 draft -- which mostly add a bunch more useful instructions and features, but nothing earth shattering.
The reality is that whatever solution gets accepted has to be supported and continue working for what is effectively ~infinite time, in multiple major browser engines. For custom runtimes it's sort of "whatever", but webpages can live forever so it's taking a lot of time to get right. But there was clearly a lot of value to be had without that, hence 1.0 was the "MVP."
[+] [-] jauntywundrkind|2 years ago|reply
WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements.
Long running effort, but it's hard work and there's just not that many hands available for this deep work. Some assorted links with more: https://github.com/WebAssembly/component-model https://www.fermyon.com/blog/webassembly-component-model https://thenewstack.io/can-webassembly-get-its-act-together-...
A preview-2 should be arriving sometime somewhat soon.
It's just hard work. It's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.
[+] [-] CharlesW|2 years ago|reply
[+] [-] rdtsc|2 years ago|reply
That's the underlying messy API it's built on. There are specs to make the API more standardized like https://github.com/WebAssembly/WASI
But overall, yeah, it feels like a shiny new toy everyone is excited about and wants to use. Some toys can be fun to play with, but it doesn't mean we have to rewrite production systems in it. Sometimes, or most of the time, toys don't become useful tools.
[+] [-] camgunz|2 years ago|reply
For some reason browsers didn't want to "balkanize the web" for the really good reason of supporting multiple languages, they wanted to do it for very petty reasons like WebMIDI or wildly differing implementations of LocalStorage (e.g. how much you can put in there), or non-overlapping support for video codecs, etc etc etc.
[+] [-] evrimoztamur|2 years ago|reply
[+] [-] zengid|2 years ago|reply
[+] [-] danielvaughn|2 years ago|reply
[+] [-] ilaksh|2 years ago|reply
The biggest thing is some kind of graphics capability.
What I think happened, if you look at the web assembly design discussions, is that they made the initially correct decision to limit the scope to be more manageable, but then over the years that decision became something of a religion and even a strange badge of honor.
"Web assembly is not meant to replace JavaScript". It certainly is challenging to try to standardized on anything like device input or graphics APIs, but after say three years, competent and sane designers obviously should have been working on that.
Maybe I am a conspiracy theorist (I am) but I sometimes suspect that Google has deliberately limited the scope of web assembly in order to maintain the control that the dominance of Chrome provides them. Because if things like keyboard/mouse and graphics had some type of web assembly standard, then it would be easy for different runtimes to support them. Then before you know it, you don't need the browser for most things, you can just use your favorite web assembly runtime.
I will go so far as to suggest that this is an antitrust issue and that a technically competent government (of which maybe non exist so far) would have somehow forced the development of an evolvable shared standard like web assembly that is not missing important pieces like graphics.
I see web assembly as the obvious successor to Java. It's been held back by some strange psychology and maybe even intentional sabotage.
[+] [-] raxxorraxor|2 years ago|reply
Sure, for applications that really need to strip the overhead of a scripting language, it is very welcome. But for the average website? Not sure about it...
And security is another matter, there is a reason the WebAssembly sandbox is so restrictive.
Webassembly is awesome, but the solution needs to fit the problem.
[+] [-] holoduke|2 years ago|reply
[+] [-] moralestapia|2 years ago|reply
well_thats_your_opinion.jpeg
Javascript is great and the web became what it is today because of it, not in spite of it.
[+] [-] taeric|2 years ago|reply
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.
[+] [-] phendrenad2|2 years ago|reply
[+] [-] zozbot234|2 years ago|reply
WASM is far more low-level than those. It does not depend on the semantics of any existing programming language, and while it does sandbox the code it does not focus on providing mechanisms for establishing memory safety other than at the module level. The focus is almost solely on minimizing overhead compared to native code, even the GC implementation is kept as simple and efficient as possible.
[+] [-] rdtsc|2 years ago|reply
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.
[+] [-] Joker_vD|2 years ago|reply
Well, there is: it was designed to be easy for already mature V8's codebase to adopt as a low-level IR, with minimal changes (e.g. V8 keeps the JS AST more or less intact during the codegen, it doesn't lower it into 3-address code or anything like that, so WASM too has structured loops and blocks but no general "goto"). Other VMs, I believe, were developed after the bytecode design for them was done.
[+] [-] munificent|2 years ago|reply
Steel-reinforced concrete is "just" another building material, but what you can do with it in practice is very different from wattle and daub.
[+] [-] pjmlp|2 years ago|reply
[+] [-] irq-1|2 years ago|reply
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-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.
[+] [-] scotty79|2 years ago|reply
[+] [-] apatheticonion|2 years ago|reply
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|2 years ago|reply
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
[+] [-] MichaelMug|2 years ago|reply
[+] [-] davexunit|2 years ago|reply
Wasm GC spec: https://webassembly.github.io/gc/core/index.html
Heap types in particular: https://webassembly.github.io/gc/core/syntax/types.html#heap...
V8 blog post about GC: https://v8.dev/blog/wasm-gc-porting
[+] [-] krackers|2 years ago|reply
[+] [-] thot_experiment|2 years ago|reply
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.
[+] [-] gwbas1c|2 years ago|reply
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.
[+] [-] kccqzy|2 years ago|reply
So if the only use case of WebAssembly is to enable that, it is an utterly unexciting piece of incremental improvement.
Everything that's exciting about WebAssembly comes from where it can be used besides replacing JavaScript in a browser. It's a point I've repeatedly argued on this forum since two years ago (see https://news.ycombinator.com/item?id=30156799 and https://news.ycombinator.com/item?id=38138739)
[+] [-] trgn|2 years ago|reply
To my frustration, WebAssembly is not replacing JS/TS and it's abominable toolchains, it ends up delivering a new suite of experiences, by adding another layer of abominable toolchains.
There's also low level "helper"-libraries getting developed in WASM, e.g. a database implementation, but wondering if that ever takes off, managing bindings is rough and library size/bootstrapping can end up bloated. And it certainly does't get us out of JS/TS-dev land.
[+] [-] bryanlarsen|2 years ago|reply
[+] [-] jauntywundrkind|2 years ago|reply
> 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), 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.
[+] [-] edelsohn|2 years ago|reply
[+] [-] zubairq|2 years ago|reply
[+] [-] zilti|2 years ago|reply
[+] [-] actionfromafar|2 years ago|reply
[+] [-] mediumsmart|2 years ago|reply
[+] [-] singularity2001|2 years ago|reply
[+] [-] davexunit|2 years ago|reply
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.