I think GP was referring to running wasm directly rather than using (as your website does with WebAssembly.instantiateStreaming) JS APIs to bootstrap it and JS APIs every time it needs to do something with the browser's built-in functionality (like manipulate the DOM).
instantiateStreaming is not the problem; the problem is that JS code is necessary (via that function or another) to execute WASM, and JS is necessary to call back from WASM into browser APIs. Because of that, WASM in the browser is, at present, effectively a JavaScript extension language, and it cannot meet the goals discussed by Crockford in TFA.
This hybrid approach that requires JS both at bootstrap and browser-API-interaction time significantly undercuts the benefits of WASM as a javascript replacement for several reasons. Some of those reasons are: this likely means JS will remain supported/enabled/required-for-many-sites in browsers, warts and all, in perpetuity; the advantages of WASM's sandboxability will be mitigated by the presence of a much more permissive runtime that must be present in order to load and run WASM artifacts; more performant/parallel access to browser APIs will remain difficult or impossible; multi-language/multi-build system competence will be needed due to large parts of the ecosystem remaining in browser JS.
Not only that. The DOM API and general browser APIs are designed with JS semantics in mind, and for JS. Just like the UNIX APIs are designed in C and expect to be called from C.
So even if you get other languages working alright on browsers, they are always going to be second-class citizens IMO, because they are going to be interfacing with JS APIs.
I can't think of a way to avoid this TBH, other than designing a different API for the new language, at which point i think we'd be no longer talking about the web as we know it.
ok but I still don't understand why it's not a great idea for everyone to embrace WASM as it is today and write your frontend logic in go or rust EVEN if you have to use instantiateStreaming.
You'd still need to interface with the JS APIs, wouldn't you?
For example, an API like `Element.prototype.addEventListener(string, callback)` wouldn't make much sense in Rust, IDK about Go. Sure, you can make it work, but you'll always be rubbing against an API that was not designed for that language. Hell, addEventListener isn't even on the Element prototype, but on the EventTarget prototype, which Element.prototype inherits from. And that's something else that wouldn't make sense at all in Rust: prototypical inheritance. But it's part of the DOM API. It's part of the web. So we'd have to deal with it too, even if we switch to a new language.
Does this make some sense? I feel like i'm repeating what's been said before in this comment chain, so maybe i'm missing something about what you're not understanding (:
here's example coding frontend in go. I think I've achieved with vote.go and register.go and timer.go above a nice way in Go to do Javascript things. I don't feel limited.
but I'm still able to write lots of logic in Go and escape having to use the "bad language". I feel like despite the above there is still big wins by just having no application logic written in javascript or typescript.
I think what the original comment means is that WASM is heavily sandboxed in the browser environment, and cannot interact with the DOM APIs directly. You still need JS for that.
Yeah I know. I don't care if it needs a bit of JS to bootstrap either. At some point it should get to a state where you can have a site with WASM and no JS required.
your code is not manipulating dom. your code is interacting with a library that manipulates the dom. That library has to interface with javascript. You are still doing all dom manipulation via js, it's just hidden behind the library. If you inlined all functions from that library you'd get code that interacts with js.
tldr: no, you can't possibly be doing that. Because an api for it literally, objectively does not exist.
but you are missing the bigger picture no? We can, today, stop writing business logic in javascript/typescript for any frontend code. Yes it will call an api that runs via js. But step 1, stop writing any NEW javascript right?
the wasm-js bridge is quite slow. because wasm is a 2nd class citizen. It's not about which language you write, per se. You wrote those parts in go. Great! Those parts slower because of it, due to this.
oh but not noticeably to the user. Network latency is always what the user perceive as the slow part. Here's a complex site done this way: https://linkscopic.com/space does it feel slow?
WebAssembly itself does not provide synchronous access directly; the interactions with WebAssembly modules in browsers are asynchronous. This is because WebAssembly operations, like module instantiation and function calls, are designed to fit into JavaScript's event-driven, non-blocking model.
