-
-
Notifications
You must be signed in to change notification settings - Fork 670
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
Add navigator.userAgent to global scope #2903
Comments
userAgent is WebAPI and doesn't relate to JavaScript specifications, much less AssemblyScript. To work with WebAPI, use host bindings |
Since AssemblyScript can be run directly with Bun and Deno
I'm trying to switch on user agent so I can run the same code to compile to WASM and execute with a JavaScript/TypeScript runtime. At this part of the code
I'll see what you got going for host bindings.
|
My implementation so far
|
So, how would you switch in the above case between |
AS isn't a runtime; maybe you can use |
I'll reserve my opinion on whether or not AssemblyScript is close enough to a runtime. Tried that.
As stated above both Deno and Bun execute AssemblyScript source code directly - after stripping types. Now,
I've substituted So when the AssemblyScript is transformed/compiled to JavaScript using either Deno or Bun, e.,g.,
there's this still left
which is incompatible with Deno or Bun. I'm trying to figure out a way to write Right now I'm modifying the resulting JavaScript by hand, e.g.,
or
then
then
So I'm trying to figure out a way to DRY. Either modifying Make sense? |
AssemblyScript as well as WebAssembly knows absolutely nothing about the host's runtime. It can be browser, node, deno, wasm3 or wasmtime. That is, Wasm module is absolutely isolated from the host it runs on. So I don't really understand exactly what the question is. The host's fragmentation problem is solved on the host side (not on AS side) and then the unified solution is imported into Wasm (AS) module through bindings.
|
If AS were to support |
BTW,
I don't think so https://github.com/humodz/node-wasi-preopens-escape. But that's not what I'm trying to get done here. I'm just trying to not repeat myself by using the same code across AssemblyScript, TypeScript, JavaScript, WebAssembly.
If The real issue is that |
Well, almost solve. Because Basically, I'm saying maintainers could try to implement signatures that match the existing signature they are copying/extending.
|
This is what I came up with so far Add
Create an external ECMAScript Module file defining
Modify
Compile to WASM with
Test processing
Preload the ECMAScript Module, then execute AssemblyScript source
Now I'll figure out a way to do the same thing using Deno. |
I'm not finding a way to preload an ECMAScript Module in Deno, yet. Modifying
|
Another way to use Deno without executing
|
Feature suggestion
See
navigator.userAgent
denoland/deno#14362Deno and Bun execute AssemblyScript directly (after transforming or stripping types).
AssemblyScript
process.stdin.read()
is not the same as Node.jsprocess.stdin.read()
.String.UTF8
is not defined in Node.js or Deno.The rational being able to use the same code that can be executed directly by JavaScript/TypeScript runtimes and compiled to WASM by
asc
.Instead of using
String.UTF8
as a conditionThe text was updated successfully, but these errors were encountered: