Just Use HTML, Man

At some point in the last decade, the web development community collectively decided that displaying text and images on a screen required the same infrastructure as launching a satellite. It did not.

There is a website called justfuckingusehtml.com. It exists, loads in milliseconds, and renders on a 2003 Nokia. A lot of what gets built on the web (forms, dashboards, user accounts, real-time data) is still fundamentally data moving from a server to a browser. HTML has been handling that since 1993.

React gets proposed because it's familiar, and that's fair enough. Six months later there's a 400MB node_modules folder, a webpack config nobody fully understands, and three state management libraries that were each a good idea at the time. A lot of overhead for what usually amounts to a few pages and a contact form.

Angular is a different problem entirely. It doesn't creep in; it arrives with a full architecture, opinions baked into every layer, a CLI that generates scaffolding for your scaffolding, and enough ceremony that rendering "Hello World" requires understanding dependency injection. Most projects don't need any of it.

Frameworks promise to manage complexity. What they actually do is relocate it into configuration, abstractions, and conventions that accumulate over time. A new developer joining the project can't change a button label without a guided tour first. The webpack config quietly becomes the most critical and least understood part of the system.

The component model solves a real problem. But a client-side rendering engine is not the only way to solve it. Real-time updates, live data feeds, complex interactive interfaces; these can all work with server-rendered HTML and a thin reactive layer driven by server-sent events. The server already has the data; the question is whether you actually need to move rendering to the browser to display it.

Content, forms, user accounts, workflows, live data; none of it inherently requires a client-side rendering engine. Render the HTML on the server and send it. Push updates over a persistent connection when something changes. A small reactive layer handles the rest. That's how this site works, including the parts with real-time data streaming at one-second intervals.

So here's what this site runs on: Go and templ. Type-safe, compiled templates. The server renders HTML. The browser receives HTML. The user sees the page. No hydration step. No virtual DOM reconciliation. No "suspense boundaries" or "server components" or whatever the new abstraction is called this quarter. No npm, no webpack, no broken builds because a package you've never heard of dropped support for your Node version. The whole thing compiles to a single binary, runs anywhere a Linux process runs, and templates are checked at compile time so a typo in a variable name is a build error, not a runtime surprise. Some developers read this and feel implicitly criticised. Fair enough; they've spent years getting good at tools that genuinely require expertise. The skills are real and transferable. This isn't an attack on that.

The practical upside is concrete: pages arrive ready to read with no waiting on JavaScript to hydrate them, search engines index the content immediately, and if a script fails the page still works. These aren't arguments for simple sites only; they hold for complex ones too. Moving rendering to the browser is a choice, not a requirement. Most of the time it's a choice that costs more than it gives back.