The Unreasonable Power of Plain HTML

It is incredibly easy to lose perspective when building for the modern web. From the comfort of a high-end development machine, connected to gigabit fiber, a 3MB JavaScript bundle feels negligible. We build complex, client-side-rendered single-page applications under the assumption that our users are navigating the web on multi-core CPUs, massive monitors, and flawless broadband connections.

But the real-world web is a chaotic, hostile environment. It is populated by spotty cellular connections, metered data plans, and incredibly low-end hardware. When critical digital infrastructure is built on the assumption of modern client-side horsepower, we lock out the very people who need those services most.

Revisiting a classic web development truth—famously highlighted by technologist Terence Eden—reminds us that simple, semantic HTML remains the most resilient, accessible, and high-performing technology stack at our disposal.

The PSP in the Welfare Office

To understand why lightweight markup matters, we have to look at the edge cases of web consumption. In a London housing benefits office, Eden observed a young woman seeking critical information about housing assistance. She had no laptop, no smartphone, and no high-speed home internet. Instead, she was connected to the office's public Wi-Fi using a hand-me-down PlayStation Portable (PSP).

By any modern standard, the PSP's built-in web browser is severely limited. It is slow, highly prone to running out of memory, and capped at opening just three tabs simultaneously. Yet, she was able to successfully navigate the GOV.UK pages to find the information she needed.

Why? Because the site was built using simple, lightweight HTML. It did not require the browser to download, parse, and execute megabytes of JavaScript before rendering a single word of text. It did not rely on complex CSS frameworks to position basic informational elements. It worked because the developers built for the lowest common denominator. As the user herself put it: "It's shit. But it worked."

The Hidden Long Tail of Web Clients

We often design websites for the latest versions of Chrome, Safari, and Firefox, treating anything else as an statistical anomaly not worth supporting. But the data tells a different story. Analytics from GOV.UK highlighted by Eden revealed thousands of users accessing public services through gaming consoles and legacy devices, including:

• Xbox: 2,062 users
• PlayStation 4: 1,457 users
• PlayStation Vita: 25 users
• Nintendo 3DS: 16 users
• Nintendo Wii U: 14 users

Beyond consoles, there is a massive fleet of non-traditional or legacy web clients quietly trying to parse our code. E-ink devices like the Kindle Paperwhite feature notoriously slow, experimental browsers that frequently hang on modern security challenges like Cloudflare or hCaptcha. In low-population-density regions of countries like Canada and Australia, slow and expensive satellite or cellular internet makes heavy page weights financially punitive.

Furthermore, legacy mobile platforms still exist in active production environments. Developers in the field report clients using Nokia Series 60 devices running J2ME to collect data. On these older devices, even basic security protocols present massive hurdles; expired root certificates on legacy systems can completely block access to modern HTTPS sites, prompting some developers to advocate for keeping HTTP active for purely informational, low-risk public resources.

Progressive Enhancement as a Survival Strategy

If your application must work when things go wrong, your architectural philosophy must shift from client-side reliance to progressive enhancement. This approach treats the HTML specification as the foundational contract with the user.

1. Start with Semantic HTML: Use the correct tags for the job (<main>, <article>, <button>, <form>). Semantic markup ensures that even if the stylesheet fails to load, the document structure remains readable and interactive.
2. Apply CSS for Layout and Usability: A small amount of clean CSS is all it takes to make a document highly readable. If the CSS fails, the content is still there.
3. Treat JavaScript as an Enhancement: If your form cannot submit without a JavaScript event handler, it is fragile. Ensure that basic CRUD operations can be performed using standard HTML <form> submissions to a backend server. Use JavaScript to make the experience smoother, not to make it possible.
4. Optimize for Metered Connections: Provide explicit alt text for all images. For users paying per megabyte, or those using proxy browsers like Opera Mini to compress data, images are often disabled by default. Clear alt text ensures the context of the page is preserved without downloading a single pixel.

The "Uncomfortable Chair" Test

As software engineers, we are insulated from the friction of our own creations. We test our applications on local networks with zero latency and infinite bandwidth.

To build truly resilient systems, we need to step out of this bubble. Eden suggests a simple diagnostic: go sit in an uncomfortable chair, in an uncomfortable location, and attempt to use your application on an uncomfortably small, outdated device over a throttled connection.

If your application fails to render, crashes the browser, or drains the battery trying to parse a massive framework bundle, you haven't built a modern web app—you've built a barrier. Plain HTML works. It has worked for decades, and it remains the single most effective tool for reaching every user, everywhere, on any device.