-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring back .wasm imports #5609
Comments
The wasm esm integration spec is currently stage 2. Before we add this feature (which we should) the implementors should familiarize themselves with this in-progress specification: |
Wasn't the only thing blocking the release of this support for "top-level await," which Deno seems to have already, putting it ahead of all of the major browsers? Doesn't the current support for top-level await make Deno non-web compatible? |
@00ff0000red Top level await is implemented by V8, not Deno. And that landed in browsers just recently, so there's not even reason to argue about it The module implementation however IS specific to the runtime, so an implementation of WASM imports that gets rushed might break the Deno phylosophy |
It is in Deno and has been for a long time. 😕 There is nothing really holding this back other than the fact that getting the semantics to line up to something that seems stalled in the stands process is a challenge/risk. |
@kitsonk I ment to say that |
Biggest problem with the non-standard feature for imports is that what if this becomes standard which is incompatible how it was implemented in Deno? Then there is possibility it will break the code depending on the feature, and there is no good way to highlight the error lines. To mitigate that risk there could be alternate syntax, e.g.:
or even
(In example below the Deno would not allow the import at all if the @deno-import is not there) If the wasm module imports become a standard, then it would be as simple as removing the unstable modifier (or additionally change it because it can't be known if it works with the standard that doesn't exist). I hope I'm making sense. |
now fetch wasm need network , how to cache all wasm and compile into exe ? I think import wasm is important , when not support , so people have to hard code fetch wasm in library development , without cache In many country for example china , network fetch from foreign site is sometimes blocked , so network fetch wasm often failed |
@gcxfd Can you use |
You can embed the WebAssembly module as a base64 encoded string for now (this is larger and slower so not optimal but works okay enough); with import assertions for wasm we should be able to bundle it all together but that'll be a little while. |
I can use readFile with my self wasm , but when I use the Third-party libraries which has wasm , I have to modify their code , This will make maintenance very troublesome . So I think the earlier support for import wasm will earlier enable Third-party libraries with wasm in real world development |
Does Deno support Request caching? Ex: But early support means that a lot of code might break, in various ways, once the proposal is complete, and Deno implements the standard. Regarding the issue at hand, what's preventing an experimental re-implementation of the proposal? I'd love to be able to start up my code by running |
Closing as duplicate of #2552 |
It was removed in #5135
Potentially this should be behind the --unstable flag?
cc @bartlomieju
The text was updated successfully, but these errors were encountered: