Back to Blog
Build April 2026 5 min read

Why We Chose Static HTML Over Next.js for the DBM Website

React is great. So is Next.js. But for a marketing site that needs to be fast, cheap to host, and dead simple to maintain — vanilla wins every time.


If you scroll through modern tech blogs, you will be led to believe that launching a simple web presence in 2026 requires an entire enterprise-grade framework. You're told that if you aren't using Next.js, Remix, or Nuxt, you are building in the stone age.

Don't get us wrong: at Dynamic Build Machine, we love React. We choose it regularly for highly dynamic applications like Port Stripes, where real-time state management, complex data structures, and offline synchronization are non-negotiable requirements.

But when it came time to build our own agency marketing site, we did something that feels almost radical in the modern dev ecosystem: we threw out the frameworks entirely and built it using vanilla Static HTML, CSS, and plain JavaScript. Here's why.

The Over-Engineering Trap

The modern frontend landscape suffers from severe tool creep. Next.js is fantastic engineering, but it was designed to solve the problems of complex, highly interactive web applications with personalized user states, authenticated dashboards, and massive, constantly updating databases.

A marketing site is fundamentally document-based. The content changes only when someone writes a new article or updates a portfolio project. When you use Next.js for a marketing site, you force the user's browser through a heavy multi-step dance: download a massive compiled JavaScript bundle, parse and execute the React runtime environment, then hydrate the static HTML page to make it interactive. For a site that consists mostly of headers, text, and structural layouts, this framework tax introduces unnecessary complexity and larger asset payloads.

1. Speed: Eliminating the Hydration Tax

A minimal Next.js deployment starts with a base layer of shipped JavaScript just to run the framework runtime. Our entire homepage payload is under 15 KB.

Because there is no React hydration step, the browser doesn't wait for JavaScript to compile before the page becomes interactive. The raw HTML is parsed instantly by the browser's native layout engine. Our Time to First Byte (TTFB) and First Contentful Paint (FCP) are locked at the absolute physical limits of the user's network connection. The site isn't just fast — it is instantaneously awake.

2. Cost: True Zero-Overhead Scale

When your site is purely vanilla static assets, your hosting infrastructure becomes incredibly commoditized. You don't need serverless Node.js instances or edge network compute runtimes to render pages. Your entire site is just a directory of flat files.

We can host these files on any object storage bucket backed by a global CDN. Because CDNs excel at caching and serving static files for near-zero cost, we could handle a sudden influx of millions of concurrent visitors without the hosting bill moving a single penny. No database connections to pool, no compute limits, no infrastructure scaling required.

3. Maintenance: Zero Dependency Rot

If you build a project in Next.js today, you are locking yourself into a continuous maintenance loop. Over the next two years, React will update, Next.js will deprecate older routing configurations, and underlying npm packages will throw security vulnerabilities during local builds. You become a custodian of your dependencies, constantly patching packages just to keep a static marketing site compiling correctly.

Vanilla HTML, native CSS, and standard browser JavaScript do not rot. The browser specifications are fanatically backwards-compatible. The code we wrote this week will render perfectly in Chrome, Safari, and Firefox a decade from now without ever running npm audit fix or wrestling with a broken Webpack configuration.

How We Handle Content Without a Framework

The main argument for frameworks on marketing sites is content management — using components to loop through data and generate blog listings automatically. We solved this cleanly without a runtime framework footprint.

Our articles are written in plain Markdown. When we run our local deploy command, a 30-line Node.js build script parses the markdown, passes it through a lightweight layout template, and outputs a pure, flat HTML file. The generation happens entirely on our local machines during development — the end user never pays a computational tax for our writing workflow.

Choose the Right Tool for the Domain

Our job as software builders isn't to use the trendiest tools — it's to solve operational problems with the cleanest, most efficient architecture possible.

If you are building a dashboard with heavy client-side state, user authentication, and interactive data visualization, reach for React and Next.js immediately. They are excellent choices for that territory. But if you are building a marketing site, a portfolio, or a text-based publication, stop over-complicating your dependency tree. Trust the native platform. Plain HTML and CSS aren't legacy technologies — they are the fastest, cheapest, and most robust foundations available on the web.