6 ms·

I can't tell if the lack of strings and DOM API interop in web assembly is on purpose or not. If it is on purpose, what an absolutely diabolical way to ensure

I can't tell if the lack of strings and DOM API interop in web assembly is on purpose or not. If it is on purpose, what an absolutely diabolical way to ensure javascript language dominance in the browser: give people a way to port their language to the browser, but make it incredibly difficult to do anything.

skitter 5y ago
Afaik for the WebAssembly MVP, the goal was to have a simple, efficient compile target - therefore only integers and floats. To make wasm more useful & easier to integrate, the plan calls for interface types[0], which allow both accessing complex (JS) objects and calling browser APIs. [0] https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p...
- recursivedoubts 5y ago
  interesting, thank you
- runnerup 5y ago
  thank you
franz899 5y ago
WebAssembly's purpose was never to replace JavaScript but only to speed up certain parts of a website/app.
- recursivedoubts 5y ago
  that's not how I remember it: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ edit: from the linked article, in case it isn't clear, an HN comment by eich: "Sure, in userland many languages compile to assembly. Hmm, where have I heard that word lately?"[1] [1] - https://news.ycombinator.com/item?id=9554914 https://news.ycombinator.com/item?id=9554914
- pjmlp 5y ago
  That was the original message used to sell WebAssembly, however when the real goal is to replace ActiveX, Flash, Silverlight and PNaCL it was obvious that it would grew beyond that.
- cubano 5y ago
  really? i thought it's purpose was to take us back to the good old days of sellable proprietary binary blobs instead of the more open HTML/JS/CSS stack.
Deukhoofd 5y ago
The lack of strings makes sense, as many different languages and standard libraries have their own implementations of it, that can behave slightly differently. It now puts the implementation of the string to the compilers/linkers, as is generally the case for assembly as well. The lack of a DOM API is something I sorely miss as well. It's currently possible (and not that hard, you can just interact with JS), but comes with such performance overhead that you lose the entire benefit of WASM.
flohofwoe 5y ago
What type of strings though? Exposing Javascript string objects in WASM doesn't make much sense if the code is expecting C strings for instance. Same for other languages, those all have their own incompatible internal representations for strings. The only somewhat interop-friendly string type is a zero-terminated bag of bytes, usually UTF-8 encoded (aka C strings), but that's a different string representation than Javascript uses. The Emscripten SDK offers helper functions to marshal high level data types like Javascript strings to UTF-8 encoded C strings on the WASM heap and back to JS, so it's not that bad. DOM access can be achieved with helper libraries which call out into JS. And since any sort of DOM manipulation is extremely slow anyway there's not much of a performance difference even with the overhead of calling out from WASM into JS (which actually is quite fast nowadays).
- mamcx 5y ago
  >What type of strings though? The good one! UTf-8, NOT null terminated, pascal like. ie: what rust have: https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html REPEAT the mistakes of C (and considering the security angle! in a browser!) must be a big no.
  - masklinn 5y ago
    > UTf-8, NOT null terminated, pascal like. > > ie: what rust have: > > https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html Rust (or C++) strings are not pascal strings. In pascal strings, the "string buffer" also contains the length information, and historically it was all bytes with a length byte at the start, which was why your strings started at index 1 and limited to 254 bytes. It's possible to modernise this style of strings to be less crummy (that is essentially what sds does), but C++/Rust string are a third take where the length (and capacity) are stored separately from the string buffer, and that buffer is always on the other side of a pointer (ignoring SSO, which Rust sadly doesn't have due to the original interface definition).
  - pjmlp 5y ago
    Unfortunely that is not what WASM designers decided when they went without memory tagging for linear memory segments. So you get all the fun to corrupt linear memory C style.
TazeTSchnitzel 5y ago
The difficulty is inherent; C, C++ and so on live in a very different world to JavaScript. Whether or not WebAssembly had direct interaction with JavaScript objects at launch or not, writing bridging code would still be tedious. But there's no reason you must write this yourself. Others have done the hard work for you and written libraries.
HideousKojima 5y ago
It's also still missing proper garbage collection, meaning languages like C# have to include basically the entire runtime if you compile to WebAssembly. This is a major part of why Blazor apps in .NET 5 are ~2MB for a simple "Hello World" (closer to 8MB if you use the AOT compilation options in the .NET 6 preview).
- Deukhoofd 5y ago
  Why would WASM have garbage collection? It's an assembly target, not a runtime. What if languages would want different memory management strategies? I know it's an existing proposal for WASM, but it feels so massively out of scope. If the issue is having to include runtimes in the WASM binary it might be more useful to think about how we could serve runtimes in a more efficient way.
  - staticassertion 5y ago
    I feel the same way. I find it very odd that GC is something that WASM ever intends to think about. If shipping your entire runtime sucks, find a smaller runtime?
    - steveklabnik 5y ago
      Think of it more of "integration with a host environment's runtime" than a "adding a runtime to wasm directly." (At least, that's what it used to be; I haven't been involved in WebAssembly for a long time.)
      - pjmlp 5y ago
        The problem is that each runtime has different GC requirements, so at best it will mean WASM GC semantics will be the underlying JS GC semantics, probably not what you want for a D or .NET GC, for example.
        steveklabnik 5y ago
jollybean 5y ago
WASM is supposed to be 'assembly' level a little bit like java bytecodes. So it's lower level than 'strings'. But as you have pointed out, the missing layer on top i.e. the 'thing we can practically use' is a big gaping hole and it's a little bit diabolical. The fact that JS has gotten so much faster and the lack of both higher-level abstractions and notably a really good 'bridge' to JS means it's lagged in terms of material applicability.

skitter 5y ago

Afaik for the WebAssembly MVP, the goal was to have a simple, efficient compile target - therefore only integers and floats. To make wasm more useful & easier to integrate, the plan calls for interface types[0], which allow both accessing complex (JS) objects and calling browser APIs. [0] https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p...

recursivedoubts 5y ago
interesting, thank you
runnerup 5y ago
thank you

franz899 5y ago

WebAssembly's purpose was never to replace JavaScript but only to speed up certain parts of a website/app.

recursivedoubts 5y ago
that's not how I remember it: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ edit: from the linked article, in case it isn't clear, an HN comment by eich: "Sure, in userland many languages compile to assembly. Hmm, where have I heard that word lately?"[1] [1] - https://news.ycombinator.com/item?id=9554914 https://news.ycombinator.com/item?id=9554914
pjmlp 5y ago
That was the original message used to sell WebAssembly, however when the real goal is to replace ActiveX, Flash, Silverlight and PNaCL it was obvious that it would grew beyond that.
cubano 5y ago
really? i thought it's purpose was to take us back to the good old days of sellable proprietary binary blobs instead of the more open HTML/JS/CSS stack.

Deukhoofd 5y ago

The lack of strings makes sense, as many different languages and standard libraries have their own implementations of it, that can behave slightly differently. It now puts the implementation of the string to the compilers/linkers, as is generally the case for assembly as well. The lack of a DOM API is something I sorely miss as well. It's currently possible (and not that hard, you can just interact with JS), but comes with such performance overhead that you lose the entire benefit of WASM.

flohofwoe 5y ago

What type of strings though? Exposing Javascript string objects in WASM doesn't make much sense if the code is expecting C strings for instance. Same for other languages, those all have their own incompatible internal representations for strings. The only somewhat interop-friendly string type is a zero-terminated bag of bytes, usually UTF-8 encoded (aka C strings), but that's a different string representation than Javascript uses. The Emscripten SDK offers helper functions to marshal high level data types like Javascript strings to UTF-8 encoded C strings on the WASM heap and back to JS, so it's not that bad. DOM access can be achieved with helper libraries which call out into JS. And since any sort of DOM manipulation is extremely slow anyway there's not much of a performance difference even with the overhead of calling out from WASM into JS (which actually is quite fast nowadays).

mamcx 5y ago
>What type of strings though? The good one! UTf-8, NOT null terminated, pascal like. ie: what rust have: https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html REPEAT the mistakes of C (and considering the security angle! in a browser!) must be a big no.
- masklinn 5y ago
  > UTf-8, NOT null terminated, pascal like. > > ie: what rust have: > > https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html Rust (or C++) strings are not pascal strings. In pascal strings, the "string buffer" also contains the length information, and historically it was all bytes with a length byte at the start, which was why your strings started at index 1 and limited to 254 bytes. It's possible to modernise this style of strings to be less crummy (that is essentially what sds does), but C++/Rust string are a third take where the length (and capacity) are stored separately from the string buffer, and that buffer is always on the other side of a pointer (ignoring SSO, which Rust sadly doesn't have due to the original interface definition).
- pjmlp 5y ago
  Unfortunely that is not what WASM designers decided when they went without memory tagging for linear memory segments. So you get all the fun to corrupt linear memory C style.

TazeTSchnitzel 5y ago

The difficulty is inherent; C, C++ and so on live in a very different world to JavaScript. Whether or not WebAssembly had direct interaction with JavaScript objects at launch or not, writing bridging code would still be tedious. But there's no reason you must write this yourself. Others have done the hard work for you and written libraries.

HideousKojima 5y ago

It's also still missing proper garbage collection, meaning languages like C# have to include basically the entire runtime if you compile to WebAssembly. This is a major part of why Blazor apps in .NET 5 are ~2MB for a simple "Hello World" (closer to 8MB if you use the AOT compilation options in the .NET 6 preview).

Deukhoofd 5y ago
Why would WASM have garbage collection? It's an assembly target, not a runtime. What if languages would want different memory management strategies? I know it's an existing proposal for WASM, but it feels so massively out of scope. If the issue is having to include runtimes in the WASM binary it might be more useful to think about how we could serve runtimes in a more efficient way.
- staticassertion 5y ago
  I feel the same way. I find it very odd that GC is something that WASM ever intends to think about. If shipping your entire runtime sucks, find a smaller runtime?
  - steveklabnik 5y ago
    Think of it more of "integration with a host environment's runtime" than a "adding a runtime to wasm directly." (At least, that's what it used to be; I haven't been involved in WebAssembly for a long time.)
    - pjmlp 5y ago
      The problem is that each runtime has different GC requirements, so at best it will mean WASM GC semantics will be the underlying JS GC semantics, probably not what you want for a D or .NET GC, for example.
      - steveklabnik 5y ago

jollybean 5y ago

WASM is supposed to be 'assembly' level a little bit like java bytecodes. So it's lower level than 'strings'. But as you have pointed out, the missing layer on top i.e. the 'thing we can practically use' is a big gaping hole and it's a little bit diabolical. The fact that JS has gotten so much faster and the lack of both higher-level abstractions and notably a really good 'bridge' to JS means it's lagged in terms of material applicability.