Engineering
Why we still hand-write HTML in 2026
Not nostalgia. A concrete comparison of shipped bytes, build complexity and what happens when the framework has a major version.
- Engineering
- 7 min read
Every AWGCOR marketing page you are reading right now, including this one, is hand-written HTML and CSS with no framework underneath it. That sounds like a strange flex in a year when the default answer to "how do I build a website" is a JavaScript framework with a build step. It is not nostalgia. It is a decision we made by comparing the actual costs, and we would make the same call again.
What actually ships to the visitor
A framework-built marketing site typically ships a JavaScript bundle before the visitor sees a rendered page — often several hundred kilobytes, sometimes over a megabyte once you count the framework runtime, the router, the component library and the app code, before a single word of your actual content has rendered. This page ships HTML and CSS the browser can paint immediately, and a small amount of vanilla JavaScript for interactions that need it. There is no framework tax on a page that does not need an application running inside it — and a marketing site, a blog, a pricing page, almost never does.
The build complexity nobody prices in
A framework brings a build step, a package manager, a dependency tree with hundreds of transitive packages you did not choose and cannot audit individually, and a CI pipeline to keep it all working. Every one of those is a thing that can break, and every one of those is a skill your team — or your agency — needs to maintain indefinitely. A static HTML file has none of that surface area. You can open it in a text editor, change a sentence, and it is live. No build, no deploy pipeline, no "why did the build fail on a Tuesday for no reason."
What happens when the framework has a major version
This is the cost that only shows up later, and it is the one we actually built this decision around. Frameworks move. A major version lands, a plugin you depend on has not been updated, and now a site that worked perfectly well is stuck on an old version because upgrading means rewriting parts of it — or it is upgraded and something quietly breaks that nobody notices until a client mentions the contact form has stopped working. We have inherited sites in exactly this state, where the honest fix was a rebuild because patching forward cost more than starting over. Hand-written HTML has no version to fall behind on. The site you launch is, mechanically, the site that still runs in five years.
Where a framework earns its cost
This is not an argument against frameworks everywhere — it is an argument for using one where it actually pays for itself. The AWGCOR client dashboard, which is a real application with state, logins and live data, is a different kind of software and gets a different kind of build. The distinction we make on every project is simple: is this a page, or is this an application? Pages get hand-written HTML. Applications get the tooling applications actually need.
Ready when you are.
Tell us what you're building and we'll map the shortest route there.
Keep reading