The Problem With Jamstack Frameworks

Published on Sep 8, 2020

Jamstack frameworks as we know them aren't great for fast-changing web applications: the build time is too long (NextJS, Gatsby), or we can't use web components easily (Hugo). 

Even with NextJS's incremental static regeneration feature, the pre-rendering logic is far from optimal: I do not want my app to run checks on each request.

In the end, you can't do Jamstack without a server-side generator ran by your hosting provider. Serverless removes the need to pay and manage a web server, but you still end up limited by the capability of the framework you use.

As soon as you need a smart logic for the way you build your static files, you're better off with your own server application. 

This is the case for Cowriters, for example: if a member publishes an article, I'd need to re-render his profile page, the main feed, and the relevant collection pages. If I have to rebuild the entire website every time, I will never be able to scale. Same if NextJS checks on my local folder every time it receives a request for one of the tens of thousands of webpages I manage. Having an atomic rebuild feature to handle these complex use cases becomes necessary, and it cannot be done without an unshackled server (aka a nodejs or php or python or rails script) to orchestrate everything.

The reason why frameworks like Gatsby or NextJS are always smarter once you use them together with their respective hosting platform (Gatsby Cloud or Vercel) is precisely because of the server-side logic that is custom-made for them. This is vendor lock-in at its finest: they give you a free dose, but you still have to pay extra to get the whole experience. This wouldn't be the case with a more traditional web framework.