Comments (4)
Closing as resolved, but if there is more that needs to be investigated here please do continue discussion.
from jco.
@GordonSmith can you clarify what sorts of extensions you are looking to make here? It would help to understand what kinds of interceptions might be useful, above and beyond the current --instantiation
output mode.
from jco.
Disclaimer 1 - I haven't attempted to integrate any of the (new to me) component, wit, wasi-sdk toolchains into a "product", so my comments are just observations on the "hello world" type generated code. Also as I highlighted above, they are more about certain frustrations with the emscripten generated "module" JS, that I would not like to see repeated here!
Disclaimer 2 - I am not interested in any class v functional debates, IMO they are just different abstractions with their own pros and cons, if anything my mantra is always "good encapsulation" which in this context is the ability to replace well encapsulated "bits" of the generated code.
So with that in mind when I look at the generated code my initial observations are:
- The "loader" code (the bit which fetches the wasm), is catering for two separate environments (NodeJS and Browsers) and is also making assumptions about the location of the wasm file. This has historically been a pain for me (as a JS library writer) as I won't be able to bundle that code cleanly - I like to create a single JS file which "just works" in NodeJS, Browsers (inline or as web workers) AND that my customers can bundle in their web applications without having to think about it. FWIW I solved this issue by compressing the wasm using zstd and encoding it as Base91 so it can be stored in a JS file as a string, with a helper function that does the decoding and decompressing - so I would need the ability to exclude your loader code and be able to pass in a "pre-loaded" wasm file (and have no reference to any NodeJS/Deno libraries which confuse my bundlers and my customers bundlers).
- The helper functions are going to get duplicated when working with more than one wasm component
- The use of TextEncode/TextDecoder might be problematic in some environments (does Deno support them? Does wasmr + embedded JS support them?), While I suspect the answer might be yes in those examples I already have my own encoder and decoder that I might prefer to use.
- The shared memory is not accessible (in my toy example anyway), I will want to be able to allocate memory on demand and be able to read / write to it from the JS side (image blobs, or parquet blobs etc.)
The code being generated is super clean and I would hate to see it getting a lot of if (opt.nodejs === true)
or if (opt.utf8encode !== undefined)
type statements.
Classes could solve these issues, so could well typed functions in separate files...
from jco.
I believe the class will make more sense to be generated from a resource shape defined in WIT. Because right now the tooling does not support resources, they have been defined as separated functions without state and no particular flow. I hope that this will change in the near future.
from jco.
Related Issues (20)
- Resource transferring seems not working with wasi-virt HOT 1
- Crash on startup with an out-of-memory error when environment variables are large HOT 3
- Provide wasm-tools APIs in the browser HOT 2
- `definedResourceTables` codegen generates invalid JS with `--instantiation async` HOT 1
- plain enums are generating complex typescript HOT 8
- Question: `jco types` generating namespaces instead of modules? HOT 3
- Better instantiation workflows HOT 1
- Better errors when failing to parse a wit directory
- Compiled wasm crashes on Rust 1.78.0, but not on 1.77.2 HOT 8
- preview2-shims: remove all class state
- preview2-shims: investigating fetch setting accept-encoding header HOT 1
- Reinstate zero-copy encoding in next adapter upgrade
- Calling into a component that includes the println macro hangs HOT 5
- Still having issues with the env vars memory leak HOT 1
- How to use WASI functionality w/ `jco`? HOT 1
- [preview2-shim] OutgoingRequest.setAuthority rejects ports >9999
- Incorrect type annotations
- More incorrect typescript annotations HOT 3
- [preview2-shim] Consider giving guest no preopens by default HOT 3
- Wasm modules with shared memories are rejected even if they do not spawn threads HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jco.