I don't think it's unsolvable but as I mentioned, not without changes on the JS side. I suppose the key thing I wanted to say is "directly"—the challenge is that the current import statement just isn't expressive enough, because in 99% of cases we need to provide an environment to the .wasm code itself.
And it's challenging because some extension like this makes no sense:
I've invented with to provide the language support here, but regardless: with ES2015 modules, import is evaluated before all code, so env is just undefined on the import line.
Very basic WASM could be supported, because it doesn't need imports—but as soon as you need to provide memory, or any of the calls or variables I described above, all bets are off.
There might also be some solution I've not thought of yet :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't think it's unsolvable but as I mentioned, not without changes on the JS side. I suppose the key thing I wanted to say is "directly"—the challenge is that the current
import
statement just isn't expressive enough, because in 99% of cases we need to provide an environment to the.wasm
code itself.And it's challenging because some extension like this makes no sense:
I've invented
with
to provide the language support here, but regardless: with ES2015 modules,import
is evaluated before all code, soenv
is just undefined on the import line.Very basic WASM could be supported, because it doesn't need imports—but as soon as you need to provide memory, or any of the calls or variables I described above, all bets are off.
There might also be some solution I've not thought of yet :)