9 ms·

It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, whi

It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.

hn_throwaway_99 2y ago
What's old is new again :) asm.js came about because it was a very optimizable subset of JavaScript, then it was superseded by WebAssembly, then the proposal in TFA is basically asking for asm.js back, but perhaps the better answer is to make WebAssembly fully support all of what JS could originally do. This is perhaps why as I get older I sometimes feel like I want to get out of software development and become a goose farmer like that dude on LinkedIn - lots of times feels more like spiraling in circles than actually advancing.
- no_wizard 2y ago
  I think it’s much harder to make big leaps as a community with languages and other - relative to the technology stack as a whole - lower level concerns. Look at the stronghold grip of C/C++ and how long it’s taken Rust to gain a meaningful foothold in those realms for example. Google wanted to flat replace JS once already, that was the entire origin of Dart. They only pivoted to the cross platform mobile framework as its primary target after it failed to gain traction as a standard
  - pjmlp 2y ago
    Actually in regards to Dart it is a more subtle. Dartium was cancelled and AdWords team, having just migrated from GWT to AngularDart, saved the Dart team. Eventually many left the team. Somewhere at Google, Flutter started and when they decided to replace JavaScript on their original design, they decided to reach out to the Dart team. So Dart got a new purpose in life, being Flutter's language. In this process it was rebooted from dynamic language, into a static type one, having JIT and AOT toolchains. How long Flutter, and by association Dart, remain relevant remains to be seen.
  - petre 2y ago
    Dart is a better designed language in many regards.
    - mdhb 2y ago
      It’s not just better than JavaScript, I would argue it’s probably the best general purpose modern OOP based language out there right now. It was actually really fortunate in that for a long time it didn’t have a big community behind it and they just put a lot of very smart language designers on the team where they had ten years to try various approaches and learn from the mistakes of not only themselves but others without a lot of outside noise. But there’s no other language I would prefer to write applications in. It’s just a really nice mix of ergonomic, expressive and powerful.
- pjmlp 2y ago
  asm.js came about because Mozzilla refused to adopt PNaCL, which is kind of ironic given the existing Firefox market share a decade later.
  - adjav 2y ago
    PNaCL was essentially "let's shove LLVM into every browser and make it a mandatory part of the web", which somehow seems even worse than "let's shove the JVM into every browser and make it a mandatory part of web"
    - pjmlp 2y ago
      Given Google's power a decade later, with Safari left as the only non-Chrome clone with market relevance, it hardly makes a difference. Additionally we already have LLVM all over the place, alongside JVM and CLR, it is the most deployed compiler infrastructure with contributions at the same level as the Linux kernel.
    - DonHopkins 2y ago
      >"let's shove the JVM into every browser and make it a mandatory part of web" Javagator / Jazilla! https://www.cnet.com/tech/tech-industry/javagator-down-not-out/ https://www.cnet.com/tech/tech-industry/javagator-down-not-o...
no_wizard 2y ago
They’re already moving it that way, it’s not like it isn’t without complexities and such either. WASM isn’t the silver bullet everyone seems to cling to. I feel like the WASM fervor has more to do with the fact people don’t enjoy using Frontend tools or JavaScript etc. vs looking at the actual utility tradeoffs
- singularity2001 2y ago
  >> WASM isn’t the silver bullet everyone seems to cling to. And it isn’t the silver bullet exactly for the reason that it's horribly complicated to access normal JS objects including strings.
  - xscott 2y ago
    You're two library functions away from having it easy: Copy from JavaScript to WebAssembly: Use TextEncoder to convert a JS String to Uint8Array Copy the bytes from the Uint8Array to WemAssembly.Memory Copy from WebAssembly to JavaScript: Copy the bytes from WebAssembly.Memory into a Uint8Array Use TextDecoder to convert from Uint8Array to JS String JS Strings are pretty much always going to be "rope data structures". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.
    - singularity2001 2y ago
      From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md https://github.com/WebAssembly/js-string-builtins/blob/main/... "the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call" I guess the more elegant and universal stringref proposal is DEAD now !? https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md https://github.com/WebAssembly/stringref/blob/main/proposals... I don't really mind, as it keeps the wasm bytecode cleaner.
xscott 2y ago
"trampoline business"? It supports nearly arbitrary imports of anything you want. How much more flexibility do you need? You could provide an `eval` function to run arbitrary code with a small amount of effort. Is the problem that Emscripten and/or Rust haven't laid it all out on a platter?
dmart 2y ago
I’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?
- xscott 2y ago
  Because it's already solved from day one and people keep repeating that it's a problem anyways. Anything you can do in JavaScript, including access to the DOM, can be put into a JavaScript function. You can import that function into a WebAssembly Module, and you can use WebAssembly Memory to transfer large or complicated data as an efficient side channel. It all works.
  - hu3 2y ago
    Could you link an ergonomic example? I have cemented in my memory that DOM access in WebAssembly is not trivial and I suspect others too. This is what StackOverflow tells me (2020): > Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access. The closest manipulation you'll get from WASM is to manipulate state objects that are passed to and rendered by the main thread with state-based UI components like Preact/React. > JSON serialization is most often used to pass state with postMessage() or Broadcast Channels. Bitpacking or binary objects could be used with Transferrable ArrayBuffers for more performant messages that avoid the JSON serialization/deserialization overhead. This feels like "we can have DOM access at home" meme.
    - xscott 2y ago
      > This is what StackOverflow tells me (2020) Web Workers can't directly access the DOM in JavaScript either. This is not a WebAssembly problem. If you want a Web Worker to manipulate your document, you're going to post events back and forth to the main thread, and Web Assembly could call imported functions to do that too. I don't even know what he's on about with Preact/React... Save the following as "ergonomic.html" and you'll see that WebAssembly is manipulating the DOM. <!doctype html><title>Not that hard</title> <script type="module"> document.addEventListener('DOMContentLoaded', () => { /* Compile this module with wat2wasm to make the binary below: (module (import "env" "easy" (func $easy (param i32))) (func $run (param) (result) (call $easy (i32.const 123)) (call $easy (i32.const 456)) ) (memory $mem 1) (export "run" (func $run)) (export "mem" (memory $mem)) ) */ const binary = new Uint8Array([ 0, 97, 115, 109, 1, 0, 0, 0, 1, 8, 2, 96, 1, 127, 0, 96, 0, 0, 2, 12, 1, 3, 101, 110, 118, 4, 101, 97, 115, 121, 0, 0, 3, 2, 1, 1, 5, 3, 1, 0, 1, 7, 13, 2, 3, 114, 117, 110, 0, 1, 3, 109, 101, 109, 2, 0, 10, 14, 1, 12, 0, 65, 251, 0, 16, 0, 65, 200, 3, 16, 0, 11, ]); const imports = { easy(arg) { const div = document.createElement("div"); div.textContent = "DOM this: " + String(arg); document.body.appendChild(div); } }; const module = new WebAssembly.Module(binary); const instance = new WebAssembly.Instance(module, { env: imports }); instance.exports.run(); }); </script> That `easy(arg)` function could do much more elaborate things, and you could pass lots of data in and out using the memory export. I'd like to believe a simple standalone example like this would be enough to get people to shutup about the DOM thing, but I know better. It'll be the same people who think you need to link with all of SDL in an Emscripten project in order to draw a line on a canvas. > This feels like "we can have DOM access at home" meme. And I'm sure somebody (maybe you) will try to move the goal posts and claim some other meme applies.
binary132 2y ago
no, people need to be able to program the browser without needing “tooling”

It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.

hn_throwaway_99 2y ago

What's old is new again :) asm.js came about because it was a very optimizable subset of JavaScript, then it was superseded by WebAssembly, then the proposal in TFA is basically asking for asm.js back, but perhaps the better answer is to make WebAssembly fully support all of what JS could originally do. This is perhaps why as I get older I sometimes feel like I want to get out of software development and become a goose farmer like that dude on LinkedIn - lots of times feels more like spiraling in circles than actually advancing.

no_wizard 2y ago
I think it’s much harder to make big leaps as a community with languages and other - relative to the technology stack as a whole - lower level concerns. Look at the stronghold grip of C/C++ and how long it’s taken Rust to gain a meaningful foothold in those realms for example. Google wanted to flat replace JS once already, that was the entire origin of Dart. They only pivoted to the cross platform mobile framework as its primary target after it failed to gain traction as a standard
- pjmlp 2y ago
  Actually in regards to Dart it is a more subtle. Dartium was cancelled and AdWords team, having just migrated from GWT to AngularDart, saved the Dart team. Eventually many left the team. Somewhere at Google, Flutter started and when they decided to replace JavaScript on their original design, they decided to reach out to the Dart team. So Dart got a new purpose in life, being Flutter's language. In this process it was rebooted from dynamic language, into a static type one, having JIT and AOT toolchains. How long Flutter, and by association Dart, remain relevant remains to be seen.
- petre 2y ago
  Dart is a better designed language in many regards.
  - mdhb 2y ago
    It’s not just better than JavaScript, I would argue it’s probably the best general purpose modern OOP based language out there right now. It was actually really fortunate in that for a long time it didn’t have a big community behind it and they just put a lot of very smart language designers on the team where they had ten years to try various approaches and learn from the mistakes of not only themselves but others without a lot of outside noise. But there’s no other language I would prefer to write applications in. It’s just a really nice mix of ergonomic, expressive and powerful.
pjmlp 2y ago
asm.js came about because Mozzilla refused to adopt PNaCL, which is kind of ironic given the existing Firefox market share a decade later.
- adjav 2y ago
  PNaCL was essentially "let's shove LLVM into every browser and make it a mandatory part of the web", which somehow seems even worse than "let's shove the JVM into every browser and make it a mandatory part of web"
  - pjmlp 2y ago
    Given Google's power a decade later, with Safari left as the only non-Chrome clone with market relevance, it hardly makes a difference. Additionally we already have LLVM all over the place, alongside JVM and CLR, it is the most deployed compiler infrastructure with contributions at the same level as the Linux kernel.
  - DonHopkins 2y ago
    >"let's shove the JVM into every browser and make it a mandatory part of web" Javagator / Jazilla! https://www.cnet.com/tech/tech-industry/javagator-down-not-out/ https://www.cnet.com/tech/tech-industry/javagator-down-not-o...

no_wizard 2y ago

They’re already moving it that way, it’s not like it isn’t without complexities and such either. WASM isn’t the silver bullet everyone seems to cling to. I feel like the WASM fervor has more to do with the fact people don’t enjoy using Frontend tools or JavaScript etc. vs looking at the actual utility tradeoffs

singularity2001 2y ago
>> WASM isn’t the silver bullet everyone seems to cling to. And it isn’t the silver bullet exactly for the reason that it's horribly complicated to access normal JS objects including strings.
- xscott 2y ago
  You're two library functions away from having it easy: Copy from JavaScript to WebAssembly: Use TextEncoder to convert a JS String to Uint8Array Copy the bytes from the Uint8Array to WemAssembly.Memory Copy from WebAssembly to JavaScript: Copy the bytes from WebAssembly.Memory into a Uint8Array Use TextDecoder to convert from Uint8Array to JS String JS Strings are pretty much always going to be "rope data structures". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.
  - singularity2001 2y ago
    From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md https://github.com/WebAssembly/js-string-builtins/blob/main/... "the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call" I guess the more elegant and universal stringref proposal is DEAD now !? https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md https://github.com/WebAssembly/stringref/blob/main/proposals... I don't really mind, as it keeps the wasm bytecode cleaner.

xscott 2y ago

"trampoline business"? It supports nearly arbitrary imports of anything you want. How much more flexibility do you need? You could provide an `eval` function to run arbitrary code with a small amount of effort. Is the problem that Emscripten and/or Rust haven't laid it all out on a platter?

dmart 2y ago

I’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?

xscott 2y ago
Because it's already solved from day one and people keep repeating that it's a problem anyways. Anything you can do in JavaScript, including access to the DOM, can be put into a JavaScript function. You can import that function into a WebAssembly Module, and you can use WebAssembly Memory to transfer large or complicated data as an efficient side channel. It all works.
- hu3 2y ago
  Could you link an ergonomic example? I have cemented in my memory that DOM access in WebAssembly is not trivial and I suspect others too. This is what StackOverflow tells me (2020): > Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access. The closest manipulation you'll get from WASM is to manipulate state objects that are passed to and rendered by the main thread with state-based UI components like Preact/React. > JSON serialization is most often used to pass state with postMessage() or Broadcast Channels. Bitpacking or binary objects could be used with Transferrable ArrayBuffers for more performant messages that avoid the JSON serialization/deserialization overhead. This feels like "we can have DOM access at home" meme.
  - xscott 2y ago
    > This is what StackOverflow tells me (2020) Web Workers can't directly access the DOM in JavaScript either. This is not a WebAssembly problem. If you want a Web Worker to manipulate your document, you're going to post events back and forth to the main thread, and Web Assembly could call imported functions to do that too. I don't even know what he's on about with Preact/React... Save the following as "ergonomic.html" and you'll see that WebAssembly is manipulating the DOM. <!doctype html><title>Not that hard</title> <script type="module"> document.addEventListener('DOMContentLoaded', () => { /* Compile this module with wat2wasm to make the binary below: (module (import "env" "easy" (func $easy (param i32))) (func $run (param) (result) (call $easy (i32.const 123)) (call $easy (i32.const 456)) ) (memory $mem 1) (export "run" (func $run)) (export "mem" (memory $mem)) ) */ const binary = new Uint8Array([ 0, 97, 115, 109, 1, 0, 0, 0, 1, 8, 2, 96, 1, 127, 0, 96, 0, 0, 2, 12, 1, 3, 101, 110, 118, 4, 101, 97, 115, 121, 0, 0, 3, 2, 1, 1, 5, 3, 1, 0, 1, 7, 13, 2, 3, 114, 117, 110, 0, 1, 3, 109, 101, 109, 2, 0, 10, 14, 1, 12, 0, 65, 251, 0, 16, 0, 65, 200, 3, 16, 0, 11, ]); const imports = { easy(arg) { const div = document.createElement("div"); div.textContent = "DOM this: " + String(arg); document.body.appendChild(div); } }; const module = new WebAssembly.Module(binary); const instance = new WebAssembly.Instance(module, { env: imports }); instance.exports.run(); }); </script> That `easy(arg)` function could do much more elaborate things, and you could pass lots of data in and out using the memory export. I'd like to believe a simple standalone example like this would be enough to get people to shutup about the DOM thing, but I know better. It'll be the same people who think you need to link with all of SDL in an Emscripten project in order to draw a line on a canvas. > This feels like "we can have DOM access at home" meme. And I'm sure somebody (maybe you) will try to move the goal posts and claim some other meme applies.

binary132 2y ago

no, people need to be able to program the browser without needing “tooling”