The wasi path_open API incurs some size overhead, it appears. Measuring in wasi SDK output, around 1K for the preopen and related support. Experimenting in Emscripten, there is also overhead from flag conversion since the open flags+mode must be converted and split into wasi's dirflags+oflags+rights+fs_flags; looks like for us a naive implementation would add almost 1K (most on the JS side where we need to unconvert things; that might be optimized with a larger refactoring, but it's unclear).
That overhead is unfortunate in embedded systems, the Web, and other places where size is a high priority. Basically, path_open requires a bunch of permissions work to be done in "userspace" inside the wasm. (And to some extent this is not strictly needed work as the VM must monitor each path for access anyhow.)
Perhaps embedded/Web/etc. would benefit from a more minimalistic API, something closer to open(), saving that 1-2K? That does raise questions like
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3