I'm not entirely convinced Wasmer will ever be able to shake its constant controversies.
I'm by no means a fan of the Bytecode Alliance, and would much prefer a startup tackle the problems that Wasmer is tackling, but between the trademarks [1], the lackluster response to the trademarks (How did you not know your lawyers were trying to trademark “WebAssembly”? Seriously?) [2], the working conditions [3], the drama surrounding the BCA [4][5], and everything else, I don't think Wasmer is the right choice either, at least not under current leadership.
[1] https://uspto.report/company/Wasmer-Inc
[2] https://wasmer.io/posts/wasmer-and-trademarks
[3] https://mnt.io/2021/10/04/i-leave-wasmer/
[4] https://github.com/wasmerio/wasmer/issues/956
[5] https://github.com/WebAssembly/WASI/issues/3
In Wasmer takes WebAssembly libraries mainstream with WAIWebAssembly
WASI
Rust2019–2026
WebAssembly / WASI
WASI
WebAssembly System Interface
52Distinct people
57Mentions
0Explicit recommenders
5.8KGitHub stars
What to know before exploring
What it is
WebAssembly System Interface
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bytecodealliance/wasmtime · linked in 2 of the same discussions
- webassembly/component-model · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year57 dated mentions
Observed mentions: 2019-06-01 02:23:09 UTC to 2026-08-13 14:37:56 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 2 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
WebAssembly System Interface
The WebAssembly System Interface (WASI) is a set of APIs for WASI being
developed for eventual standardization by the WASI Subgroup, which is a
subgroup of the WebAssembly Community Group.
WASI started with launching what is now called Preview 1, an API using
the witx IDL, and it is now widely used. Its major influences are POSIX and
CloudABI.
WASI 0.2 (Preview 2) is a modular collection of APIs defined with the Wit IDL,
incorporating many of the lessons learned from WASI 0.1, including support for
a wider range of source languages, modularity, a more expressive type system,
and virtualizability.
WASI 0.3 (Preview 3) is the current preview. It builds on WASI 0.2, replacing
the earlier explicit streams and polling interfaces with the component model's
native, composable async functionality via the future and stream types.
Find the APIs
Development of each API happens in its own repo, which you can access
from the proposals list.
This repo is for general discussion, as well as documenting how we work
and high-level goals.
Propose a new API
If you would like to create a new proposal, get started with our
Contributing guide.
All new API proposals should use the new format and the new repo structure that is shown in the proposal template.
See the Wit in WASI document for more information about using Wit for WASI proposals.
Read the full README on GitHubWhat Hacker News says
14 sourcesI'm trying to figure out what Extism is actually providing here.
The underlying runtime appears to be Wasmtime, an existing project that you can use separately.
For the system API, Extism supports WASI (a POSIX-like API for WASM) which is already supported by Wasmtime. However it sounds like it also has a different, non-WASI API that provides similar functionality. I'm curious to hear a compare/contrast between these two system APIs, or what motivated inventing a new non-WASI system API. It does appear that WASI is in its early days; WASI was announced in 2019 (https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...) but it appears that all of the specific proposals are still early stage and far from being standardized (https://github.com/WebAssembly/WASI/blob/main/Proposals.md).
For the API, Extism provides a C API/ABI that ca
Read the rest
n be called through FFI, but AIUI Wasmtime already has such an API: https://docs.wasmtime.dev/c-api/
Basically I'm trying to understand the conceptual difference between this project and Wasmtime.
But isn't WASI considered harmful?
I absolutely disagree with ASC's stance on this, but it seems that the AssemblyScript project at least wants nothing to do with that kind of thing:
[1] https://devclass.com/2022/09/08/assemblyscript-project-wasi-...
[2] https://www.assemblyscript.org/standards-objections.html
[3] https://github.com/WebAssembly/WASI/issues/401
In Wasmer 3.0Very cool. This is super relevant to me, I've been porting Trealla Prolog to WASI recently[1] and I've been considering moving from wasmer-js to libapps/wasi-js-bindings. This looks like a nice alternative as well.
I tried running Trealla (you can grab a binary from here https://wapm.io/guregu/trealla) and it seems to work but it doesn't echo any of my input text. Does this have the terminal in raw mode by default? I'm curious how this works given that WASI lacks termios.h.
I always thought a "Steam for text games/CLI apps" would be super cool (ala webassembly.sh) but the WASI spec is missing a lot of terminal-related things: https://github.com/WebAssembly/WASI/issues/161
[1]: https://github.com/guregu/trealla-js
In Show HN: I built a WASI playground for running CLI binaries in the browserI'm confused. Searching for WASI leads me here
https://github.com/WebAssembly/WASI
Which has no links to any readable docs or specs.
¯\_(ツ)_/¯
In Show HN: I built a WASI playground for running CLI binaries in the browserNope, the file I linked to is the WASI API, just expressed as a C header (which I find a bit easier to skim than the actual specification).
Here's the actual WASI spec:
https://github.com/WebAssembly/WASI/blob/main/phases/snapsho...
You'll find it matches the file I linked. Search for "POSIX" or "errno".
In Wasmtime 1.0What you linked to is WASI-libc, which is a C standard library implementation on top of WASI - which itself is more low-level and less POSIX-like. https://github.com/WebAssembly/WASI
In Wasmtime 1.0It is almost funny, almost sad, that we were in this for nearly five years, every single day, and despite that a cartel created for the occasion completely evaporated us politically for pointing out "technically not wrong" technicalities that nobody ever had the intention to address, this is how we are perceived still by the same people we once thought we were giving a voice to :) Yet, somehow, Wasm has turned out to be almost indistinguishable of what was once presented or what is still marketed by its outdated supplementary material. Openness? Portability? Security? Web interop? Multi-language? Professional conduct? Giggles through rose-colored glasses. https://github.com/WebAssembly/WASI/issues/401 —the AS guy
In Assemblyscript Removes WASI Supportold topic:
https://github.com/WebAssembly/WASI/issues/401#issue-8177488...
The problem with WASI is that it is a some kind of truncated copy of CloudABI and POSIX. With all the goodies like abbreviated error codes like "fbig", "idrm", "srch" and etc. See: https://github.com/WebAssembly/WASI/blob/0ba0c5e2e37625ca5a6...
The main problem of WASI in my opinion is that it's based on a standard which is 30 years old. And yes, the idea was cool, to let you run even C without having to rewrite libc. But the reality is that we can't do this now and it's still a big question whether we can in the near future. Besides, C is probably the only one that needs such a low level api, but everyone has to suffer because of it, essentially reinventing libc based on WASI with their own language runtime on top of it. This is simply a waste of binary space.
Al
Read the rest
so it lead to fragmentation into the WebAseembly ecosystem. A compiled program in wasm32-wasi cannot run in a browser, only in wasmtime, wasmer or node.js. WASI-polyfill.js is very limited, adds a bunch of kilobytes of glue code and is still not even officially introduced.
Hi, author here. All examples should have used `lunatic::net`, I fixed it now.
The reason why we provide `lunatic::net` and you can't just use `std::net` is that WASI (system interface for WebAssembly) still doesn't have support for sockets[0]. `lunatic::net::TcpStream` is for now just a drop in replacement for `std::net::TcpStream` and once sockets get standardised you will be able to use the standard library types instead.
[0]: https://github.com/WebAssembly/WASI/pull/312
In Rust without the async (hard) part> The rejection from the Bytecode Alliance was based on a history of behavior that isn’t compatible with the BA codes of conduct—both the individual CoC and the organizational CoC.
>
> We made both of these points explicit in the rejection email. In that email, we also said that if Wasmer established a track record of positive engagement, we would re-evaluate.
From a BA member[0]. If I was you, I'd start reading some interpersonal communication books ASAP and really take some time to reflect deeply on what is happening here. It seems like a lot of people around you are making decisions that gravely impact your business and personal future (your lawyers trademarking things without you understanding what, the Bytecode Alliance rejecting you, people alleging harassment, etc.) and you're having a hard time understanding what they are doing an
Read the rest
Wasmer is considered a bad actor by many, and there are many in the WASM space who want nothing to do with them. It's no accident Wasmer isn't a part of the Bytecode Alliance [1].
A particularly damning incident was the time they tried and failed to trademark "WEBASSEMBLY", an open W3C standard [2] [3]. There are many choice words for companies trying these kinds of stunts.
Webassembly is growing despite Wasmer's existence. Not because of them. Be cautious.
[1]: https://bytecodealliance.org/
[2]: https://tsdr.uspto.gov/documentviewer?caseId=sn88703780&docI...
[3]: https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...
In Show HN: WAPM – WebAssembly Package ManagerI know what WASI is, my point is that there is no where near parity with existing posix implementations. I have been following the bytecode alliance and webassembly communities for a while and they can't seem to get beyond the design phase. You only need to look at the networking API [0] and the thread has not been updated for two months, with prior to that folks asking is the work even happening still
[0] https://github.com/WebAssembly/WASI/issues/370
In Pay attention to WebAssemblyI'll ask the same questions I had over on lobsters since I didn't get satisfactory answers there:
* 64bit - Can I run a database that addresses more than 4 gig of memory (eg: keep all my indices in memory so perf doesn't fall off a cliff)? I think the answer is no. This effectively rules out most 'enterprise' software and most things involving 'big data' (eg: all ai/ml projects), not to mention I haven't deployed 32bit to prod in something like 10 years.
* threads - shared array buffers && web workers aren't threads - this isn't the biggest deal in the world since all interpreted languages are effectively single process/single thread but there is quite a lot of software that would like real threads.
* security - You can overwrite constants in what traditionally would be read-only. You can overwrite portions of the stack. You can overwrite
Read the rest
the heap. You can overwrite function pointers. You can overwrite and redirect indirect calls. Taking an existing linux binary and converting it to wasm severely downgrades the security of it.
* real sockets/TLS - https://github.com/WebAssembly/WASI/pull/312 && https://github.com/bytecodealliance/wasmtime/issues/71 ? yes, I understand some people have shimmed in various layers here but most applications would currently require modification to use said shims - what's the best of breed to not require application mods?