alt Hacker NewsBuilding an HTML-first site doubled our users overnight
Comments
I haven't heard much about in a while, but the HTML Triptych proposal [0] is still something I hope to eventually land in browsers. HTML forms speaking to REST endpoints are a good pattern. (meaning user-aiding validation is handled via the input attributes, real validation is handled on the far side of the request, and the flow is GET /form => POST /thing => GET /thing/1) It would be a great pattern with the triptych features implemented!
Most of my apps are now simply HTMX + Go + SQLite.
I've found it's enough for most projects.
One of my sites is image heavy and serves 10 TB of traffic per month. For this, I use the following setup:
1. S3 (I wanted reliable data storage) 2. In front of it, I have Cloudflare (with Tiered Cache enabled, which makes POPs prefer pulling from Cloudflare rather than the origin). I've set rules to cache everything on both the browser and Cloudflare for 1 year, ignore origin cache policies, ignore query strings, etc., and I simply use immutable objects that require revisioning. 3. BunnyCDN in front
Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.
And if you run only S3, the bills will be huge.
But yes, lately I’ve been building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage in the app without sign up or involving a backend.
What can I do? So I was forced to switch to Flutter on Android, but I ran into another pain point: app updates sometimes spend a lot of time "under review," which is frustrating. For the same app, I maintain a web app that is very quick to update by comparison.
I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
I like how quickly you can update PWA app.
The counterargument: In Defence of the Single Page Application:
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
This post is good, and it's a great example of taking a problem and solving it with the appropriate tech with the right amount of depth. It really helps to have full domain knowledge of your customers as well.
However, I do not like how it is framed as "simple html is better than react" - because you could just as well have told the same story as a react developer.
(Nb. I could go on forever about the complexities and intricacies of storing things session based on a server vs browser based and etc - and lots of other things that were skimmed over in this article, but that would be too long)
All of those things that are simple in html are also simple in react.
It's literally the same code - there's nothing preventing you from using browser based html validation in react - all the same code that gets complicated in react (overly complicated validation logic) also ends up being complicated in astro - they have their own thing around schema validation etc and integrating it within an astro site means you have to integrate their client router etc etc.. so it's very easy to go overly-complicated there as well.
The comparison is also with an off-shore team doing development for you with probably incomplete knowledge and the way projects are structured they have an incentive to create the solution as fast as possible, in as little time as possible, with the biggest amount of complexity as possible.
The last point is devious - it's not necessarily that the contractor does this by design, but the incentive structure makes it so something that's overly complicated actually benefits them, so they don't have a direct incentive to go with something simple.
Anyways, a simple solution, directly addressing the problem at hand is always better - no matter what stack you pick.
(I'd like to say that I don't have anything against Astro's form validation, I was just trying to highlight how there's more to it than "native html browser validation")
This isn't "We replaced a React app with an HTML form and performance improved." It's "We replaced a bad web page with a good web page and performance improved."
Attributing this to the technology driving the browser experience is silly. You can make a brilliant user experience with React. You can make a terrible website with plain HTML.
The improvement comes from the change design, not tech.
Excellent article but I am always torn when I read inspirational articles like this - it makes perfect sense to me and I love the idea of simple, non-nonsense sites that work well, load quickly and don't rely on the latest browsers to function.
Then I start to wonder if that's just because I'm not smart enough to understand React or whatever the fancy technology of the day is.
Feels like I have a hard understanding threshold that cannot be breached - give me a simple editor like Sublime and ask me to make a web page - even with JavaScript - and it's my happy place. Give me VSCode or Zed, Claude/Copilot/ChatGPT plugins everywhere, React tutorials and my brain goes to mush.
I'm not convinced from the article that HTML-first was the thing that fixed the problem. What fixed the problem was 1) the person building it knew what they were doing and 2) it had design constraints from the get-go to be user-friendly. You can do that with React. It's arguable whether it's easier or better, but you can get there regardless of the approach you use.
HTML first, minimal JS, not using any frameworks unless absolutely justified is already part of my prompts to LLMs when I build stuff for myself. I’m not a frontend developer, and have not kept up to date with the ton of frameworks. That HTMl first approach already makes the LLM outputs faster/fresher for me. I wish more people went this route for public facing services.
I was going to comment on the Terence Eden excerpt quoted by the author about the woman researching housing benefits on an old PSP browser, when I noticed that you (the OP) are Terence himself. It's strikingly powerful, and a reminder of the duty we have in building our infrastructure.
> Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures.
It is frightening to think of how many people are alienated from critical systems every day because of this bias reinforcing the idea that they do not exist.
I built apps like these on GOV.UK over 10 years ago for the Ministry of Justice. We built our own form wizard library that let us validate long forms in steps and break them out into multiple pages because Ruby on Rails didn't support doing that out of the box. It was a very important principle back then that everyone should be able to make use of these digital services regardless of whatever users were using to access them.
I remember when YouTube implemented a new html player and suddenly, unexpectedly, they had all the is traffic coming from rural Africa. Size matters.
I'm curious how many web issues can be solved by having the people responsible for the relevant sites only be allowed to use them on a Windows 11 machine with only 4 GB of RAM using Firefox with the network throttled to 3G speeds.
Assuming the processor isn't horrible, I can still browse plenty of sites with those specs without much issue, and on the sites that do require more, it's very rarely because the sites actually needs it (i.e. I'm not running Windows XP in a VM in the browser or something). It could just be normal HTML and CSS and normal forms, sprinkled with some light JS to help out a bit. But the amount of sites made with that level of care and attention are sadly rare, since the people responsible rarely feel the pain or have the empathy to fix the problem.
Don't tell me were going to rediscover progressive enhancement all over again after more than a decade. Back when we used to actually care about the end user whether you were programming frontend or backend.
Too much VC money and big tech influence in the JS ecosystem made the web worse in some ways.
There is one hard wall that stops very old clients from connecting: Not supporting a new enough version of TLS. TLS 1.2 is from 2008, and TLS 1.3 is from 2018. Web browsers older than 2008 can't connect to modern websites since TLS 1.0 and 1.1 were deprecated from web servers in 2021.
Sadly, this is the story of nearly every React project I've reluctantly inherited. In my experience, it's because React is not opinionated like its peers Vue and Svelte. So, a bunch of devs will use something for state management and and another team will use something else completely. Eventually both teams leave after making a mess. But, if you look at the graphs and numbers that MBAs chase, they will all look like everyone was productive until the very last minute. The ultimate casualty is unfortunately the user. Even Facebook hasn't figured out React across their properties. Just use Instagram / Facebook on the web. Bunch of spinners to load a static list of items in a drop down menu. Not even joking, click on the bhamburger menu on Instagram web. It makes a dozen requests, shows you a loading skeleton and takes 5 seconds before you can see a finite list of menu items. Ironically Facebook was super popular in the 2014s because they didnt have much React based BS going on. Everything was just good old hyperlinks.
If the creators of React haven't figured it out, what makes you think you can?
Most of my apps are now simply HTMX + Go + SQLite. I've found it's enough for most projects.
People who built a crappy website using React are just as likely to build a crappy website using Astro, HTML-first approach or any other technology
> My client was a utility company
> Adding a lot of pressure, this was a regulated monopoly
> Some requirements I derived: > ... > We had to meet WCAG accessibility (the team settled on AA rather than AAA)
The author doesn't doxx their employer by giving any dates, but if we take the story at face value and assume it took place in last few years, it is pretty shocking.
How does it take a single hero to be fighting for AA compliance as an afterthought for a project with this scope in the 2020s?
I've worked on much more niche projects that treated this with the respect it deserves as a quasi-legal requirement.
As a public policy specialist (and a tinkerer when it comes to tech), I read the article with pure joy.
This is the "wonder" that happens when you build for the client instead of for yourself. It takes being truly intentional: sometimes the client (especially that kind of client) does not know what he needs or want; sometimes you as a dev simply build something with good intentions but just out of habit.
Taking the time to ask true, relevant questions, and build backwards, is one of the ways you achieve this. It takes time, energy, intentionality (once again)... but it's worth it.
How many people are using browsers which don't support Javascript in 2026, and doing so out of necessity rather than out of choice? I can't imagine this number to be >1%.
How many such devices can still support modern TLS certificates anyway? By this logic, shouldn't we also use plain HTTP instead of TLS?
I am not familiar with this astro framework they used. But having built some sites using Pure HTML/JS back in the day, React, Angular, Vue, Rails ERB, Rails Hotwire, and HTMX. I think HTML first websites are absolutely the way to go. Rails Hotwire with View Components makes rails sites super fast, faster to develop and easy to re-use components. HTMX more generally, but Ive used it with Spring boot and Thymeleaf. I really don't want to go back to SPAs. Development time is less and the website performance is better, and I haven't really seen any regressions in capability. With HTMX and some url parameters, I can make a pure HTML site that seems like a Single Page Application but without the excessive loading times.
This is such a great story. I am glad more people are sharing stories like this. I hope my article the other day inspired more to develop lightweight websites:
https://inavoyage.blogspot.com/2026/06/im-building-parallel-... https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
> this was a regulated monopoly, and if their customer satisfaction dropped below 96% (if I remember correctly) it could result in millions of pounds in fines.
OK, I'm still at the beginning and irrelevant to the article, but as a USA-ian, I am so jealous about that. Unheard of here.
I like JavaScript-light websites just as much as anyone (my own website works on the same principle). However, I do wonder how much of the increased traffic has to do with AI agents that now have an easier time working with the more standard web forms. My own contact form had a bunch of bots quoting Scorpion lyrics before I added a rate limiter.
Good post, but:
> A venerable web application pattern that has had a small modern renaissance thanks to Remix
Remix is not that popular. I don't think attributing this to remix is accurate. Next.js quite possibly.
> When we launched, the number of people completing the form doubled. The analytics people didn’t even know where these users were coming from. Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures.
Yeah, reminds me of the b52 story re holes in wings on the planes that made it back from missions, leading them down the wrong path of strengthening wings. They weren't looking at the planes that never came back with holes in the fuel silages.
The quote from Terence Eden almost made me cry. Actually the whole article did.
Old people. They exist.
Not even that old. 60 year people can't user your fancy site because then don't have an internal model of how a computer works.
You know that when pressing a button a hidden engine runs in the backend (or something runs in the backend). You expect an answer and if the expectation do not match the result, the model in your mind creates an hypothesis about what maybe happened and iterate from there. Maybe you should have clicked something before? Maybe you should mark some form checkbox?
Old people don't have that because they didn't grow up with computers.
What is on the screen is what they see. I clicked next and nothing happens. Well... the site is broken.
You known when you plug your refrigerator and nothing happens and instead of reflecting on the possible blown out resistor that you can bypass with a small wire you understand that your only relationship with the refrigerator is plug and unplug or call for help? That is an old person using your site. They won't fight against it. They'll give up immediately.
Yeah the uk gov website is indeed petty damn good. For once all the money dumped into studies and what not produced an outcome.
I want to work with people like this. Build the right solution to the problem with the simplest technology you can.
Hmm I cannot load the font on Firefox 151.0.3 Arch Linux. All I see is only a title and empty paragraphs. So I end up reading the article in the source code mode and felt pretty on-brand.
Back to HN comments it looks like this wasn't actually intentional?
Empathy and respect for users is what product managers should be doing.
Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.
I still to this day is baffled by all the idiot geniuses who thought it was OK to have "Please enable javascript" when opening a website without JS enabled. A good chunk in many pages are just static content. You should be able to render HTML. Ashte!
What do people like for form validation?
In this article he recommends the “validation-enhancer” library:
https://www.npmjs.com/package/validation-enhancer
I’ve also seen one called “formisch” that the author of valibot is working on:
https://github.com/open-circle/formisch
They’re both pretty new. Has anyone tried them?
Can anyone confirm if Web Components work in the old psp web browser?
I've tried this before and I think this constraint is something that has to be kept top of mind for a designer not just the engineer. Most designs these days assume a single page app and there are interaction patterns that make plain HTML not suitable. But if you incorporate this in from the start and stick with it, there's no reason you can't do this.
Great work. I love it. We need more developers like you.
I've started getting traffic on my website only after I re-build it with a locally-brewed MD parsing engine that uses Astro to spit out the final version of the site.
I guess the main argument is how easy it is for an LLM to ingest the content, since I can bet all of the crawlers are llm-enabled one way or another.
> […] it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”
Is it more work?
Use Next.js Bro just know React and complaining it.
My go-to for spinning up a site has been Jekyll + Bootstrap with the occasional bit of React for well over 10 years now.
While it still does the job, I'm a little curious to explore more modern options, if for nothing else to understand the choices a more junior dev would face/make today.
I'm seriously considering giving Atro a go. Is it worth it?
I'm not a web dev and my needs are pretty simple but I've had a lot of success with jekyll. It's a open source static-site generator.
> Javascript and modern CSS should be used to enhance the experience
When messing around with my blog's Javascript, this mantra is so thoroughly embedded into writing it, that I try to include "enhance" in function names where it makes sense. I might have to do likewise with my CSS.
I was a little confused by "doubled our users" since that's more about inbound traffic than site experience. I guess it's really shorthand for "halved form abandonment" which is still pretty great.
All the text is invisible for me in Firefox on Linux when the `--font-body` is set to `"Atkinson", sans-serif`. Setting it to `"Atkinson Hyperlegible", sans-serif` fixed it.
Designing for failure modes (bad network, old devices, no JS) often leads to better systems even in the happy path. This is a good case study of that.
Recently I had to migrate an old SpringBoot app that had a React front-end to a new cluster. Not wanting to mess with super-old dependencies, I opted to rewrite it on a new version of Java/SpringBoot. When it came to the frontend, I paused. I couldn't come up with a single good reason why this app needed React. I rewrote the frontend in straight HTML with a little bit of JavaScript for DOM manipulation. I literally used `var` instead of `let/const` just to drive the point home... (yes, that was overkill). But you know what I didn't need? A BUILD PROCESS! No npm deps. No vite/rsbuild/etc. It was like I had forgotten we could even DO that.
Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.
Interesting they went with Astro.Makes sense for a form-heavy site. No JS until you need it,and it handles page transitions cleanly.
As a non-web dev, I have a question about this part:
> There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”
Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard <input> components for the form, have a submit button at the bottom. When I was making my own websites many years ago now, that's how it worked, and it wasn't that hard. Maybe it's reflecting my ignorance in this field, but doing fancy front-ends seems much harder to me.