Why Compute does not yet support JavaScript
Chief Product Architect, Fastly
The vision for our serverless compute environment, Compute, is for developers to build incredibly secure, performant apps and experiences at the edge using the languages they know and love. So it’s no wonder why one of our most frequently asked questions is, “Why doesn’t Compute support JavaScript?”
This question is a valid and important one, as other serverless options do support JavaScript. We’ve shared before about how we evaluate new languages for Compute, noting that JavaScript cannot yet compile to WebAssembly, the tech on which Compute is built. And the good news is that we’re currently evaluating AssemblyScript to satisfy this need. AssemblyScript (a strict subset of TypeScript, where Typescript is a typed superset of JavaScript) allows you to use the JavaScript programming model and syntax while still maintaining the type-safety and performance benefits of WebAssembly.
But the question still remains: why didn’t we take the path of least resistance and use an off-the-shelf technology like V8 that has JavaScript support built-in? Why did we choose the much harder path of building our own compiler toolchain from the ground up?
To buy or to build?
Fastly has a long history of looking at problems from first principles and being unafraid to undertake difficult projects if we know they will benefit our customers. Building our own custom routing infrastructure may have seemed like a foolish undertaking for a then one-year-old startup, but existing networking solutions forced a tradeoff between performance and control. It was only by doing it ourselves that we could achieve both the performance and flexibility that we knew were required — a decision that is still paying dividends to this day.
Applying this principle to Compute
Similarly, existing serverless technologies force a tradeoff between performance and security. A “cold start” the first time a serverless function is run takes much longer than subsequent “warm starts” where everything has already been initialized. Some technologies partially mitigate this problem by reusing the environment across many requests in order to amortize the cold start costs across many function invocations. But this turns a performance problem into a security problem: there is an entire class of security vulnerabilities created by reusing environments. Attackers can attempt to access “leftover” data from previous invocations or deliberately poison the environment to damage subsequent invocations.
By eliminating cold start costs, we could create a solution that was both performant and secure. So that’s exactly what we did. Compute startup times are under 35 microseconds, allowing us to give every single request a completely clean operating environment — eliminating the possibility of data persisting between invocations.
Supporting JavaScript the right way
To consistently strike this balance while also supporting your most-loved language, we’re taking steps to support JavaScript with AssemblyScript in the near future, so stay tuned. We continue to invest in expanding the scope of Compute and are excited to see how our customers harness its potential — no matter their language of choice.
