Spin 2.0 – open-source tool for building and running WASM apps

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Onboard AI - ChatGPT with full context of any GitHub repo.
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern API for authentication & user identity.
  • teavm

    Compiles Java bytecode to JavaScript, WebAssembly and C

    Joel from our team worked on the initial prototype for WASI support in TeaVM (https://github.com/konsoletyper/teavm/pull/610), and we temporarily forked before the WASI support made it to the official repo.

    Good reminder to deprecate that now!

  • wit-bindgen

    A language binding generator for WebAssembly interface types

    Thank you!

    To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular.

    Due to Spin's heavy use of WASI and the component model, languages that have first party support in the WIT bindings generator (https://github.com/bytecodealliance/wit-bindgen) are the easiest to implement, followed by languages that can be built on top of the support for those with first party support.

    For example, the JavaScript support is built by embedding QuickJS (in particular, Shopify's Javy project — https://github.com/fermyon/spin-js-sdk), which then uses the Rust SDK.

  • Onboard AI

    ChatGPT with full context of any GitHub repo. Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at app.getonboardai.com.

  • spin-js-sdk

    https://developer.fermyon.com/spin/javascript-components

    Thank you!

    To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular.

    Due to Spin's heavy use of WASI and the component model, languages that have first party support in the WIT bindings generator (https://github.com/bytecodealliance/wit-bindgen) are the easiest to implement, followed by languages that can be built on top of the support for those with first party support.

    For example, the JavaScript support is built by embedding QuickJS (in particular, Shopify's Javy project — https://github.com/fermyon/spin-js-sdk), which then uses the Rust SDK.

  • jco

    JavaScript tooling for working with WebAssembly Components

    (As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have significant experience) and JCO (https://github.com/bytecodealliance/jco), and the web platform compatibility makes it a significantly better proposition for things like 3rd party dependencies).

    C# is an interesting one — the .NET team at Microsoft (and in particular Steve Sanderson from that team) has been making tremendous progress in ahead-of-time compilation for .NET and generating Wasm and WASI compatible binaries (as opposed to their initial approach on Blazor), and experimenting with that led us to build support for Spin as well.

    Finally, we do a lot to support other popular languages and their Wasm support — two examples: Python (https://github.com/bytecodealliance/componentize-py) and Java / TeaVM (https://github.com/fermyon/teavm-wasi), for which we haven't fully integrated Spin support, but we hope to get there soon.

    I hope this explains a bit our process on language support, happy to expand on any point here.

  • componentize-py

    (As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have significant experience) and JCO (https://github.com/bytecodealliance/jco), and the web platform compatibility makes it a significantly better proposition for things like 3rd party dependencies).

    C# is an interesting one — the .NET team at Microsoft (and in particular Steve Sanderson from that team) has been making tremendous progress in ahead-of-time compilation for .NET and generating Wasm and WASI compatible binaries (as opposed to their initial approach on Blazor), and experimenting with that led us to build support for Spin as well.

    Finally, we do a lot to support other popular languages and their Wasm support — two examples: Python (https://github.com/bytecodealliance/componentize-py) and Java / TeaVM (https://github.com/fermyon/teavm-wasi), for which we haven't fully integrated Spin support, but we hope to get there soon.

    I hope this explains a bit our process on language support, happy to expand on any point here.

  • teavm-wasi

    Friendly fork of TeaVM with support for WASI and the WebAssembly Component Model

    (As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have significant experience) and JCO (https://github.com/bytecodealliance/jco), and the web platform compatibility makes it a significantly better proposition for things like 3rd party dependencies).

    C# is an interesting one — the .NET team at Microsoft (and in particular Steve Sanderson from that team) has been making tremendous progress in ahead-of-time compilation for .NET and generating Wasm and WASI compatible binaries (as opposed to their initial approach on Blazor), and experimenting with that led us to build support for Spin as well.

    Finally, we do a lot to support other popular languages and their Wasm support — two examples: Python (https://github.com/bytecodealliance/componentize-py) and Java / TeaVM (https://github.com/fermyon/teavm-wasi), for which we haven't fully integrated Spin support, but we hope to get there soon.

    I hope this explains a bit our process on language support, happy to expand on any point here.

  • zig-spin

    🦎 🪀 [WIP] Zig SDK for the Spin serverless application framework created by @fermyon.

    Hey, jesdict1!

    Check out this community project that adds support for Zig — https://github.com/tensorush/zig-spin.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • wasmedge-quickjs

    A high-performance, secure, extensible, and OCI-complaint JavaScript runtime for WasmEdge.

    I'm impressed you're already leveraging the component model. I thought it wasn't quite ready for primetime yet, but it seems you're proving that wrong... I'll have to dig in more here, as I'm working embedding WebAssembly in a high performance storage engine.

    Thanks for the notes! I hear you on QuickJS - I've seen approaches of folks trying to build more node compatibility on top of quickjs (ala https://github.com/second-state/wasmedge-quickjs), but have recently heard about spidermonkey in wasmtime. Do you have intuition for nodejs vs browser in terms of what people want in terms of compatibility?

  • spin-trigger-sqs

    A trigger plugin for processing SQS messages using Spin

    We made that choice primarily because we want to leverage the really good startup times for Wasm (and in particular for Wasmtime), and not running any guest code (in this case, business logic) until there is an actual incoming request means the server can execute other applications while idle.

    Now, HTTP workloads are not the only type of workloads that Spin can handle — because of the way it's built, it's entirely pluggable and you can build your own trigger (for example https://github.com/fermyon/spin-trigger-sqs), and potentially have long-running processes, but that is not currently possible with Spin today.

  • extism

    The framework for building with WebAssembly (wasm). Easily load wasm modules, move data, call functions, and build extensible apps.

    you may want to take a look at https://github.com/extism/extism

  • lunatic

    Lunatic is an Erlang-inspired runtime for WebAssembly

  • wasmtime

    A fast and secure runtime for WebAssembly

    Thanks for the question!

    Spin could definitely run in more places than what we have pre-built binaries for. Specifically, we could run on all platforms Wasmtime supports today (https://github.com/bytecodealliance/wasmtime/releases/tag/v1...), including RISC and S390X, for example.

    And while we have been experimenting a bit with running Spin on RISC, we haven't really had the bandwidth or requirement to build a production build for those yet.

    Are you interested in a specific operating system or CPU architecture? Would love to understand your scenario.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts