Sites vs. Apps

Choosing the right mental model: content-dominant sites vs. interaction-dominant applications

The Spectrum

Not everything on the web is the same kind of thing. A blog, a documentation site, and a corporate homepage are fundamentally different from Gmail, Google Docs, or a stock trading dashboard. The distinction between sites and apps — and the vast spectrum between them — is one of the most important framing decisions in web development, because it determines which architectural approach is appropriate.

Sites                                                        Apps
◀━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶
Content-dominant              Mixed              Interaction-dominant
Blog, docs, news        E-commerce, social      Gmail, Figma, trading
HTML-first                Hybrid approach           JS-first
Read-mostly                Read/write              Task-oriented
  • If something is mostly non-interactive content, it's probably a site. Don't use heavy programming to manage it unless at scale — you're likely overcomplicating it and may introduce adverse side-effects (performance, SEO, accessibility).
  • If something is task or interaction-based, it's likely an app. Bending traditional web tech for app-like behavior can be problematic, though it's tried and true.
  • The degree of site-ness and app-ness is not absolute. Apps can have site-like features. Sites can have interactive elements. Even video games often embed web tech (HTML, CSS) for UI elements.

Why This Matters for Architecture

Characteristic Site-like App-like
Primary content Documents, articles, media Interactive features, real-time data
Navigation model Page-to-page (1 URL = 1 page) State-based (views within a shell)
JavaScript role Enhancement (optional) Essential (app won't work without it)
Rendering approach Server-side / static Client-side / hybrid
SEO importance High Often low (behind auth)
Caching strategy Aggressive (content rarely changes) Complex (real-time data)

Static vs. Dynamic — A Common Trap

A "dynamic" site is one where the server composes responses on the fly, usually by binding data into templates (the MVC pattern). This appeals to developers, but is it always the right idea?

A "static" dynamic site — a database-driven site that delivers the same content to every visitor — is needless complexity with poor performance. The solution: caching, static site generation (SSG), or publishing patterns.

The JAMstack movement and static site generators (11ty, Hugo, Astro) are a recognition that many "dynamic" sites were never truly dynamic. Site approaches need to fit their purpose.