Introducing our Next-Generation JavaScript SDK
Today we’re happy to announce the availability of our brand-new JavaScript SDK. This SDK is a complete rewrite of our previous JavaScript SDK, with much improved ecosystem compatibility, standards compliance, robustness, and key new features.
This release also sets us on a path towards significant performance improvements and ongoing improvements to compatibility with existing JavaScript applications.
At the same time, we’re retaining a high degree of compatibility with the previous SDK, so upgrading should be straightforward for most users.
Let’s dive into more detail on what’s new and different about this release.
Building on the robust foundations of SpiderMonkey, StarlingMonkey, and ComponentizeJS
Where the previous SDK was built on top of the QuickJS JavaScript engine and the Javy runtime, the new SDK is built on top of the Firefox browser’s SpiderMonkey engine, and the Bytecode Alliance’s StarlingMonkey runtime and ComponentizeJS WIT bindings generator.
Together, these projects provide a fantastic foundation for our SDK:
- SpiderMonkey is the JavaScript engine that powers the Firefox browser. It’s been in development for over 20 years, is used by millions of users every day, and can claim a degree of maturity that really only the big browser engines can.
- StarlingMonkey is a JavaScript runtime we’ve built together with our friends at Fastly and contributed to the Bytecode Alliance. It’s built on top of SpiderMonkey in a highly modular way, making it easy to configure as needed for our use case. Crucially, it comes with an implementation of key web APIs that substantially improve compatibility with the web ecosystem, like the fetch API for handling outgoing HTTP requests, key parts of the Service Workers spec for handling incoming requests, streaming processing of request and response bodies using the web’s Streams API streams
setTimeout, andsetInterval. - ComponentizeJS is a tool that enables using external interfaces defined in the WIT interface description language in JavaScript. That makes it easy to use not only the interfaces Spin provides in addition to what’s included in WASI, but also functionality implemented in other WebAssembly components, including ones written in other languages such as Rust, Go, Python, or C/C++.
Radical Change Under the Hood, Small Tweaks on the Surface
As described above, the new implementation of our JS support could hardly be more different from the old one. The good news is that, thanks to the fact that JavaScript has an exceptionally robust specification, we can do all this without risking subtle breakage of existing code. While the new SDK comes with a slightly tweaked API that requires equally slight changes when upgrading existing projects, entirely replacing the underlying platform otherwise does not have any compatibility impact.
From there, they can then start taking advantage of the new features that the new SDK brings. Notably, we tweaked the API to make it easy to integrate streaming HTTP bodies without having to completely rewrite existing code.
New, standards based APIs
We implemented support for (a slightly tweaked version of) the existing APIs on top of the fetch API and Service Workers spec standards. Developers can choose to directly work with these standards if they prefer, giving them substantially improved compatibility with the broader web and JS ecosystem.
Standards help in a completely different way, too: since all of the HTTP support is now built using wasi-http, applications built with the new SDK that don’t make use of the Spin-specific APIs we also support can run in any environment that supports wasi-http, such as Wasmtime and Node.js (via JCO).
Just the beginning
With this release, we focused on changing the underlying platform for our JavaScript support in a drop-in compatible way, while already gaining support for modern web standards, composability with other WebAssembly components, and a more robust and mature foundation for future development.
Going forward, we’ll see rapid improvements in performance, compatibility, and new features. As a sneak peek, some of the most exciting developments in the works are:
- Performance improvements: the Fastly team has been working on substantial performance improvements for JavaScript execution in WebAssembly. A first iteration of this work has just been integrated into StarlingMonkey and is already making execution several times faster, depending on the exact workload. This integration landed just yesterday and thus hasn’t been integrated into our JS SDK yet, but will be soon.
- Improved compatibility with the web and JavaScript ecosystem: we’re close to landing a key improvement to StarlingMonkey: the ability to implement parts of the runtime itself, and of the web APIs it provides, in Rust instead of C++. This will make it much easier to keep up with the latest developments in the web ecosystem, and to provide a more complete and compatible implementation of the web APIs that are crucial for compatibility with existing JavaScript applications. Not all JS code uses (web-)standards based API: a lot of code out there makes use of Node.js APIs. We’re working on providing a compatibility layer for these APIs, so that developers can use them in their Spin applications.
- Support for more trigger types: currently, the new JavaScript SDK only supports HTTP triggers. We’re working on adding support for more trigger types, such as the Cron and Redis triggers.
Stay In Touch
We’re excited to be able to share this new SDK with you, and we’re looking forward to your feedback and contributions as we continue to improve it. Please join the chat in the Fermyon Discord server or our weekly project meetings, and follow us on X (formerly Twitter) @fermyontech and @spinframework!
