Topic: Discuss ins & outs, pros & cons, opportunities & threats of WebAssembly for edge computing.
The WebAssembly-related standards are being extended beyond the browser realm, for use “on the edge”, meaning that modules and components can run anywhere i.e. cloud, server, browser, IoT and mobile devices. Many languages are adding compile targets for Wasm. The Component Model and WASI built on top allow for interface-based polyglot programming…
An individual compiled WebAssembly module is an efficient binary .wasm file that can execute with near-native speed (though currently not for all languages and environments… much is still early days). Eventually wasm is to be fully hidden from the application developer as a technology further down the stack.
My thinking was that this emerging technology is a good fit for @akkartik’s Freewheeling apps with its sandboxing and freedom to choose any language + stack.
This week is the first WebAssembly conference:
Below I collected some (admittedly buzzword-laden) resources for those who want to know more…
I have to admit, I’m a bit wary of WebAssembly. It might have to do with the ‘Web’ in the name, but I tend to focus on the people creating and pushing a technology, and for the most part (with exceptions such as WebGPU and yourself) WebAssembly feels a bit too trendy and hype-y for my taste. I’ve seen enough cases in the past where big companies get into a promising technology, and it never ends well for my priorities.
The component model is a proposal actively in development for what looks like a package system from other ecosystems, but with some unique features including:
clearly defined types at component boundaries
parent components can define how child components are wired together (instead of only the child importing within itself)
In my view, this seems like a great layer upon which to build malleable extensibility. The link-time virtualisation example hints at the “rewiring” power I am thinking of for malleable purposes.
I’m hoping to get better at writing about my own malleable thoughts on this extensibility topic and others on my blog in the next weeks / months… I just need to force myself to block off the time to do it properly.
Beyond the component model, I also see malleable connections in allowing language choice / polyglot extensibility. You would be able to use whichever language you prefer, as long as it compiles to Wasm. Of course, there are still some open problems around polyglot language semantics to ensure the combined multi-language program actually does something sensible… even with that in mind, I see this as quite an enticing way to side-step programming language preferences by supporting many of them in one go.
Being wary is certainly prudent. As with all major technology efforts the infamous hype cycles there’s danger to going all-in too soon. There’s a lot of nice experimentation as well as actual product development going on, both by established parties (corporations) and tinkerers on the Fediverse and HN.
From my own surveys of the emerging technology landscape I became confident enough to say that I’d like to consider being an early adopter, and knowing full well that that entails frequent changes and shifts as well as open areas for research. But that last bit is a Good Thing™. Unleash the creativity
Indeed. In the last wasmCloud community meeting there was a demonstration of a very basic KVCounter in Golang (port of a similar example in Rust) and based on a simple WIT world definition + codegen, the code itself is completely void of infra-specific stuff. And even more there’s zero lines of code that it makes it a wasmCloud application. It just runs on that platform based on all the open standards it supports. The only specific line that makes this happen is in the compilation directive:
This is just a prototype, and the codegen can be much cleaned up (e.g. now generates very long names).
This extends (pun intended) seamlessly to the above. Components can be composed from modules written in any Wasm-supporting language. And create powerful plugin architectures. Extism is a prime example of a project focused on that, among others.
Where I’m interested is in having very loosely-couple event-driven architecture and orchestrated “service modules” be the building blocks for creating “social experiences”. Reviving the idea of Social experience design (SX) that builds upon DDD Strategic design to allow non-technical stakeholders to be always in lock-step with the software team and see their Needs covered. All this relates to the Solidground Project, where we’ll go with a new Rust + Wasm stack.
PS. I’ll drop some notes about wasm survey I did. But that requires some editing to upload imgs. Will do later.
That’s one of the features I find interesting, because we desperately need better ways to build bridges between software components from different universes. But this crucially depends on the availability of diverse languages on the wasm platform, plus practically usable interfaces. For now, I see mostly languages aiming at low-level and/or highly formalized problems. I vaguely remember comments about garbage collection being difficult to do on wasm - that could become a show stopper if it’s a fundamental issue.