Is Your Web Site an App?: Why Static HTML Still Wins for Websites

The modern web began as pure Hyper Text Markup Language (HTML), designed with a simple yet profound purpose: to create a web of linked documents, a tapestry of ideas reminiscent of Asimov’s Encyclopedia Galactica. It was a system for presenting information. Only much later did the practice of generating these documents on the fly emerge, where server-side logic would assemble content before sending it to the browser. While the content became dynamic, the format remained the same simple document. Even worse, with the emergence of machine-based page consumers (LLM-based agents) even client side dynamic content display becomes problematic because AI agents currently only deal with semantic content and not with the code or required interactions. The fundamental distinction between a web page and an app is being lost. We’ve begun to conflate simple content display with complex application logic, and in doing so, we’ve created unnecessary and insecure servers.

The Great Divide: Site vs. App

This confusion stems from blurring the line between a “site” and an “app.” Let’s draw that line clearly.

A Web Site is a collection of documents and resources, primarily designed to present information. Think of a blog, a news site, a company’s marketing page, or a restaurant’s menu. The core purpose is information delivery. The user’s interaction is simple: they read, navigate and understand.

A Web Application, on the other hand, is a program that runs in the browser. It’s characterized by complex, persistent state and rich user interaction. This is where the document’s content must be managed by a server because the application has an internal state that is not accessible to the client. Think of a project management tool like Asana, an online spreadsheet, or a social media feed. The user isn’t just consuming content; they are creating, manipulating, and interacting with data that changes and persists. In a single page application (SPA) the remote server is replaced with a local server, but it still requires a server.

The key differentiator is state. A website is largely stateless. Every user gets to the content in the same way. An application is stateful. Each user shapes their interaction based on their actions.

It is important to note that it is a spectrum between the two. A website that requires a login has some state. A browser app that converts text to base64 using javascript does not need server side state. Knowing that this is a spectrum and making appropriate choices is the thing that matters.

The Allure of the Over-Engineered

So why are we building simple, stateless websites with stateful application frameworks? The reasons are varied:

• Misunderstanding the Problem: If we are only used to building SPAs or default to using React for “everything web” then we may be missing opportunities or making assumptions about the requirements.
• The “Just in Case” Fallacy: Building for imagined future complexity often leads to paying the price for features you are never going to use. The difference between delivering a simple system now and delivering unused features slightly later, is costly.
• My Users Need It: User Experience (UX) based design would validate this assumption early on with real users. Instead of tying your content creators to a specific editor on a live server, a decoupled workflow sets them free to use the best tools for their job.

The Power of a Decoupled Workflow

The real advantage of the static-first approach is decoupling how you create content from where it’s hosted. Instead of forcing everyone into a single, built-in web editor, you empower your team to use the best tool for their job. The website is just a final destination, not the workshop.

Consider this hypothetical workflow:

1. Shared Content Location: All content and images live in a simple, shared location like Dropbox, Google Drive, or a Git repository.

2. The Team Chooses Their Preferred Editor: Team members can use Google Docs, Obsidian, a Headless CMS, or any other preferred tool.

3. Saving a File Triggers the Preview: An automated process watches the shared location and generates a 100% accurate preview of the site whenever a file is saved.

4. Publishing is Automated: Once approved, the content is published by moving it to a ‘published’ folder, which automatically triggers the live deployment.

This type of workflow is not only flexible but also resilient; content creation can continue offline, relying only on local tools. When you compare this elegant simplicity to the alternative: an approach involving Server-Side Rendering (SSR) or a client-side framework; the contrast is clear. That approach brings massive overhead, with a server rendering pages that could have been pre-built, a client downloading large JavaScript bundles, and a mountain of complexity to manage it all.

Misconceptions

But what about all the things you would give up if you would use a static site?

• Interface Interactivity: This is generally done through client-side JavaScript that manipulates the DOM and CSS. A static site still does all these things but with clearer control and intent in what is often called “islands of interactivity”.
• Any State makes it an App: Think about your state. Really think about it. If it reduces down to a cookie or a token, it might not be an app. Only if you have to store something on the server does it start to smell like an app.
• Losing Behavior Tracking: Google tracking works on static web pages by embedding a bit of JavaScript. But don’t forget the web server logs. There is a wealth of information there around navigation between your static pages.
• Static deployment is slow: If page content does not change every 5 minutes, having a 5 minute deployment process is fine, as long as you have local testing that is instant. And with a static site, you generally do have instant local testing. All the tricks form software development, like incremental builds become available. On very large sites, spending your engineering time on the build and deployment process is worth it, rather than spending engineering time on maintaining sever code for small sites.
• I have to edit on the server: This often comes up because of a fear that the deployed page may look different from the one the content creator made. With a static site the local testing view is exactly what is deployed reducing the chance of strange issues.

The Unbeatable Case for Static

For the vast majority of websites, a static site is the superior choice. This is where the content is pre-built into simple HTML, CSS, and minimal JavaScript files. These files are then served directly from a Content Delivery Network (CDN).

This is the approach used by modern static site generators like Astro, Hugo or Elevnety. Astro is the very tool this blog is built with. The benefits are undeniable:

• Blazing Speed: Static files are incredibly fast to serve. There’s no database to query, no server-side rendering to perform. The page is already built. Your website performance metrics now largely depends on the CDN. In some tests an Astro static site outperforms Next.js by 15 points on the Lighthouse score.
• Ironclad Security: With no live server or database to attack, the surface area for security vulnerabilities is dramatically reduced. A quick look at the typical web server logs often reveals a constant stream of probes for vulnerabilities (like common PHP files or /admin paths), an entire class of threat that is irrelevant to a static site.
• Simplicity and Low Cost: Hosting static files is cheap, often free. The AWS free tier for CloudFront is likely to cover most use cases with its free 1TB of data transfer and 10M requests per month. Compare that to having a hosted web server at $20 per month serving the same site. The development process is simpler, focusing on content and presentation rather than complex state management.
• Scalability: A CDN can handle massive traffic spikes with ease, something that would crush a traditional server-based setup.
• AI & Search Engine Friendly: Static HTML is simple, semantic, and easily parsed. This makes it ideal for search engine crawlers and emerging AI agents that consume content directly, ensuring maximum visibility and accessibility.
• Tooling: The content creation tools are decoupled from how you host the content, giving you more options. The deployment process is also automatable using the tools developers are already familiar with. Even better, this process can be made transparent to your content creators.

With modern tools, “static” doesn’t mean “boring.” We can still have rich, interactive elements where needed, without paying the price of a full application framework for the entire site.

Look at the users of the Astro static build tool. These are heavy hitters.

When Do You Actually Need an App?

You need an app when your primary purpose is interaction, not information. Ask yourself:

• Does the user need to log in to a personalized account with unique functionality based on identity?
• Is there significant state manipulation or processing that does not happen on the client?

If the answer is yes, then a web application is likely the right tool for the job. But if you are building a blog, a portfolio, a documentation site, or a marketing page, you are building a website. Embrace the power and elegance of static. The goal is not to abandon powerful app frameworks; they are essential for building some of the most important apps we use. The goal is rather be deliberate about the choice. By defaulting to app level complexity for content-focussed websites, we create unnecessary cost in performance, security, maintenance and machine readability.

The next time you start a project, ask this: Am I delivering information, or am I building a tool? For the former, the answer is clear. Reclaim simplicity, speed and security of the static web. The AI agents will thank you too.