Why I still write HTML
14 April 2026/1 min read
I build with modern tooling. Component frameworks, build steps, the whole apparatus. And every project ends by producing plain HTML files, deliberately, because the HTML is the part that will still work.
Consider what has happened underneath the web in the time I have been doing this. jQuery was mandatory, then it was legacy. Flash was the future, then it was removed from every browser on earth. Build tools have turned over completely, several times. Frameworks that were the obvious right answer are now migration projects.
Meanwhile a page of HTML written in 1998 still renders. Not approximately.
Correctly. The <p> tag has never broken compatibility. Neither has <a>. The
platform is aggressively, almost stubbornly backward compatible, and that is
the single most valuable property it has.
So the question I ask about any layer I add is: what happens to this client's site when the layer stops being maintained?
If the answer is "the site stops working," that is a liability with a delayed fuse. The client will not experience it as a technology decision. They will experience it as their website breaking one day for no reason, four years after I stopped working on it, with nobody to call.
If the answer is "the site keeps working, we just cannot rebuild it as easily," that is fine. That is a maintenance inconvenience, not an outage.
That is the whole rule. Use whatever tooling makes the build good. Make sure what you hand over is HTML that does not need any of it.
It also happens to solve problems people are paying consultants to solve right now. Pages that render without JavaScript are pages crawlers read, which is increasingly what determines whether you exist. The correct answer for durability and the correct answer for being found turn out to be the same answer, which does not happen often enough to ignore when it does.