HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
cloudflare
workers-wasi
C++2022–2023
cloudflare / workers-wasi

workers-wasi

Discover this repository through its Hacker News conversations.

Explore on GitHubRead Hacker News discussions
5Distinct people
5Mentions
0Explicit recommenders
161GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A public description has not been verified.

Where it is used

No documented product use has been verified yet.

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

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 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 month5 dated mentions

Observed mentions: 2022-06-19 15:44:00 UTC to 2023-11-15 18:28:18 UTC.

012022-06-01 00:00:00 UTC to 2022-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJun 20222022-07-01 00:00:00 UTC to 2022-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-01 00:00:00 UTC to 2022-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-09-01 00:00:00 UTC to 2022-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-01 00:00:00 UTC to 2022-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-01 00:00:00 UTC to 2022-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2023-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-01 00:00:00 UTC to 2023-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsFeb 20232023-03-01 00:00:00 UTC to 2023-04-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-04-01 00:00:00 UTC to 2023-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-05-01 00:00:00 UTC to 2023-06-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-06-01 00:00:00 UTC to 2023-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-09-01 00:00:00 UTC to 2023-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsNov 2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jun 20222022-06-01 00:00:00 UTC2022-07-01 00:00:00 UTC101
Jul 20222022-07-01 00:00:00 UTC2022-08-01 00:00:00 UTC000
Aug 20222022-08-01 00:00:00 UTC2022-09-01 00:00:00 UTC101
Sep 20222022-09-01 00:00:00 UTC2022-10-01 00:00:00 UTC000
Oct 20222022-10-01 00:00:00 UTC2022-11-01 00:00:00 UTC000
Nov 20222022-11-01 00:00:00 UTC2022-12-01 00:00:00 UTC000
Dec 20222022-12-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
Jan 20232023-01-01 00:00:00 UTC2023-02-01 00:00:00 UTC000
Feb 20232023-02-01 00:00:00 UTC2023-03-01 00:00:00 UTC000
Mar 20232023-03-01 00:00:00 UTC2023-04-01 00:00:00 UTC101
Apr 20232023-04-01 00:00:00 UTC2023-05-01 00:00:00 UTC000
May 20232023-05-01 00:00:00 UTC2023-06-01 00:00:00 UTC101
Jun 20232023-06-01 00:00:00 UTC2023-07-01 00:00:00 UTC000
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC000
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC000
Sep 20232023-09-01 00:00:00 UTC2023-10-01 00:00:00 UTC000
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC000
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC101

What Hacker News says

5 sources
w10-1·Nov 15, 2023
The examples seemed clear enough to read (I did not test them), but I felt than even when teaching by example there needs to be more overview and explanation. I.e., I would prefer an overview of WASM structure and use with examples, rather than just the examples. (I have some (but limited) experience using WASM.) As for the utility of wasm, note also that Cloudflare workers can run WASM on edge servers [1], and that the Swift community has some support for compiling to wasm [2]. I've never really understood how wasm could do better than java bytecode, but I've been impressed with how much people are using lua and BPF. More generally, in a world of federated programming, we need languages client can submit that providers can run safely, without obviously leaking any secret sauce -- perhaps e.g., for model refinement or augmented lookup.
Read the rest
[1] https://github.com/cloudflare/workers-wasi [2] https://github.com/swiftwasm
In WASM by example
angelmm·May 24, 2023
Those are great questions! I believe Emscripten will be required for some cases as it provides more features for targeting a Web Browser. If WASI is the only requirement for a Wasm module, then there are three possible solutions: - Use a library that provides the WASI bindings in a browser environments: there are some OSS projects that provides WASI bindings on top of browser technologies. For example, workers-wasi from Cloudflare [1]. It could be even another Wasm module that provides the implementation for the main one. I know the people from Loophole Labs are experimenting with virtual filesystems (VFS) [2]. - Browsers provides a WASI implementation: server-oriented runtimes like NodeJS are already providing these bindings (under a experimental flag). I shouldn't have stated that as a fact, as browsers may provide it or not. However, I
Read the rest
saw in the past the Google Chrome team experimenting with WASI and the browser FileSystem API [3]. So, I think it may happen :) - [1] https://github.com/cloudflare/workers-wasi - [2] https://www.youtube.com/watch?v=46jZSXVxYPw - [3] https://github.com/GoogleChromeLabs/wasi-fs-access
In SQLite builds for WASI since 3.41.0
paulgb·Mar 24, 2023
Indeed, some people are doing this: - WASI once had an official polyfill https://wasi.dev/polyfill/, now apparently succeeded by https://github.com/bjorn3/browser_wasi_shim - wasmer-js provides a JS polyfill for WASI https://docs.wasmer.io/integrations/js/wasi - Cloudflare has a WIP polyfill https://github.com/cloudflare/workers-wasi I'm generally leery of non-temporary polyfills, so I'm not sure that any of these feel like a long-term viable option for me.
In The tug-of-war over server-side WebAssembly
aseipp·Aug 1, 2022
Yes, when they initially announced this feature, they actually demo'd running an unmodified Rust program compiled to wasm32-wasi. It just takes the HTTP body as stdin and writes the response from stdout, though, so it's limited: https://blog.cloudflare.com/announcing-wasi-on-workers/ I also did this recently but with the shim approach: a small Rust program that needs to run a cryptography operation on some input[1], compiled to wasi and operating on stdin/stdout, and then invoked by a larger Typescript program invoking it with the proper stream. Worked great. There is also a thing called workers-rs[2] which will let you write the entire worker in Rust, but it does not use WASI. WASI isn't really enough for anything beyond simple stdin/stdout pipelines without something "wrapping it" to provide the needed fds, env vars, arguments, etc. So
Read the rest
instead workers-rs binds to the underlying Worker runtime primitives, the ones normal JavaScript uses, and exposes that -- but it does all of the mangling/bindgen/shim bullshit for you in the background. The shim is unavoidable, and always exists behind the curtain, but this approach lets you completely ignore it. workers-rs doesn't support every API, though (e.g. no R2 support.) In theory, assuming you ported the workers-wasi interface to Rust[3] yourself, you could then write a Worker in Rust using workers-rs that load WASI-conformant WASM programs (written in XYZ) and execute that program on the request object. Sounds confusing but I think you get what I mean. [1] No, this operation wasn't provided by the WebCrypto API, as far as I'm aware, otherwise I probably wouldn't have bothered with the added complexity. [2] https://github.com/cloudflare/workers-rs [3] The underlying WebAssembly support comes from V8; WASI, then, is "just" an implementation of some very well known functions/APIs in the surrounding environment that the WASM program expects to exist, and behave in a certain way. So actually the entire workers-wasi framework is here, and if you ported this TypeScript interface to Rust, using workers-rs, you could invoke any WASI program similarly: https://github.com/cloudflare/workers-wasi/blob/main/src/ind...
In Running Zig with WASI on Cloudflare Workers

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.