3 ms·

can you link me to example that does wasm in browser without calling instantiateStreaming?

by andrewfromx 2y ago

mvdtnz 2y ago
His entire point is that it can't be done currently.
- andrewfromx 2y ago
  so what's the big problem with calling instantiateStreaming? Explain it to me like i'm 5
  - zbentley 2y ago
    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.
    - andrewfromx 2y ago
      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.
    - epidemian 2y ago
      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.
      - andrewfromx 2y ago
        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.
        epidemian 2y ago
        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 (:
        andrewfromx 2y ago
        https://github.com/andrewarrow/homeducky/blob/main/browser/vote.go https://github.com/andrewarrow/homeducky/blob/main/browser/v... https://github.com/andrewarrow/homeducky/blob/main/browser/register.go https://github.com/andrewarrow/homeducky/blob/main/browser/r... https://github.com/andrewarrow/homeducky/blob/main/browser/timer.go https://github.com/andrewarrow/homeducky/blob/main/browser/t... https://www.youtube.com/watch?v=dxO94MvfRCg https://www.youtube.com/watch?v=dxO94MvfRCg 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.
happytoexplain 2y ago
That's the point.

can you link me to example that does wasm in browser without calling instantiateStreaming?

mvdtnz 2y ago

His entire point is that it can't be done currently.

andrewfromx 2y ago
so what's the big problem with calling instantiateStreaming? Explain it to me like i'm 5
- zbentley 2y ago
  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.
  - andrewfromx 2y ago
    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.
  - epidemian 2y ago
    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.
    - andrewfromx 2y ago
      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.
      - epidemian 2y ago
        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 (:
        andrewfromx 2y ago
        https://github.com/andrewarrow/homeducky/blob/main/browser/vote.go https://github.com/andrewarrow/homeducky/blob/main/browser/v... https://github.com/andrewarrow/homeducky/blob/main/browser/register.go https://github.com/andrewarrow/homeducky/blob/main/browser/r... https://github.com/andrewarrow/homeducky/blob/main/browser/timer.go https://github.com/andrewarrow/homeducky/blob/main/browser/t... https://www.youtube.com/watch?v=dxO94MvfRCg https://www.youtube.com/watch?v=dxO94MvfRCg 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.

happytoexplain 2y ago

That's the point.