The Static vs. Server-Side Choice Isn't Binary

There's a common assumption that choosing WordPress, or any classic server-side CMS, means you've opted out of the static site world. That isn't necessarily true. WordPress has a public API, which means you can pull content from it during a build process to generate static files—that's precisely the approach Gatsby takes. There are plugins that export a WordPress site to static HTML, and projects like Frontity further blur the lines between the two approaches.

Beyond the technical overlap, there are plenty of legitimate reasons to stick with a traditional CMS. You get a lot of capability out of the box: e-commerce solutions exist, form plugins are mature, authentication is a core feature, and the editing experience in Gutenberg is genuinely strong. For many projects, that feature-readiness beats the research phase that can come with piecing together a static setup, where even a small requirement might feel like uncharted territory.

And the same logic applies to other classic CMS platforms like Craft, which ships with a GraphQL API, or Drupal, which can be integrated with Jamstack architecture. These tools don't lock you out of static approaches; they just give you a different starting point.

That said, the static site world has plenty of merits. Decoupling the data layer from the front end is a sound architectural choice. Security is a major plus, and serving pre-built HTML from a CDN delivers excellent performance. The developer experience—git-based workflows, deploy previews, and the like—is another strong draw.

But going static doesn't mean giving up dynamic functionality. As Josh Comeau demonstrates with a project like Tinkersynth, you can build a React-based app that does substantial client-side work while still delivering a large portion of it statically. The trick is the "mindset shift": questioning whether a database call is truly necessary at runtime, or whether that data could have been fetched at build time and turned into a static file. And even when dynamic data is unavoidable, it's often possible to render most of a page statically and only pull the final pieces over via API.

The ideal future isn't choosing one camp over the other. It's a hybrid approach: render as much as possible statically, handle the rest through APIs, and use the best tools for each job without compromise.

When Static Makes Sense

  • You're starting a greenfield project.
  • The speed and security benefits of static HTML are compelling for your use case.
  • You have accessible APIs that can be consumed at build time, not just at runtime.
  • A particular static site generator fits your project well.
  • A cost analysis shows static hosting would be cheaper.
  • Features like build previews would materially improve your workflow.

When Server-Side Software Is the Right Call

  • You need the out-of-the-box features of a classic CMS, and migrating to static would incur too much technical debt.
  • You're already deeply invested in a server-rendered stack like Rails or Python with no existing pain points.
  • Your team's expertise is concentrated in server-side development.
  • A cost analysis shows server-side hosting would be cheaper.
  • There aren't solid static solutions for what you're building—forum software is a good example.
  • You have an extreme scale issue, such as millions of URLs, where static build times become prohibitive.

Weak Reasons to Avoid Static

  • "I need server-side functionality." You can still call APIs from servers, either during builds or at runtime.
  • "I need authentication." Jamstack handles auth just fine with JWTs and similar approaches.
  • You haven't actually explored what Jamstack-style development offers.

Weak Reasons to Choose Server-Side Software

  • You haven't looked into Jamstack approaches at all.
  • You assume that using established, well-supported tools prevents you from building anything statically.
  • SEO concerns. If anything, statically rendered content generally performs well—though moving to static could mean shifting some data fetching to client-side calls, which is a legitimate consideration, not a dealbreaker.