As a further update on https://github.com/nodejs/uvwasi/issues/59, it is now possible to use Preview 2 components via Jco with support for the full set of Preview2 APIs, passing the conformance test suites on Node.js.
To achieve this, Jco implements a Preview 2 implementation on top of the high-level Node.js APIs using the preview2-shim library, which while correct has performance limitations that a uvwasi implementation would avoid. There is an open issue on the Jco project for improving performance in Jco in https://github.com/bytecodealliance/jco/issues/417.
Ideally for the best performance, Preview 2 should be fully implemented in uvwasi, so this is very much a question of implementation effort not design or architecture.
On top of low-level bindings development, there are also the high-level API design questions for Preview 2. Direct host integration, eg for a Node.js Preview2 implementation, should likely involve:
High-level API work can already be achieved using Jco transpile today as an internal implementation. These two work streams - high-level API integration, and low-level uvwasi updating can thus be implemented completely independently at this point in time based on how development priorities turn out.
As a further update on https://github.com/nodejs/uvwasi/issues/59, it is now possible to use Preview 2 components via Jco with support for the full set of Preview2 APIs, passing the conformance test suites on Node.js.
To achieve this, Jco implements a Preview 2 implementation on top of the high-level Node.js APIs using the preview2-shim library, which while correct has performance limitations that a uvwasi implementation would avoid. There is an open issue on the Jco project for improving performance in Jco in https://github.com/bytecodealliance/jco/issues/417.
Ideally for the best performance, Preview 2 should be fully implemented in uvwasi, so this is very much a question of implementation effort not design or architecture.
On top of low-level bindings development, there are also the high-level API design questions for Preview 2. Direct host integration, eg for a Node.js Preview2 implementation, should likely involve:
WebAssembly.compilesupport, perhaps via a separatecompileComponentfunction for component binaries (which are uniquely identifiable through their leading bytes), with automatic binding to WASI APIs, similar to how the new strings proposal allows builtins to be specified at compile time - https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md#using-builtins.High-level API work can already be achieved using Jco transpile today as an internal implementation. These two work streams - high-level API integration, and low-level uvwasi updating can thus be implemented completely independently at this point in time based on how development priorities turn out.