I’m with Smorgasbord1 on this one.
Why didn’t Fastly just use V8 like everybody else? If you didn’t know V8, is a runtime environment that was built into chrome to separate out tabs, so that if one tab crashes it didn’t affect the other tabs. V8 was built for browsers and wasn’t designed for the edge.
So Fastly skipped those off-the-shelf conventional serverless solutions on the market, like containers or the V8 Engine and chose the harder path to build their own runtime on top of WebAssembly.
Fastly open sourced Lucet, its native WebAssembly compiler and runtime designed to take WebAssembly beyond the browser, and build a platform for faster, safer execution on Fastly’s edge cloud.
This is core to their vision and what they see as building blocks for future Edge apps.
And like Smorg mentioned, Fastly took a similar path very early on to build their own software routing infrastructure from scratch to offer a lot of flexibility in load balancing and routing, instead of relying on expensive routers from Cisco and Juniper etc.
There’s a lot to like about FSLY’s technology. Having written a lot on NET and FSLY on this board, I’m still biased towards FSLY when it comes to the technology. The last time I checked, FSLY’s Compute@Edge was oversubscribed. So hopefully there’s good demand and things will go well and pay back in the future.
However, let’s keep in mind that WebAssembly is relatively new ( became a W3C recommendation on 5/12/2019 and alongside HTML, CSS, and JavaScript, is the fourth language to run natively in browsers. ) And the fact that the first WebAsssembly conference was held in February this year just before the pandemic hit hard. So a lot of this is pretty new stuff and it does look like there’s work to do before the full power of WebAssembly can be used to empower uses cases like…better performance of apps on low-end mobile phones etc.
Cheers!
ronjonb