syrusakbary
TL;DR: WASI 0.3.0 is the Component Model-based WASI proposal. It adds async/await-style capabilities such as actors and streams, and today is runnable in only one server-side Wasm runtime (it is not supported natively by browsers). Unfortunately it still breaks compatibility with the original WASI proposal and runtimes that supported it.
If your goal is to compile existing, unmodified C/C++ programs and libraries to WebAssembly, WASIX may be a more practical option today ( https://wasix.org/ ). Disclosure: I’m part of Wasmer, the company behind WASIX.
Good work to everyone on the Deno team!
We are building the next generation of infrastructure for AI without Docker containers, but with a better container technology based on WebAssembly!
We are hiring for:
* Rust Engineer (Remote, EU timezone)
* Rust Distributed Engineer (Remote, EU timezone)
* Developer Education Engineer (Office, San Francisco)
https://www.workatastartup.com/companies/wasmerWasmer (YC S19) Is Hiring – Rust and DevRel Positions
Nanobrew: The fastest macOS package manager compatible with brew
I think the fact that WASIX is much more mature now have helped to increase development speeds quite a bit!
We actually believe Edge.js will a great use case for LLM-generated code.
This was intentional, as a demonstration that Edge and Node should not diverge a bit. You should be able to replace `node` with `edge` in your terminal and have things running, so that's why we point to the Node.js docs.
> But why the need of --safe then? What's the difference between using it and not using it?
Edge.js currently runs without a sandbox by default. The main reason for this is two fold: native currently performs a bit better than with the Wasm sandbox (about 10-20% better), and because we wanted to polish more the Wasm integration before offering it as default.
> $ edge pnpm run dev > What is this doing?
This is making the `node` alias available for anything that you put after edge. This allows pnpm to use the edge `node` alias instead of your platform node.
Things will be installed as usual, in your `node_modules` directory
It should probably take a few hours with AI to get a demo for it :)
Time is highly correlated with expertise. When you don’t have expertise, you may go fast at expense of stability because you lack the experience to make good decisions to really save speed. This doesn’t hold true for any projects where you rely on experts, good processes and tight timelines (aka: Apollo mission)
And yes, it will allow running Node.js apps fully on the browser, in a way that’s more compatible than any other alternative!
Stay tuned!
What was the most confusing thing in the blogpost? I'd like to polish a bit more to make it clearer! Thanks a lot!
As a fun exercise, you can try reading process.cwd() from edge in --safe mode and without it.
I'm Syrus, from Wasmer. We built Edge.js in a few weeks after different trials trying to bring Node.js to the Edge. We used AI and Codex heavily for this project, as otherwise the timeline would have spanned to a year plus to develop.
The summary of this announcement is that Edge.js:
* Runs using WebAssembly when in `--safe` mode
* It's fully compatible with Node.js (passing all their spec tests for non-VM modules)
* It has a pluggable JS engine architecture: can work with V8, Javascript, SpiderMonkey, QuickJS, Hermes, etc.
Super happy to answer any questions you may have!Note aside, OpenJS executive director mentioned it's ok to use AI assistance on Node.js contributions:
I checked with legal and the foundation is fine with the DCO on AI-assisted contributions. We’ll work on getting this documented.
[1]: https://github.com/nodejs/node/pull/61478#issuecomment-40772...With it, you have a virtual fs automatically, just by using the `node:fs` package (or any other filesystem calls!)
We wrote about this in depth here: https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...