Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A couple of things here:

- the WASI build is targeting WASI snapshot preview 1, and so should work in any compatible runtime.

- for the web, currently we use Emscripten, but we are considering moving to a single WASI build there as well. We'll be writing our own JS WASI shim if we do. Having full control of the JS code will help to solve some of the problems we've faced with Emscripten.

- we are also exploring a route to native where we take the WASI build and decompile it back to C. This seems a little mad, but it makes it possible to compile (with any tool chain) a native binary with a very minimal WASI-like api that can be linked to from any app. It essentially end up a little like the SQLite amalgamated header file as a build route. It's very experimental, and we haven't committed to it yet, but it looks like it may work.



This is interesting. Can you go into a bit more detail on why the WASM decompiling would be helpful as opposed to just using the native codebase?


Dynamic linking on iOS is complex, and Android also brings some toolchain complexities. It would be possible to do a native build and link it, and that is a route we are also exploring, but a single C file that can be linked with any existing toolchain would simplify things for users.

It also allows us to implement a VFS layer underneath PGlite in a native mode. So things like the in-memory VFS, or a custom VFS, would be possible.

We have not committed to one route or the other yet.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: