Waden

[lastmjs]

Latest Thinking

We are thinking to wait on starting this project. This will give wasmedge-quickjs time to either continue to be unmaintained, strengthening the need for us to start our own project, or become maintained again and address our many issues. This also gives time for the Wasm component model to mature and continue its Wasm standardization path, along with its implementation in wasmtime and integration into ICP.

The only MAJOR functionality missing from wasmedge-quickjs right now is crypto, but we're just waiting on an ICP implementation of wasi-crypto.

We will continue to wait for now and push forward with major missing features in Azle. Once we begin to contemplate again production-readiness, this might be a good path to go down.

Azle is in many ways attempting to just be Node.js or Deno but executing in a wasm32-wasi/wasm64-wasi (Wasm) environment, with environment/OS APIs specific to ICP. This is a beautiful goal for the ICP ecosystem and hopefully Web3 at large. But there are a number of issues with our current design and long-term sustainability path.

• wasmedge-quickjs does not seem very well-maintained lately
• wasmedge-quickjs has many bugs
• wasmedge-quickjs does not have all of the Node.js stdlib implemented
• QuickJS is not one of the big JS engines that we know are very battle-tested and will be maintained well into the future
• QuickJS is much slower than V8 for example
• Azle is ICP-specific, but a lot of the work we're doing could benefit Web3 or Web2 at large

Waden is a theoretical WebAssembly runtime for TypeScript and JavaScript. That's it. It would be focused on providing the best possible support for TypeScript and JavaScript for the wasm32-unknown-unknown, wasm64-unknown-unknown, wasm32-wasi, and wasm64-wasi environments etc (probably focused mostly on wasi). It would be stand-alone and could be used by anyone.

It would have "bindings" or host imports or some mechanism to allow it to be ported into non-standard environments, or non-universal environments. For example, Azle could become the ICP bindings project. But we could have bindings for AO, CosmWasm, etc.

Perhaps Waden becomes extremely successful and battle-tested, providing an amazing resource to the Web3 and other ecosystems. This would be good for the whole space, maybe even the whole world. Its association with Demergent Labs and ICP would hopefully help the ICP ecosystem.

Demergent Labs could continue to focus on the Azle bindings, but itself or others could begin work on bindings for other ecosystems.

What problems would this solve?

The idea is to create an amazingly successful and well-respected JavaScript runtime that is built on top of rock-solid dependencies that will be well-maintained into the future. We would like to create a robust ecosystem of contributors to Waden, and because it will be so general-purpose and useful, hopefully there would be reason for many people to work on and maintain Waden. Environment-specific bindings would allow Demergent Labs and other teams to focus on the ecosystems that they are interested in.

Building a well-respected project used by many other ecosystems could bring ICP and Demergent Labs notoriety and respect, as the original home and major focus of one of the bindings would remain ICP. Could open many doors.

• Great way to attract contributors
• Great way to get to production-readiness
• Great way to gain notoriety and respect
• Great way to move all of Web3 and perhaps Web2 forward

How do we achieve this?

• Compile V8 or SpiderMonkey into wasm32-wasi
• Create or use Rust bindings to V8 or SpiderMonkey
• Port over Node.js or Deno libraries and ensure they work in wasm32-wasi
• Use existing test suites to ensure the project is as battle-tested and production-ready as possible
• Continue to focus on Azle as the ICP bindings
• Encourage or build other bindings
• Do we wait for the Wasm component model to mature?
• We want ICP to support Wasm components I think
• What if we made all of the Node/Web stdlib components? And make it extremely slick?
• Azle bindings could be components?
• All bindings could just be components