Wasmer: relation to wasmtime?

Created on 6 Feb 2019  ·  4Comments  ·  Source: wasmerio/wasmer

This project seems to share many of the goals of https://github.com/CraneStation/wasmtime.

Are they two experiments with the same goals, or are they fundamentally different in some way? Very supportive of both projects!

❓ question

Most helpful comment

Thanks for asking, @vitiral.

Before starting Wasmer, we took a deep look into all the different alternatives for executing WebAssembly, including wasmtime (and WAVM, wasmjit, nebulet...).

After playing with wasmtime in October, it didn't seemed a good fit as it was impossible to run any wasm file with it and the project seemed unmaintained (as the last significant commit was a few months distant).

wasmtime commit log
screen shot 2019-02-06 at 9 25 50 am

So we decided to create our own runtime.

After a month working on wasmer, the creator of wasmtime decided to put more effort on it rather than supporting wasmer.
That was a sad decision, because we talked about moving from wasmtime to wasmer but it didn't happen.

Right now, however the two projects differ on their goals.

Main differences

  • Wasmer goal is to be the universal runtime for WebAssembly
  • Wasmer is trying to abstract the API from the IR itself (Cranelift), so we can use LLVM for example to target other chipsets (such as RISC-V or ARM)
  • Wasmer goal is to be highly pluggable, so it's easy to plug custom ABIs (imports/exports) such as Emscripten or CloudABI.
  • Wasmer can be easily embedded in other applications
  • Wasmer is backed by commercial use cases and applications

Other than that, we have now a full team working on it and making sure other projects can use our runtime very easily. As far as I'm aware only one person is working on wasmtime.

All 4 comments

Thanks for asking, @vitiral.

Before starting Wasmer, we took a deep look into all the different alternatives for executing WebAssembly, including wasmtime (and WAVM, wasmjit, nebulet...).

After playing with wasmtime in October, it didn't seemed a good fit as it was impossible to run any wasm file with it and the project seemed unmaintained (as the last significant commit was a few months distant).

wasmtime commit log
screen shot 2019-02-06 at 9 25 50 am

So we decided to create our own runtime.

After a month working on wasmer, the creator of wasmtime decided to put more effort on it rather than supporting wasmer.
That was a sad decision, because we talked about moving from wasmtime to wasmer but it didn't happen.

Right now, however the two projects differ on their goals.

Main differences

  • Wasmer goal is to be the universal runtime for WebAssembly
  • Wasmer is trying to abstract the API from the IR itself (Cranelift), so we can use LLVM for example to target other chipsets (such as RISC-V or ARM)
  • Wasmer goal is to be highly pluggable, so it's easy to plug custom ABIs (imports/exports) such as Emscripten or CloudABI.
  • Wasmer can be easily embedded in other applications
  • Wasmer is backed by commercial use cases and applications

Other than that, we have now a full team working on it and making sure other projects can use our runtime very easily. As far as I'm aware only one person is working on wasmtime.

Awesome, thanks for the breakdown. It might be worth putting a bit of this in README (at least a link to your answer). I consider my question answered :smile:

Quite a bit can change in a year and a half (when the above exchange occurred), and I thought it would only be fair to point out to others who find this thread that the core wasmtime runtime now has almost 4x the contributors as wasmer's (204 v. 55), and has 9 contributors in the last week versus 1 for wasmer.

wasmtime: https://github.com/bytecodealliance/wasmtime/pulse

wasmer: https://github.com/wasmerio/wasmer/pulse

Here's a recent, thorough blog post that compares the two runtimes and concludes they are similar in their current functionality and performance: https://wiki.alopex.li/ActuallyUsingWasm .

I'm genuinely excited about both efforts! wasmtime has some impressive companies behind it (Mozilla, Intel, Fastly, Red Hat), but if there's a startup worth betting on it would be one that's gone through YC as Wasmer has :-) .

Thanks for commenting @elimisteve.

Let me address some of the comments:

  1. Contributors. The number of contributors you are seeing for wasmtime are on almost it's majority related the Cranelift IR. This is mainly caused because they decided to merge both projects (wasmtime and cranelift) together 😉
  2. Pulse on activity for Wasmer. While it looks like wasmer doesn't have a lot of recent commits, the main reason is because we are working on a lot of stuff under the hood that will be released soon (stay tuned!).
  3. Performance/Speed. Wasmer is way, way ahead on this one... stay tuned for more numbers!

We really appreciate the effort that some of their developers are doing to move wasm tooling forward, which will be great for the ecosystem on the long term and super useful for their browser.

I'd like to conclude saying that the tradeoffs to make when running Wasm server-side are quite different to when running in the browser.
And for the server-side spectrum... we are the leaders, not only because we have many more number of installs, or because Wasmer is much faster than wasmtime (50% faster in coremark), but because of the great community that is behind us 😊

Was this page helpful?
0 / 5 - 0 ratings