<story><title>Netlify Edge Functions: A new serverless runtime powered by Deno</title><url>https://www.netlify.com/blog/announcing-serverless-compute-with-edge-functions</url></story><parent_chain><item><author>lewisjoe</author><text>This is great news. I&amp;#x27;m really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs.&lt;p&gt;While the general trend today is to back the serverless environment with Javascript runtimes (Cloudflare runs its edge on top of V8, Netlify uses deno, most other serverless runtimes use nodejs), I&amp;#x27;m optimistic that WebAssembly will take over this space eventually, for a bunch of reasons like:&lt;p&gt;1. Running a WASM engine on the cloud means, running user code with all security 
controls, but with a fraction of the overhead of a container or nodejs environment. Even the existing Javascript runtimes, comes with WebAssembly execution support out of the box! which means these companies can launch support for WASM with minimal infra changes.&lt;p&gt;2.It unlocks the possibility of running a wide range of languages. So there’s no lock-in with 
the language that the Serverless provider mandates.&lt;p&gt;3.Web pages that are as ancient as the early 90s are perfectly 
rendered even today in the most modern browsers because the group behind 
the web standards strive for backward compatibility. WebAssembly’s specifications are 
driven by those same folks - which means WASM is the ultimate format for any form of 
code to exist. Basically, it means a WASM binary is future proof by default.&lt;p&gt;I&amp;#x27;ve published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique, here - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;writer.zohopublic.com&amp;#x2F;writer&amp;#x2F;published&amp;#x2F;nqy9o87cf7aa789ba49419eac167d0c34cfcb&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;writer.zohopublic.com&amp;#x2F;writer&amp;#x2F;published&amp;#x2F;nqy9o87cf7aa7...&lt;/a&gt;</text></item></parent_chain><comment><author>syrusakbary</author><text>I fully agree with your take. I think JS-directed computation is very good towards short-term adoption (since running JS on the Edge is probably the most popular use case), but eventually the needs to run other programming languages at the Edge will likely eclipse the JS use case.&lt;p&gt;At Wasmer [1] we have been working actively towards this future. Lately more companies have been also doing awesome work on these fronts: Lunatic, Suborbital, Cosmonic (WasmCloud) and Fermyon (Spin). However, each of us with a different take&amp;#x2F;vision on how to approach the future of Computation at the Edge. I&amp;#x27;m very excited about to see what each approach will bring into the table.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;wasmer.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;wasmer.io&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Netlify Edge Functions: A new serverless runtime powered by Deno</title><url>https://www.netlify.com/blog/announcing-serverless-compute-with-edge-functions</url></story><parent_chain><item><author>lewisjoe</author><text>This is great news. I&amp;#x27;m really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs.&lt;p&gt;While the general trend today is to back the serverless environment with Javascript runtimes (Cloudflare runs its edge on top of V8, Netlify uses deno, most other serverless runtimes use nodejs), I&amp;#x27;m optimistic that WebAssembly will take over this space eventually, for a bunch of reasons like:&lt;p&gt;1. Running a WASM engine on the cloud means, running user code with all security 
controls, but with a fraction of the overhead of a container or nodejs environment. Even the existing Javascript runtimes, comes with WebAssembly execution support out of the box! which means these companies can launch support for WASM with minimal infra changes.&lt;p&gt;2.It unlocks the possibility of running a wide range of languages. So there’s no lock-in with 
the language that the Serverless provider mandates.&lt;p&gt;3.Web pages that are as ancient as the early 90s are perfectly 
rendered even today in the most modern browsers because the group behind 
the web standards strive for backward compatibility. WebAssembly’s specifications are 
driven by those same folks - which means WASM is the ultimate format for any form of 
code to exist. Basically, it means a WASM binary is future proof by default.&lt;p&gt;I&amp;#x27;ve published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique, here - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;writer.zohopublic.com&amp;#x2F;writer&amp;#x2F;published&amp;#x2F;nqy9o87cf7aa789ba49419eac167d0c34cfcb&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;writer.zohopublic.com&amp;#x2F;writer&amp;#x2F;published&amp;#x2F;nqy9o87cf7aa7...&lt;/a&gt;</text></item></parent_chain><comment><author>electroly</author><text>&amp;gt; a fraction of the overhead of a container&lt;p&gt;I mean, only in theory or when looking at it from the right angle, right? Or are you only comparing against JavaScript (unclear)? WASM is still much slower than native code. Containers spend most of their time executing native code; the &amp;quot;overhead&amp;quot; of containers is at the boundaries and is minor compared to the slowdown by moving from native code to WASM. In the future WASM may approach native performance, but it&amp;#x27;s not there now. I&amp;#x27;m 100% certain that transitioning my native-code-in-containers workloads to WASM would be slower, not faster.</text></comment>