syrusakbary

I wonder if they could use Wasmer to execute Javascript under the hood without limitations.

This is awseome, I didn't know this was possible and may replace the need of using Cranelift for having fast builds of Wasm bytecode into assembly in Wasmer.

If you want to run in a WebAssembly runtime, perhaps Wasmer can be a good choice for you.

Note: we don't support .NET or Java atm, but we support PHP and Python is about to be fully supported!

https://wasmer.io/products/edge

The article is awesome. Thanks for the mention to Wasmer and WinterJS.

Cool things coming in the pipeline!

That's an interesting project!

We have an opening in Wasmer to work on the compiler side of things, I think you could be a great fit: https://www.workatastartup.com/jobs/15822

Hey!

I'm Syrus, from Wasmer. I think the people from the Bytecode Alliance are still working on WASI, but are currently fully focused on WASIp3.

WASIp3 faces the same issues as normal WASI when compiling C libraries and apps: no thread or signals support, lacking compatibility with most of POSIX, with the added challenge that it also breaks compatibility with the original WASI.

At Wasmer we have been working on WASIX, which is a superset of WASI and adds support for the mentioned features: threads, signals, forking, subprocesses... and makes most of programs compile to Wasm easily (like Emscripten). The only con is that Wasmer is currently the only runtime that supports it (although we would love to have integration in more!).

We have been able to compile bash, CPython, PHP and many more running successfully without limitations.

Feel free to take a look here: https://wasix.org/

Fair! We have already plans to solve the patching issue you commented... stay tuned!

> After delving into this, it seems Wasmer tried, but as they weren't standards compliant, adoption/ecosystem support never followed.

You may be surprised by how much WASIX is being adopted by the ecosystem! Aiming it to be full POSIX compliant has proven incredibly powerful, as there's no need for waiting for other entities to reinvent what already works in the POSIX (macOS, Linux, ...) :)

This is super interesting! I would be very curious to see how we can get into even more safety when running WebAssembly in Wasmer with this crate (similar to V8 isolates).

Awesome work!

Hats off to the creator big way.

Really amazing stuff, and impressive dedication. To the author: if you would like to work on challenges of similar caliber, ping me (I'm Syrus, from Wasmer)

The article is completely on point.

Personally, I don't think that Cloudflare is the best provider for Wasm at the Edge as everything needs to go through a Javascript layer that eventually hurts performance and prevents further optimization, but is a strong one nontheless (note: take everything with a grain of salt, even though I try hard to not be biased, I'm also founder of Wasmer)

> "The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated."

Wasmer launched WASIX [1] a few years ago which fulfills the vision that the article describes. With WASIX you can have sandboxed access to:

  1. Filesystem
  2. Networking / Sockets
  3. Processes
  4. Threads

[1] https://wasix.org/

Is this blogpost generated by AI? Most of the things “make sense” isolated but the whole post is nonsense (pip install pyodide? reqs/s in pyodide?)

It seems the issue was not up to date, thanks for pointing it out (just commented in Github to make it clear for future readers).

Wasmer supports most of the Wasm-C-API, with some exceptions for APIs that are not that common to use: finalize, hostref and threads (tables just had some quirks on the implementation that we had to polish, but is generally implemented [1]).

https://github.com/wasmerio/wasmer/blob/main/lib/c-api/tests...

If you are interested in running any of these cases using Wasmer via the Wasm-C-API please let us know... it should be mostly trivial to add support!

[1] https://github.com/wasmerio/wasmer/blob/main/lib/c-api/src/w...

"Mistakes teach us, forgiveness frees us" - ChatGPT (o3-mini)

https://wasmer.io/posts/wasmer-and-trademarks

Indeed, we need to improve further the base binary size!

Most of the size comes from the LLVM backend, which is a bit heavy. Wasmer ships many backends by default, and if you were to use Wasmer headless that would be just a bit less than a Mb.

If you want, you can always customize the build with only the backends that you are interested in using.

Note: I've seen some builds of LLVM under 5-10Mb, but those require heavy customization. Is clear that we have still some work to do to reduce size on the general build!

Pro tip: ask about their previous experience and go deep there. It will be impossible for the AI to generate fake experience on a user, and very easy to catch for the interviewee

This is an interesting approach, great work!

For anyone that wants to check where the meat is at, is mostly in this file: https://github.com/irrio/semblance/blob/main/src/wrun.c

Thinking out loud, I think it would have been a great idea to conform with the Wasm-C-API (https://github.com/WebAssembly/wasm-c-api) as a standard interface for the project (which most of the Wasm runtimes: Wasmer, V8, wasmi, etc. have adopted), as the API is already in C and it would make it easier to try for developers familiar with that API.

Note for the author: if you feel familiar enough with Wasm and you would like to contribute into Wasmer, we would also welcome any patches or improvements. Keep up the work work!

This is an awesome use of WASIX [1] and the Wasmer SDK [2]. Quite exciting to see!

I recommend as well reading through the blogpost (repo on [3]): https://lights0123.com/blog/2025/01/07/hip-script/ (many things to improve on the Wasmer side... we have some work to do!)

[1] https://wasix.org/

[2] https://github.com/wasmerio/wasmer-js

[3] https://github.com/lights0123/hipscript/

Thanks for the feedback! I'm Syrus, from Wasmer. We are currently working on redesigning the homepage so its easier to know what we do and what is our business value. Stay tuned :)

Nice, thanks for the benchmark Yuri!

Nice! I didn’t know the project. Thanks for sharing!

The whole LLVM toolchain is a bit big. I think we can reduce much more the size. We actually researched on using tcc but unfortunately tcc doesn’t have a wasm backend (for generating wasm output). It would be awesome if they added it!

The Clang WASI SDK weights about 100Mb compressed. We optimized things a bit but still have a way to go (we are not yet compressing in the network). I believe we can serve everything in about 30Mb

Wasmer (https://wasmer.io/) | Frontend Software Engineers | Hybrid (EU Timezones + Madrid Office) | Full Time

At Wasmer we are working on the software that will power the next generation of Cloud Computing platforms using WebAssembly. Similarly to Node.js, we are moving WebAssembly to the server-side but completely emancipated from JavaScript.

We are seeking a skilled frontend developer with industrial-strength software engineering skills to help us build our the Wasmer website. Stack: JS/TS. React/Next.js + Tailwind + GraphQL (Relay)

Reach out to syrus [at] wasmer.io or apply via Work at a Startup [1]

[1] https://www.workatastartup.com/jobs/45795

You don't need to modify an already running program, you can plug new functions into an existing Wasm program via a table, and even attach variables via globals or function arguments.

I'd recommend checking the work on making SpiderMonkey emit Wasm as a backend

Thanks for the correction Tzvetan! Keep up the great work in Static Hermes

Thanks!

Since Porffor can compile itself (you can run the compiler inside of Porffor), any calls to eval could be compiled to Wasm (via executing the Porffor compiler in Porffor JS engine) and executed performantly on the same JS context *

*or at least, in theory

It's awesome to see how more JS runtimes try to approach Wasm. This project reminds me to Static Hermes (the JS engine from Facebook to improve the speed of React Native projects on iOS and Android).

I've spent a bit of time trying to review each, so hopefully this analysis will be useful for some readers. What are the main commonalities and differences between Static Hermes and Porffor?

  * They both aim for JS test262 conformance [1]
  * Porffor supports both Native and Wasm outputs while Static Hermes is mainly focused on Native outputs for now
  * Porffor is self-hosted (Porffor is written in pure JS and can compile itself), while Static Hermes relies on LLVM
  * Porffor currently doesn't support async/promise/await while Static Hermes does (with some limitations)
  * Static Hermes is written in C++ while Porffor is mainly JS
  * They both support TypeScript (although Static Hermes does it through transpiling the TS AST to Flow, while Porffor supports it natively)
  * Static Hermes has a fallback interpreter (to support `eval` and other hard-to-compile JS scenarios), while Porffor only supports AOT compiling (although, as I commented in other thread here, it maybe be possible to support `eval` in Porffor as well)

In general, I'm excited to see if this project can gain some traction so we can speed-up Javascript engines one the Edge! Context: I'm Syrus, from Wasmer [3]

[1] https://github.com/facebook/hermes/discussions/1137

[2] https://github.com/tc39/test262

[3] https://wasmer.io

I'm amazed on how well this article fits with a new product that we have been working on at Wasmer. AWS Lambda is great, but it doesn't really solve the cold start problem of dynamic languages. Nor does FastCGI.

We are very close to launch Instaboot, a new feature for Wasmer Edge that thanks to WebAssembly is able to bring incredible fast cold-starts to dynamic languages. Bringing 90ms cold-start times to WordPress (compared to >1s in state-of-the-art cloud providers).