Telerik blogs

While the Edge runtime has limited functionality, it’s a powerful solution in the right circumstances. Here’s when it can serve your JavaScript app well.

The Edge runtime is a fast alternative to Node.js for deploying your JavaScript application. Because it is so limited in functionality, you must know how to navigate it to get the features you want.

TL;DR

While Vercel Edge runtime may be dying in depreciation, Cloudflare, Deno and Bun will exist for a long time. If you connect to your database with HTTP, and you don’t need image processing, you shouldn’t have many problems deploying anywhere. Try and write your app so that you can connect to any server, in any environment, so you can prepare for any situation.

Server JavaScript Environments

Let’s look at a brief history of server-side JavaScript to understand where we are today.

V8

In 2008, Google released the V8 engine, making JavaScript load faster for browsers, specifically for the creation of Google Chrome using the open-source Chromium browser project.

Node.js

Node.js was released in 2009. It allowed developers to run JavaScript directly on the server, replacing the need for PHP, Python, C# or Java for backend server needs. Other languages like Perl, ColdFusion and Ruby were still active, but not as popular.

Overnight, frontend developers became full-tack developers. It was the only JavaScript server option for nearly 10 years.

Node.js is built on the V8 engine with I/O, networking and file system capabilities—things which are not allowed in the browser. These additions were written in C++.

Serverless

Amazon released serverless computing for the first time in 2014. AWS Lambdas allowed developers to run JavaScript on the server without provisioning or managing servers manually. Each function starts up, runs and gets destroyed. There are cold start times, but they can be minimal.

By 2017, ZEIT (now Vercel) introduced Now v1, which was a wrapper around AWS Lambas to allow easy deployment of the functions. After being rebranded to Vercel in 2020, the serverless functions have descended into something more powerful. The infrastructure built on top of the lambdas today are extremely powerful.

Recently added in 2025, the Fluid Compute engine gets rid of these cold start problems, adding incredible speed and facility.

Edge Runtimes

Edge runtimes allow isolated instances of JavaScript that can scale infinitely.

Cloudflare

Cloudflare Workers were introduced in 2017, using V8 Isolates. This means they created a sandboxed version of V8 for the server, and only added Web Platform APIs. There is no file system, TCP, nor child processes. You can use HTTP, just like the browser, for fetching data.

They are extremely fast, extremely limited and not meant for long processes or large applications. Today, there are some node compatibility options for certain common APIs.

Vercel Edge

Vercel copied the model of V8 Isolates in 2022. Some people have suspected it uses Cloudflare under the hood, but there is no public record of this. Either way, the limitations are the same.

Vercel has depreciated Edge Functions, however, Edge runtime can still be run inside the Serverless Functions. DO NOT confuse Edge Function depreciation with Edge runtime.

Vercel Bun

Vercel recently released a public beta of Vercel Functions using Bun. I suspect the goal is for Bun to replace the Edge runtime, as they actively recommend against using Vercel Edge, but have not depreciated the Edge runtime itself.

Bun is built on top of the JSC Engine (JavaScriptCore), which Safari browser uses, and uses Zig for the Bun Runtime. JSC is probably faster than V8 Isolates for Edge runtimes, but slower for large applications with intensive compute activities. Either way, the differences will be minimal and depend largely on configurations.

I believe Vercel is the only platform that hosts Bun for you at this time without configuration. You can self-host it anywhere.

Deno

Deno is widely used on platforms like Netlify Edge and Supabase Edge Functions.

Deno uses V8 Isolates with many more Node.js feature capabilities. It is written in Rust. However, I personally have struggled getting any Node.js-compatible APIs to work without hiccups. Deno does offer the most compatibility with Node.js, it just requires torturing yourself to get them to work correctly. I suspect this will get better over time.

Node.js vs. Edge Runtimes

Theo recently released benchmark tests basically showing Vercel Serverless is faster than Edge runtimes. Since Vercel is probably switching the Edge runtime for Bun (my guess) and doubled down on Serverless, they didn’t care so much. Since then, Cloudflare has updated some performance bottlenecks, and may have increased their speed.

The Real Winner

In reality, they are not arguing about which runtime is better; they are arguing about which service is better. Edge runtimes will probably always be faster for smaller applications, while Node.js will probably always be faster for application intensive applications.

Cloudflare vs. Vercel is a different story. I love seeing the companies solve some of the hosting issues, but I suspect benchmarks will go back and forth as things evolve. I hope the Bun Runtime gets real adoption, as I believe it has the best potential.

Remember to always put your functions as close to the database as possible.

📝 It is still unclear if Cloudflare is faster than Vercel, as it really depends, but it is definitely cheaper.

Being Safe

I suggest you write your software with as little compatibility issues as possible. You do not want vendor lock-in, and having the ability to deploy your app anywhere gives you the best peace of mind.

Framework

It should also be noted that you can save more time using smaller JavaScript frameworks like Nuxt or SvelteKit, compared to Next.js, in any benchmark. If timing is the most important thing, the framework you choose matters the most.

Compatible JavaScript

Most standard JavaScript will work in Edge runtimes. However, certain features will not work out of the box, while others can’t work. There are always trade-offs, but there are usually work-arounds.

Image Processing

Manipulating an image requires a file system. Pure JavaScript is too slow for heavy pixel math, and those native bits can’t load in the Edge runtime. Fast image work normally relies on native libraries/codecs (libvips via sharp, mozjpeg, libwebp, etc.). The only alternative is Wasm.

WebAssembly

Edge runtime allows you to load Wasm files since you can’t use Node.js APIs. However, and a BIG however, currently loading Wasm with a Framework in Cloudflare or Vercel Edge does NOT work out of the box, and may not work at all. You can load Wasm in the browser, but it is very difficult on the server. Bundlers have a very hard time with Wasm files, particularly on the Edge.

Work-arounds

🚧 The best work-around is to create a separate function that is outside of your framework. This is NOT easy, but doable.

If you’re using Vercel, the easiest route is to just create a separate Serverless Function using Node. Netlify functions may work as expected on Deno, but you’re locked in to a Deno deployment.

📝 Cloudflare also wants you to pay for image resizing options. No thanks.

Vercel Open Graph Image

Vercel created a useful utility that allows you to generate Open Graph Images from HTML code on the fly. It first converts the image to SVG, then converts the SVG to a PNG. The @vercel/og is not open-source and is mainly imported with @next/og, but you can’t hide JS source code with NPM.

Satori

Satori converts HTML, including Tailwind, to an SVG image. It is beautiful and can run anywhere, but it doesn’t have all CSS features you would want. While it was written for JSX and React, you can use satori-html to convert any HTML string to a JSX object. This is useful for non-JSX environments.

Resvg

Converting the SVG to a PNG is the problem for Edge environments. resvg-wasm will handle this, it just currently can’t be bundled correctly when using a framework and edge deployment from any current examples I have ever seen, except the built-in NextJS library.

Sharp

Resvg only handles conversion to png, but you may need jpg conversion as well. Sharp does have a Wasm version, but I have never seen it used in action. I imagine you will get the same importing problems unless you don’t use a Framework to bundle it correctly.

Yoga

You may also need Facebook’s Yoga layout engine for calculating flexbox layouts. There is yoga-wasm for this as well.

Usage

The best way to use the og/image package, is to use it the way it was meant to be used, with Next.js or with Vercel Functions (not Edge). You will shoot yourself in the foot trying to configure it otherwise. I suggest creating a reusable function that can be called separately from any framework. This way you can have your cake and eat it to, with a workaround.

Database Connections

The main protocol people use to connect to database is TCP/IP. While managing connections is painful, you get a direct connection to your database. Edge runtimes do NOT support TCP/IP connections on their own.

Cloudflare

Cloudflare allows you to connect to TCP/IP through third-party options:

New in 2024

Connecting to a Database on Cloudflare shouldn’t be a problem with recent Node compatibility mode.

HTTP

You can always connect to your database if your database offers HTTP connections.

Vercel Edge

Currently, there are no Node compatibility options without using HTTP or a custom proxy. Recommended database is Neon.

Netlify Edge

Deno supports npm packages now as well as a Deno TCP connector out of the box. There is a configuration hassle in Deno, but it can work.

In Short

Vercel Edge is not compatible with much, but it allows you to use Vercel Functions beside it. Cloudflare may can connect to your database, but will be painful to work with images. Netlify uses Deno with the most compatibility, but deploying them and getting them to work is difficult. It is too early to tell for Bun.

Compatibility is the Edge’s nightmare.

If you leave image processing to Serverless Functions, and connect to your database through HTTP, life is good.

There are always trade-offs.


About the Author

Jonathan Gamble

Jonathan Gamble has been an avid web programmer for more than 20 years. He has been building web applications as a hobby since he was 16 years old, and he received a post-bachelor’s in Computer Science from Oregon State. His real passions are language learning and playing rock piano, but he never gets away from coding. Read more from him at https://code.build/.

 

 

Related Posts

Comments

Comments are disabled in preview mode.