Every few years the front-end world reshuffles its deck. A router gets rewritten, a rendering model is declared the future, and a migration guide appears with the cheerful tone of a dentist explaining a root canal. Meanwhile, the thing your users actually receive — the HTML — has barely changed since the late nineties. That asymmetry is worth sitting with. Your framework is a tool for producing markup. It is not the markup.
Pick any project older than five years and you will find at least one dependency that is now a museum piece. That's normal. Tooling churns because tooling competes. But the churn punishes teams who let framework idioms leak into the fundamental structure of their pages.
The teams that survive migrations gracefully have one thing in common: their HTML reads like HTML. A heading is an <h2>. A list is a list. A button that does something is a <button>, not a <div> wearing a click handler as a disguise. When the framework changes, that structure survives the move because it never depended on the framework in the first place.
Semantic elements are not there to please a linter. They are a contract with browsers, assistive technology, search crawlers, reader modes, and every future tool nobody has built yet. Write this:
<article>
<h2>Writing HTML That Outlives Your Framework</h2>
<p>Frameworks churn. Markup endures.</p>
<a href="/archive">Read the archive</a>
</article>and a decade of software you'll never meet already knows what to do with it. Write a pile of nested <div>s with class names encoding the meaning instead, and you've handed all that intelligence back and taken on the job yourself — forever.
If the answer to any of those is no, you've coupled your content to your tooling. That coupling is invisible right up until the day it becomes a rewrite.
The most durable pages treat JavaScript as an enhancement to a document that already works. Forms that POST. Links that navigate. Content that renders before hydration ever runs. This isn't nostalgia for a slower web — it's insurance. A page built this way degrades to something useful when a bundle fails to load, when a script errors, or when someone's on a train tunnel connection at the worst possible moment.
The framework is scaffolding. The building is the HTML. Don't confuse the two, and never let the scaffolding hold up the roof.
None of this means avoiding frameworks. They earn their keep managing state, composition, and interactivity that plain markup can't touch. The discipline is narrower and more boring: keep the output honest. Let the framework generate a document a browser from ten years ago and ten years from now could both understand.
Do that, and your next migration stops being a rewrite. It becomes what it always should have been — swapping the machine that prints the pages, while the pages themselves stay exactly where you left them.