Modern frontends like Next.js, Svelte, Remix, Astro, etc. are hard to deploy. There are services like Netlify and Vercel that have built custom infrastructure just to do this. In this post we look at why frontends have become so hard to deploy and why even the giant cloud providers like AWS, GCP, or Azure have really poor support. We also look at how some recent changes have made it possible for SST to better support them. Back in the 2010s frontends were single-page apps. Hosting them was really easy. You just uploaded it to an S3 bucket and shared the URL with your users. To get fancy, you could add a CDN. Modern frontends now need a combination of infrastructure like S3 buckets, serverless functions, databases, CDNs, edge functions, edge data stores, and more. There are also a dozen or so competing frameworks. This is complicated enough that even AWS and GCP’s services like Amplify and Firebase have really poor support for them. They only support a couple of frameworks, don’t support their latest versions, and don’t cover all their features. As a result, most people use secondary cloud providers like Netlify or Vercel. These services have their own custom infrastructure built on top of the major cloud providers. They’ve used this approach to grow to impressive scales. Both of these companies are reportedly doing around 00M in ARR. But why do we need dedicated services? What’s so hard about deploying a frontend? How come even the giant cloud providers are unable to keep up? There are a few main reasons why frontends are hard to deploy and host: Complicated infrastructure, dozen different frameworks, and faster pace of updates. Self-hosting frontends is a perfect fit for an OSS project. When we had first started building SST, deploying frontends was a small part of what we did. But as we grew, we started to get more requests for better frontend support. We looked at the above problems; not having a one-size-fits-all solution and a long tail of frameworks and features. And realized that this was a perfect fit for an OSS project. So here’s what we did: Break down the problem, open source everything, and work closely with the framework authors. This is led us to start the OpenNext project. Now providers like Cloudflare, and even Netlify and Vercel, can contribute to the project and help keep it up to date.
