> 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.

[0] https://triptychproject.org/

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.

https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...

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")

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.

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.

> 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.

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.

Too much VC money and big tech influence in the JS ecosystem made the web worse in some ways.

If the creators of React haven't figured it out, what makes you think you can?

> 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.

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 such devices can still support modern TLS certificates anyway? By this logic, shouldn't we also use plain HTTP instead of TLS?

https://inavoyage.blogspot.com/2026/06/im-building-parallel-... https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...

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.

> 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.

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.

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.

Back to HN comments it looks like this wasn't actually intentional?

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?

Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.

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.

Is it more work?

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?

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.

Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.

I have done exactly that on a project that was under similar constraints. The UI models live in .tsx files and the browser gets pure HTML with zero JS by default.

I don't want to be that guy, but the title is misleading. The number of users completing the form doubled.

why not take the html5 standard (see https://html.spec.whatwg.org/ ) and if needed (dont think so for these use cases... "for clients ranging from energy companies to political parties") htmx or alpinejs ...

What were some of the downsides? Illuminating the tradeoffs would elevate this post from good to great.

Personally, rather than this luxurious approach, I just do one giant form and store all values in local storage. If something is wrong have one message at the top listing which fields failed validation and why. Generate some css to put a red border around the fields.

Local storage might not be a good idea for such sensitive data but if you can get away with the simplicity it's lovely.

>The PSP’s web browser is - charitably - pathetic. It is slow, frequently runs out of memory, and can only open 3 tabs at a time.

Alluring, an annoying property of private software development is that making websites and software in general inaccessible to lower end hardware is actually a positive effect, as it filters out 'undesirable' lower-income prospects.

That, along with pressure to produce fast, without much concern for quality (with notable privileged exceptions of luxury software like Apple or 1B+ user software like Google), as well as a disregard for sourcing "I don't care if you do it yourself, or npm install software from effectively unpaid volunteers", ends up in a state of software lacking craftmanship, software that one is not proud of to work in.