JavaScript support hits 1.0 milestone on Compute@Edge
Tags: news, javascript, fastly
Published: 2022-12-19 16:26:51

When Compute@Edge was launched, we talked about [why we didn’t fully support JavaScript](https://www.fastly.com/blog/why-edge-compute-does-not-yet-support-javascript) at that time. Support [was added](https://www.fastly.com/blog/compute-edge-now-supports-javascript) in July last year, and it has been an exciting journey to see what people have already built with the SDK at scale. With confidence in its stability we are proud to announce a 1.0 release of our JavaScript SDK. 

We listened to the community feedback, filled in feature gaps, and [addressed many bugs](https://github.com/fastly/js-compute-runtime/blob/main/CHANGELOG.md) in the SDK.  Not only that, we’ve also overhauled the [SDK reference docs](https://js-compute-reference-docs.edgecompute.app/) making it easier for you to know what’s supported and how to implement the features. All the Fastly specific features of the JS SDK now have [interactive example applications](https://js-compute-reference-docs.edgecompute.app/stable/classes/fastly_config_store.ConfigStore.html) in the documentation.

![Interactive examples in docs](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/041admda5z1gqqqoh80z.png)

We've also been building out [example code on our developer hub](https://developer.fastly.com/solutions/examples/javascript/) to showcase how to use JavaScript to address common use cases. Take a look at examples like [geo-tagging of requests](https://developer.fastly.com/solutions/examples/decorating-origin-requests-with-geoip), [capturing and aggregating log data from clients](https://developer.fastly.com/solutions/examples/no-origin-rum-logging), [normalizing requests to improve cache efficiency](https://developer.fastly.com/solutions/examples/normalize-requests), or [load balancing across multiple backends](https://developer.fastly.com/solutions/examples/random-director-with-weighted-probability). 

Want to deploy a site you've built using a JavaScript-based web framework?  We got you - check out our tools and instructions for [Gatsby](https://www.fastly.com/blog/gatsby-on-the-edge-in-under-2-minutes-with-fastly) and [Next.JS](https://www.fastly.com/blog/run-your-next-js-app-on-fastly).  [RemixJS is coming soon](https://github.com/remix-run/remix/pull/4860).

What if you have a dynamic backend in NodeJS running [ExpressJS](https://expressjs.com/)?  It'd be cool if Compute@Edge offered Express-like abstractions, so you can write server apps on Fastly using familiar constructs like route handlers and middleware. No problem! Check out [Expressly](https://expressly.edgecompute.app/), our Express-alike server framework at the edge!

![Expressly screenshot](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ejw1bny8lcivr0zrmjw.png)

There are blogs and tutorials to inspire you if you're after something more advanced too: learn more about [using JavaScript for A/B testing](https://developer.fastly.com/solutions/tutorials/ab-testing-edge-compute/), or create a [waiting room](https://developer.fastly.com/solutions/tutorials/waiting-room/) to handle traffic surges, for example.

## Our support for JavaScript is unique

In the serverless world, “cold starts” are the enemy. Even if a platform can run your code fast 99% of the time, an occasional 300ms delay while your app starts up can create debugging headaches, and these can easily add together in a microservices architecture and lead to much more frequent poor performance for end users.  At Fastly, we don't have cold starts because we don't do warm starts: your code starts from the same state on every request, and that startup takes microseconds. My colleague Lin Clark has explored [how we do this over on the Bytecode Alliance blog](https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly).

Speaking of which, as a founding member of the [Bytecode Alliance](https://bytecodealliance.org/), we're building an ecosystem of languages that can run on the server using WebAssembly, using the [Wasmtime](https://wasmtime.dev/) runtime.

For JavaScript we use [SpiderMonkey](https://spidermonkey.dev/) on top of Wasmtime, which provides spatial and temporal separation between concurrent tasks. Spatially, each request gets its own language runtime and memory heap. Temporarily, there is no state left over from previous requests. Starting from a fresh identical snapshot on every request makes debugging significantly easier. A bug in one task cannot affect subsequent or neighboring tasks.

## Future of JavaScript on Compute@Edge

We’ve solved the biggest security headaches of secure sandboxing, and have unmatched initialization performance of startup times, from cold, in the tens of microseconds. With the v1 release of our SDK we have achieved sufficient feature support in JavaScript while providing execution performance that is within a reasonable margin of modern JS JITs. But [we're going to make it even faster](https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly), so stay tuned.

## Not JUST JavaScript

And because our platform doesn't rely on a JavaScript engine at its core, you're not locked into one language - write JavaScript if you want to, but  if you need the robustness of strict static typing and lower level memory management, you could just as well use [Rust](https://developer.fastly.com/learning/compute/rust/) or [Go](https://developer.fastly.com/learning/compute/go/) instead.  And developers outside of Fastly have even made SDKs for languages we don't officially support yet: we celebrate them and [showcase them on our developer hub](https://developer.fastly.com/learning/compute/custom/).  All languages that run on Compute@Edge are equals on our platform.  

We love to see what our customers build. Find us on twitter at [@fastlydevs](https://twitter.com/fastlydevs) or tweet with `#builtonfastly` and let us know!