2026-04-20 · 10 min read

Single-File HTML Templates vs React/Vue: When to Pick Which

The question gets asked in the wrong order. It usually starts as "what framework should I use for my marketing site?" — but the framework decision is downstream of the actual question, which is: how much of this site is static content versus interactive application?

Once that ratio is clear, the right answer falls out. This post is the honest version, with typical ranges.

The shape of each choice

A single-file HTML template — what we ship at Morton Digital — is index.html plus optional sibling HTML files for subpages. Tailwind CSS is loaded via CDN. There's no node_modules/, no build step, no bundler. You edit the file, you refresh the browser. Deploys are rsync.

A React/Next.js site is a full application: components, routes, state, a bundler (Webpack/Vite/Turbopack), a dev server, potentially server components and edge runtime. You write JSX, the toolchain emits optimized JS + HTML. Deploys are git pushes that trigger a build.

Neither is better in the abstract. They optimize for different things.

Typical Lighthouse numbers

Using the same 5-section SaaS landing page content, the two approaches land in consistently different ranges. Measure on DevTools Lighthouse (Moto G Power emulation, 4G throttling, cold cache) and you'll see shapes like this:

The Next.js version renders on server, hydrates on client, and still pays a non-trivial runtime cost on mobile. The gap closes somewhat with aggressive code-splitting and use client pruning — but getting Next.js to 99/100 mobile requires weeks of perf tuning; plain HTML ships there by default.

When to pick single-file HTML

Pick this when the site is:

• Read-mostly. Landing pages, portfolios, docs sites, blog homepages, link-in-bio pages, product demo pages.
• Stable over time. Content changes weekly at most. Every edit is a human writing copy, not a build system regenerating.
• Independent from an app. The marketing site lives separately from the product surface. Users don't flow from landing → logged-in experience without a page reload.
• SEO-critical. Google indexes what it sees in the initial HTML. A plain index.html with structured content is maximally crawlable. SPAs require careful SSR or pre-rendering to match.

Concrete examples where single-file HTML wins:

• The SaaS marketing site that lives at yourdomain.com while the product is at app.yourdomain.com. (Orbit, Horizon.)
• A developer portfolio. (Forge.)
• A book/course sales page with checkout handled by an external service.
• A pre-launch waitlist page with an email form posting to a third-party endpoint.

When to pick React/Next/Vue

Pick a framework when the site is:

• Dynamic per user. Each visitor sees different content pulled from a database, or there's a logged-in state that drives navigation.
• Deeply interactive. Multi-step wizards, real-time data, live editors, visualizations that respond to user input.
• Continuously re-published. Content authored in a CMS, regenerated on deploy. A marketing team edits Contentful, the build rebuilds the site.
• Sharing an application shell with the product. One design system, one auth flow, one deploy pipeline — consolidation pays for the tooling weight.

Concrete examples where a framework wins:

• A SaaS dashboard with filters, tables, charts, settings — anywhere state lives on the client.
• A multi-tenant app where /{customer}/dashboard must render differently per tenant.
• A docs site with 200+ pages authored in MDX and heavily cross-linked.
• An e-commerce frontend with cart, session, product variants — the reactive model earns its cost.

The common mistake

The mistake isn't picking the wrong tool for a single surface — it's picking one tool for all surfaces when the surfaces have different shapes. The teams who ship best tend to have:

• Marketing site: static HTML or Astro, deployed to a CDN.
• Product app: React/Vue/Svelte, hosted on whatever supports their auth/data story.
• Docs: static generator (Docusaurus, Starlight, Astro).

They accept the "three deploy pipelines" cost because it's smaller than the "ship the whole thing in Next.js and wrestle with hybrid rendering" cost.

What about build-step-free + a sprinkle of interactivity?

This is the sweet spot for a lot of sites. Single-file HTML can handle interactivity — it just does it differently:

• FAQ accordions: <details> / <summary>. Zero JS. Keyboard-accessible by default.
• Mobile nav toggles: 8 lines of vanilla JS, or CSS-only with the checkbox hack.
• Form validation: browser-native :invalid selectors plus pattern= attributes.
• Image carousels: CSS scroll-snap. No library.
• Smooth scrolling to sections: html { scroll-behavior: smooth }.
• Dark mode toggle: ~15 lines of JS reading/writing a data-theme attribute.

Every Morton Digital template uses these patterns rather than reaching for libraries. The interactivity is real and works in every browser from the last 5 years — it just doesn't need 150KB of React to enable it.

Bottom line

If you're building the landing page, portfolio, or brochure that lives in front of your product, start with single-file HTML. You'll ship this afternoon instead of next week, load faster for every visitor, and have less to maintain forever.

If you're building the actual product surface — the part logged-in users interact with — reach for a framework.

Don't use the same tool for both unless a specific team consolidation argument justifies it.

Browse the single-file template catalog if the first half of this post described your project.