ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
54% Positive
Analyzed from 7964 words in the discussion.
Trending Topics
#react#html#page#don#web#more#user#form#site#using
Discussion (211 Comments)Read Original on HackerNews
> 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.
A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.
As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.
Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.
These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form.
It’s a culture of not giving a shit. That’s the real issue.
It's akin to writing a backend in Haskell. Chances are you could write something performant that leverages FP in a way that serves as a magic bullet for your domain. But now everyone after you needs to learn Haskell and how to model all future problems in a way that conforms with it - or rewrite things again.
Before LLMs I would have agreed.
I am convinced the one single thing that made HTML unusable over the time was that people wanted or needed a way to re-use parts of the page across multiple pages, like headers, navigational elements and footers.
This meant people used frames, PHP, templating engines or any other new technology mainly for the purpose of creating shared elements, simply because HTML failed (and to this day: fails) to offer a way to include one HTML file in another without having it suck (like frames definitely did, since the browser treated each subpart of the page like its own entity including caching).
But do we really need all that stuff? Build steps, bundling, tree shaking, all for what? And is it really simpler… hmm
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.
If the button doesn't work, the average user is going to say "this most be broken" and then use a competitor (or contact your support). That's why it's really important to error-proof one's design (eg https://en.wikipedia.org/wiki/Poka-yoke).
So instead of the button failing because you didn't check a box, pop up with a message telling them "Please click $box before continuing". Or if you want to be fancy, feed them whatever form you're giving them piecemeal, so that they can't continue until they finish this small part (e.g., have them input a name, then the next page only has a spot for an address, then the next page only has a spot for card information, then the next only has a spot to select shipping). Simple bite sized chunks anyone (well, anyone you would ethically want to sell to) can understand.
Either it works right away without any further questions, or they'll not do it.
Sadly, also if they can't do it on their phone, they will not do it. It's actually very hard to get people motivated to do anything that has to do with sitting down at an actual computer anymore. Which is a bit hard if you're in a very technical political advocacy group, kinda makes me the guy to do everything remotely complex... XD
Aren't insane.
When did the industry put the onus on the user to understand how the computer works? What happened to the old days of Xerox PARC's HCI studies putting the user first? The computer is in service of the user, not the other way around!
If I need to build a mental turing machine to understand your application, it is a bad application. It is rather the engineer's job to build a mental model of the user and their needs, and if you can't do that you should not call yourself a software engineer.
Maybe this isn't applicable to all software devs. If you make web apps, users actually see your UI, they click an icon or type in a URL and hit enter with the intent of using the thing you made. With firmware, that's not how it works.
When you hit the "mute" button on your laptop keyboard, it should just do it. The audio should turn off and the little LED should light up. If that fails, even once, the mirage is broken. The user is forced to think about the fallibility of firmware, which is a word they might not even know, and still struggle to conceptualize if they do. I think it also has a lasting effect on the way someone thinks about the pruduct: Is this going to work today? Why did that happen? Was that a virus? So on.
OTA firmware updates have the same problem. Most users don't know what the hell firmware is. All they know is their computer is showing a loading screen they've never seen before. It's unfamiliar and weird.
Like I said, I don't know if this mindset translates perfectly to other fields, but the priorities that fall out of my philosophy certainly apply. Reliability over everything, and get it right the first time.
This is even true for things as seemingly non-technological as getting to your flight once you arrive at the airport. People who are used to dealing with a service desk might just show up with their printed ticket without even having looked at it, take it to the counter, and expect instructions on what to do next without having read or considered all the fields present on the ticket.
It's not just about understanding the technology, but sometimes about understanding the business, policies, whatever. When a human agent or customer service worker is handling that stuff for you (typical in the pre-computer age), you barely have to think about that stuff and even if you're told, it can be "in one ear, out the other". Automation very often means pushing a requirement of more understanding onto customers/users.
I think this is a bit outdated. I'll be 60 in a month, and have been practicing and writing about machine learning, for money, for a straight 10 years now; and I was a young man (and a full stack developer) during the digital revolution.
If anything, GenX had to work harder to get into these brittle emerging technologies and paradigms. There's no-one of my age group, at least that I know of, who is remotely as tech-illiterate as your comment depicts.
Truth is that it took so long for smartphones to dumb down everyone's tech acumen that those of my generation had already learned to do it the hard way.
My mother, born in 1934, had no problem using computers. She didn't internalize how they work, but she learned the workflows she needed. How to launch applications and so on.
The situation described in that comment is just a broken app, it has nothing to do with the age or the understanding of the user.
my mum, a boomer now in her 70s, would have no bloody clue what you're talking about. she used to work helping out a guy who was doing punchcard programming back when she was young. she ain't dumb. if i broke it down into normal human english words, she'd probably get a sort of idea (or at least nod along to humour me).
i've lost count of the number of conversations i've had with my dad, late 70s boomer, where he complains that they've changed the UI. "It's all different and i don't understand, why did they have to change it? I don't know where anything is now." he's been moaning about things like this for over a decade now (so since his late 60s).
there are definitely technically not-very-literate 60 year olds and the general point about older folks, whether that's >60 or >70, is very real:
older people exist who don't have a clue about SPAs/PWAs, and chances are they're either asking their offspring for help (my mum does this), trying to phone someone instead (my mum does this) or just walking away from it (my mum does this).
You know, it's time to stop this trope.
People who are 60 today were born in 1966, they probably entered the workforce in the mid 80's. They probably are not even retired yet. They know how to use computers, they own a smartphone (or if they don't, it's probably for economic reasons unrelated to their age).
As a founder and product manager, this kind of thinking is unhelpful as we design the future. In many ways it's actually ageist to imply that old people are unable to utilize everyday technology.
I was building public service websites (BBC News website) back in the early 2000's where accessibility was a real and important consideration. Technology progresses, and the bar for accessibility has moved up.
My father is about to turn 80 - he checks his heart with his Apple watch, video calls his grandson from his iPad, and asks ChatGPT questions from his iPhone and MacBook Pro. Maybe he's more unusual for 80yo's but it's time to stop this lazy trope that old people are technically illiterate.
(also, shit, I'm only 15 years away from being 60 myself :/ )
Keep it simple and light. HTML+CSS first, JS to expand functionality. Don't re-invent the wheel.
I wouldn’t sweat the broken fridge either though, there’s so many other electrical appliances in the house to use.
If the creators of React haven't figured it out, what makes you think you can?
> 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 can't imagine trying to use links/lynx or a browser with less market share than FF that isn't based on chromium.
It doesn't work if you disable JavaScript...but it wasn't always this way!
They had a mobile version of their online banking service at https://m.chase.com that was EXTREMELY FAST and did 85% of what you need to do in an online banking portal (check balances, transfer funds). They scrapped it when they moved to their current bloated monstrosity of the portal that they have today.
It was a big reason why I moved to a credit union (who outsources their online banking services to Alkami, which maintains a very tight portal and supports 2FA AND passkeys!).
Someone at chase isn't checking their work on firefox.
Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.
React is too heavy weight for a lot of things. But it's ridiculous to call it disrespectful.
And don't dare to contradict me, the fact that MIT-bred leetcode ninjas paid half a million per year can't produce a simple (mostly static) website on that stack it's only because of management that wants to ship the next product. /s
[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.
There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS.
If 2009 is too far back you can try your luck in 2012 with Firefox OS.
Joking aside, people and companies have given it a go. But a combination of bad timing and various other events never made that reality happen in our timeline.
Running `npm install` on Android isn't so easy.
(Caveat: The new Android Terminal that only works on a handful of models.)
It's not great for every task - in particular the lack of abstraction-building capabilities - but it's great for business-logic-heavy server apps, probably because it's specialized for that and not trying to be a jack of all trades.
I can't imagine this kind of traffic without acting as a CDN, advertising broker, pornographer, or part of a massive ecommerce site. I have to wonder, what are you doing that generates 10TB of traffic per month?
Pages has a 20k-100k limit on static files, but if they just guide you to R2 to offload it, which is still Cloudflare.
Did you mean the CDN? In which case, I'm not seeing that in the terms. [0] Though, I would have expected they'd have a similar thing. R2 resources don't generally count towards your cache limits.
[0] https://www.cloudflare.com/service-specific-terms-applicatio...
Working on a "simple html page" that is actually 5 different independent "subpages" (routes, views, templates) in the backend is awful. The UX was improved, but the DX was sacrificed.
I recommend having a single view function for each page/SPA and do sub-routing within that function to handle page fragments. In other words, use a GET/path/Header parameter that indicates which fragment is currently needed, defaulting to the full document as normal. Just make sure you are considering request logging and client-side caching in your solution.
This makes it very easy to add/remove async content from the page, since you are just editing the one view function/template and you can easily reason about the entire page as one logical unit.
It also means you don't need to duplicate security logic or other middlewares for the page, since it can be implemented once at the start of your multi-faceted view function.
Would like to hear about your Go stack for building htmx apps.
These gems are brought to you by the department of redundancy department.
My favorite from Southern California.
"ATM" means "Automatic Teller Machine", so "ATM Machine" is "Automatic Teller Machine Machine".
Both are mentioned in the animated movie "Spider-Man: Across the Spider-Verse".
https://en.wikipedia.org/wiki/Chai
The applet took 30 seconds to load. Once it loaded, it showed five buttons to click to get to different sections of the site. When you clicked on one, instead of changing the content frame, it sent you to an entirely new frameset. This, of course, caused the sidebar to take another 30 seconds to load. Hitting the back button did the same thing.
Meanwhile, I knew someone whose friend made a little applet that he showed me; it was a Java applet that you could provide an image URL for and it would load the image and then, below the image, show a rippling effect as though you were looking at something on the shore of a rippling lake. This applet took less than a second to load and ran incredibly smoothly.
Java was a curse, not because Java was bad but because Java applets were written badly and used badly simply because they were neat.
I would like to say the early interweb was just a learning experience, but today's interweb hasn't learned any of the lessons. It's just changed which language the lesson is being relearned
Every single person I showed it to including my then-70-something mother said "that just looks like menstrual bleeding".
Every single person said that.
They still went with it. Conversion rate? Dunno, never got numbers high enough to test the script.
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
"Satire isn’t dead.
Satire won.
This is what it looks like from inside, looking out. "
Nice work!
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.
Embrace Extend Extinguish is real, and the people going along with it deserve to be replaced by a LLM that lies and spits out garbage code just like they do but faster.
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.
You could argue that the constraints of using HTML-first (as they call it) helped them stay away from the bad patterns they were using before.
But you’re right: The user change came from fixing the design, not the technology used.
This is a lot like those bad resume bullet points where someone tries to claim an increase in business was due to their code change. “Increased visitor count 100% by rewriting website to be HTML-first”. Then when you ask them about that point they concede that the entire site was redesigned to fix some design problems or add a feature and that’s what drove the visitor increase.
Fun thing, TFA describes a kind of multi-page wizard style form that I haven't seen a lot anymore in the last decade or so. But when I did see it, it's always some dogshit enterprise system. Some Oracle product for expensing expenses last time.
The problem with those things always seems to be that they are slow in the middle of doing your task. Every button is seconds of waiting. Doubly annoying if you have to go back a step or two. The badly coded SPAs seem to be slow at the start. It takes a while to load, but once it's loaded its performance is usually okay.
* Have working back/forward buttons * Have working progress indicator as provided by the browser * Show errors to the user - even if they are ugly * Be accessible to keyboard navigation
With SPAs these are all things the developer has to get right.
So often when using a SPA I'll click a button, you get a spinner and then nothing will happen. Is it still in progress? Don't know. Eventually I'll open developer console and trace the network requests to find the JSON HTTP request that returned "ERR_BAD_EMAIL" and fix what I've entered. With a normal form submission at least the user will see the error message and can press back and then fix it.
The article is clearly aimed at non crappy developers or developers who want to do better for their users.
And it provides an anecdotal experience where an HTML first option developed by a good developer was far superior to what a JS necessary option would have been, given the user base of this application.
(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)
This is an absurd statement. Just because something is a proverb, doesn't mean it's automatically true for all cases.
But I 100% see where the author's coming from, considering the massive fragmentation of react codebases/patterns and decision paralysis of React development in general. I really doubt most React apps, even the more accessible ones, are testing their multi-page form wizards with JS completely turned off.
HTML-first does seem highly underutilized in the commercial web, and I learnt a lot from reading this (as a solidJS/react dev).
An "old school" Ruby on Rails/Symfony/Django app, with templates, usual get/post forms etc, frames you and pushes you in using the standards and relying on browser default behaviors.
In JS-heavy apps, it's as easy to code normal `button` elements as it is to code clickable `div` elements. But with the divs you just forget to handle keyboard nav, proper element roles, etc. It's easy to create fake links, not relying on `a` tags, using an internal JS router that doesn't expose URLs, doesn't handle middle click mouse, for no particular reasons.
In less JS-heavy contexts, the easiest way to do is to use proper HTML so you are less inclined to mess up.
Even on codebases that use a decent framework like Next.js that handles those for you on paper, it's often we see people not very aware of the benefits of using proper semantics and standard behaviors, and you easily end up with web apps with poor UX in the end.
Astro itself works just fine with React, and it can still be HTML-only.
But you can also render React on the server yourself using renderToString, if you don't want a framework.
Too much VC money and big tech influence in the JS ecosystem made the web worse in some ways.
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.
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.
Personal anecdote: Recently they were updating everyone to "smart meters" on the gas lines. They needed me to be home so they could enter my apartment and bleed the gas out of the line by turning on the stove prior to replacing the meter. I played phone tag with them for 6 months, setting up countless appointments, and nobody ever showed up, the meter remains un-upgraded. At the same time, I have received weekly phone calls and monthly physical letters stating that if I don't upgrade the meter, my gas will be shut off. I just moved, so the new tenant will have to deal with it now.
The public sector, simple, no frills, accessible, no flashy graphics, websites were a massive eye-opener.
They just worked. They had a job. They did it. I wasn't going to buy more from them because of it, and they didn't care. It was great.
I've heard that recently they've dismantled the centralised team that wrote all the rules, enforced it, and started moving to decentralised hosting, but so far the whole still seems to hold to together really well. I think, I hope, they have embedded the expectation that the local council, the tax office, your visa status, etc, should just be utilitarian in nature, and work for everyone.
I worry how long it will last...
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?
> 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.
> A venerable web application pattern that has had a small modern renaissance thanks to Remix, form submissions and redirects took a while to explain to my colleagues, on account of everyone being used to heavily client-side web applications.
(Although it's not really a joke, it's pretty amazing how many professional web developers these days don't know how to use forms without JavaScript.)
I recently had to intervene during the latest office holy war to explain that you don't need JS for file uploads.
It was eye opening.
I'd be curious to see the stats on how often Next.js users lean into the server component model that makes the frontend fast. My anecdotal experience is that it's an afterthought for many. By comparison, Astro (as mentioned by the author) makes you think about this stuff upfront via opt-in rather than opt-out. It's a wonderful framework.
https://inavoyage.blogspot.com/2026/06/im-building-parallel-... https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
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.
Back to HN comments it looks like this wasn't actually intentional?
You've only got yourself to blame, there.
Is it more work?
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.
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?
P.S. your solution seems to have disabled the custom font instead of fixing it
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 ...
Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.
it doesn't work for everything and imo is worse for (p)react due to the lack of native JSX, but it does allow for bringing in stuff that usually takes an `npm install && npm build`
https://www.gov.uk/service-manual/technology/using-progressi...
What were some of the downsides? Illuminating the tradeoffs would elevate this post from good to great.
> "but that’s a lot more work for us."
And it's not that any individual or team is lazy. Most teams have a constant barrage of priorities to balance and are paid by companies valuing efficiency over everything. That said, I think the article makes a great case for adjusting our prioritization. Going a bit slower won't kill anyone, in fact doing so will probably save some.
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.