WebAssembly support in the browser via Hoot is a great strategic technology decision.
I am curious to learn more - bit roadmap-level - about plans wrt wasm for exposing OCapN functionality, not only in the browser, but also possible further plans that relate to WebAssembly Components and interface-based programming via WASI/WIT.
Recently Wasmcloud v1.0 was released, a framework I consider using. It supports WASI Preview 2, and allows a shift to more service-oriented development, in my case for the Social Web and in relationship to ForgeFed where @fr33domlover is implementing OCaps (non-Spritely ones still, I think) and also looking into federated Teams & Projects (building blocks for composed services to me).
An area where service composition, orchestration and choreography approaches may be well considered, looks to be for use with Spritely’s Community Pattern Language, in future plans. A topic area of this community that I am highly interested in.
Maybe Spritely Institute isn’t at a stage yet do much in terms of community engagement. That is no problem. But some more conceptual outlines and sketches surrounding future technology direction may help those awaiting eagerly what comes forth, to prepare and align their projects to quickly adopt once the time is right. Thank you, for all your work!
Hi @aschrijver, I can explain the state of the technology a bit. The most important target for Goblins/OCapN programs is the web browser, so that’s our primary focus right now. Hoot is now in a good enough state that we have begun working on the integration of Hoot and Goblins. This integration is in an early stage but things are progressing quickly. We will share more news as we hit major milestones, so stay tuned for that!
With regards to WASI, Hoot binaries do not currently conform to the WASI interface. It’s a target that would be possible and something we’re considering for the future but it’s low on the priority list. For starters, non-browser runtimes have been much slower to adopt the now-standardized Wasm features that Hoot relies upon: GC and tail calls. I looked into Wasmcloud and it seems to use Wasmtime under the hood. According to the Wasm feature matrix, Wasmtime does not support GC and tail calls are not yet stable and behind a feature flag. So, even if we could compile for WASI we couldn’t yet run on Wasmcloud. The priorities for the developers of these non-browser runtimes tend to be supporting static languages that use Wasm’s linear memory model and not dynamic languages that use GC, but they should catch up eventually. I’ve been told that Wasmedge recently got GC support, for example.
At the moment, the best “native” runtime for Hoot is NodeJS (starting with version 22 which hasn’t been released yet) since it can share the JavaScript host code used for web browsers. Other V8 distros such as Deno should be usable, as well, once they start shipping a sufficiently fresh version of V8.
Thank you @dthompson. Yes, this is helpful. Your direction makes sense. Going on the Wasm components / WASI route is a deliberate early-adopter’s choice. I’ve noticed that the developments are going rapidly, with a large body of vendors in the “cloud” landscape, but with edge computing and small device operations as extra boons. It comprises something of a paradigm shift. I just read a summary about the recent Wasm I/O conference (bit vendor-biased, but okay):
One of the links within is to a page where they track language support:
That is super exciting! Great work.
Indeed. I should ask Bailey Hayes of Bytecode Alliance about roadmap too. She has a very clear picture of the technology landscape. It is a pity that that list only contains a few runtimes. The Awesome WebAssembly Runtimes list on Github is also 9 months outdated. Like many others.