> 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.
Our app was fast, and simple, but it also came at a cost: we were limited in our ability to take rich UI elements off the shelf with an npm package. We had to do a lot more work to provide a rich user experience. Everything took longer, and the user experience was worse as a result. We cared, but sometimes you don't have time to carry through.
The company failed, and I don't think react would have saved it. But I can tell you first hand that righteous adherence to "simplicity" didn't help either. It's always a trade-off.
It seems like a lot more work because you have to keep the backend and frontend in closer sync. The backend has to be aware of and able to store every sub-form in the full process (which sounds like a "wizard form" with a multiple sub-forms to get through the full "form" process), not just accept a "finished" or "complete" submission. If a sub-form needs a change the backend, the backend's storage, and the frontend all need to change. The backend and frontend have to agree on validation logic for each small piece of the form. The backend and the frontend need to both validate every small piece of the form, and maybe can't share that validation logic (depending on what language the backend is written in), especially if one of the goals is to do as much of the frontend validation as possible with Browser native validation tools (`<input required` and `<input type="email"` and so forth) so that you get the most benefits of progressive enhancement.
The original ways of making websites were "full stack" and from a full stack perspective it shouldn't seem that hard to have a coordinated frontend and backend, especially when a progressive enhancement approach likely means a smaller more agile frontend, but current siloed world where frontend and backend are different teams with different goals and alignment makes that seem like way too much work.
As someone that reads a lot of code written by others, I'm confident that "learning a new way to do something" is perceived by many as the hardest thing in the world.
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).
Someone is saying that they delivered a very reasonable solution that's simpler than most would come up. Person taking over was not happy.
Do we know if the code being handed over was high quality? Were they reacting to the fact that it was "not React"? Maybe they have a template they enforce in the company about how apps are built?
We don't know.
The entire approach went out of style with the advent of single page apps, React, Angular, VueJS, etc.
I'd pee myself in happiness to take over a project like this.
that menu is maintained manually, and every time a page is added, all copies of the menu have to be updated. at some point that will get tedious. then i have a few options:
i generate the menu using a backend framework. the downside: the website is no longer fully static. i now depend on a backend framework for hosting. static hosting is out. i also have to edit the content through the backend, and i have to continuously maintain the backend for the lifetime of the site.
i generate the menu using a static site builder. the downside: i can no longer edit the content directly in html. i have to keep a source version for the static site generator, and more critically, i have to keep a copy of the site generator in my repo because i want to be able to make changes to this site 10 years from now and not find that the version of the site generator i was using is no longer available for download and my source is not compatible with the new version of the site generator.
i generate the menu using xslt. works, but xslt is no better than javascript security wise. it's possibly even worse. and xslt support may be removed from browsers in the future.
the final option is javascript. using some framework that doesn't need build tools, or something homegrown. i am afraid javascript is the only option that is futureproof while letting me avoid manual work to maintain the menu.
People expect the entire screen not to redraw whenever they interact with an app and expect behaviour asides from the HTML defaults.
To start off, writing a basic crud website with forms is much easier with htmx.
But when you start building more complex components, and integrate with other systems (OAuth for e.g.) there are tons of libraries and SDKs for the react ecosystem, but not many for pure html components.
At this point, it's much easier to use off the shelf components than it is to manually write html to handle all the bizarre UI edge cases.
Modern frameworks such as Astro allow for a similar development experience (and can optionally use JS, React and other client-side libraries) while still being able to generate a static site if desired.
I think server-side rendering and static site generation are less familiar to many web devs who came up in the React/Vue/Svelte era. The patterns and mental model are just different. In an ideal world we combine both: fast static HTML that works everywhere, with progressive enhancement for interactivity. Astro does this well; Next.js supports it too, though the SSR parts have a learning curve.
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.
The hard part is coming up with a recipe that solves your problem and that the machine can run without breaking things when it runs around with a few billion steps per second. You have to think ahead for it and handle edge cases in the recipe.
That is the really hard part.
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.
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. It feels like 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?
I created a couple libraries to abstract the SQL and HTMX/web/OAuth bits; my apps are now very similar and easy to copy features between.
Cloudflare R2 object storage is S3-compatible, offers free egress, and does not share their CDN product's fair use policy against image-heavy use. Storage is 65% the per-GB cost of S3.
Because there isn't a 30% walled garden you can create with that.
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...
Very cool!
> But yes, lately I’ve been building mobile apps. ... What can I do?
I am currently building HTMXNative.
Together with Objective-Smalltalk, which has linguistic support for REST built-in.
The idea is that you create your model in a natural way and then thinly wrap it to deliver wherever.
Would like to hear about your Go stack for building htmx apps.
There's a couple of Rust libraries like this; right now I'm building an app in Tauri+Svelte.
It looks like Wails might be a similar framework in Golang.
Your Go server can have endpoints that render XML instead of HTML and basically get the same server-driven experience of your HTMX site. Fully skips the need for the app review process since you're not updating the actual client app code to make UI changes.
There WAS. Firefox OS phone! HTML+CS+JS apps! But Mozilla kicked it to the graveyard even though it was very popular in third world nations. I guess it was not $$$$$ enough for the Mozilla CEO of that era.
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.
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.
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.
Many developers are unaware how many people are not comfortable with computers.
Here's an example with my dad, 64. During Covid, he had to get his medicine by emailing his GP instead of going to him. He received the email address as a photograph of a piece of paper over WhatsApp. (Clearly the doctor wasn't comfortable with tech either.) The paper said:
Send your medication request to:
- john.smith@some.long.medical.site.org
He said "I tried everything: lowercase, uppercase, spaces between '.', no spaces, space between '-', no space... Nothing works!"
He thought "-" was part of the email address. To some people it might seem like he was being dumb, but he's never had to seriously use computers before. When he bought our first computer he was 38 and never used it. He got his own laptop at 46, and only used it for movies and Skype, before WhatsApp existed. It doesn't seem that odd to know how email addresses work. (He is a technical person, but not a computer person. For example, decades ago he etched a circuit to make an HBO decoder so we can watch HBO for free.)
I've seen static sites with these same problems, 404 was invented decades before React...
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.
It's not about age. It's about ability.
A lot of the people I build web pages for are poorly educated. The text we use for web is written for people with an eighth-grade education. Print material is fifth-grade.
People in the SV bubble can't imagine that there are tens of millions of people in America who cannot understand how an SPA works.
These people are invisible, even as they ladle out the food in the Google cafeteria, and polish the chrome in the Meta lobby.
You realize that someone who was 18 when the Mac was first released would be 60 now?
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - May 2022 (32 comments)
Nice work!
* 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.
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.
May I ask what tech is used for mobile apps? I am guessing not a full mobile app but it uses webview.
I built some libraries that ease the process, and they power the new MOJ Forms and GOV.UK Forms.
Rails still has a decent foothold across departments, but it's being nibbled away at by Python and.NET.
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.
JavaScript: The Good Parts by Douglas Crockford is a comically short book. React: The Good Parts would be shorter still.
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.
> 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'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.
Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.
You're being generous with what I would consider negligence.
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
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.
keeping things simple is not a bad thing, and often requires you to be smart enough not to overcomplicate them.
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.
> 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.
Nice to see that Astro supports non-js browsers. Perhaps website developers, especially ones needing to develop for government services, should use 1GB Raspberry Pis for testing, but that would still have modern javascript. I got a 1GB RPi 4 in about mid-2019 and was rudely reminded of how much memory Chrome used even back then. More than 1 tab open and it would be killed.
The Eden quote is here https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven... and it has some stats of gaming consoles using uk government sites.
I can't imagine trying to use links/lynx or a browser with less market share than FF that isn't based on chromium.
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?
How many such devices can still support modern TLS certificates anyway? By this logic, shouldn't we also use plain HTTP instead of TLS?
If you're using a decade old phone to sign up for a utility, you've got bigger problems in your life and no self-respecting person should be adding to them.
- Old browsers without the modern JS features you're trying to use
- Different browsers, with different features
- JS didn't load due to network errors
Better would be to use plain HTTP in addition to TLS, rather than instead of TLS. TLS does have benefits, but if it is optional then it can also be used on computers without TLS (as well as potentially other situations where you do not want TLS or where it is not useful).
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.
And their mobile device should be the cheapest Android phone from a monthly cell provider you've never heard of. This is what the real world is for a lot of people, and a huge number of developers simply don't know or care.
Sadly, the internet as a whole seems to disagree. Even the most useful resource on the web one could use over plain HTTP, Wikipedia, only allows connections over HTTPS. I guess it kind of made sense as part of the campaign to push the internet as a whole over to HTTPS, but anyone who's connecting to any website over normal HTTP these days is doing so because they literally can't use HTTPS.
TLS 1.2, the standard, may be from 2008 but support for it in browsers did not start to appear until around 2013.
If the creators of React haven't figured it out, what makes you think you can?
facebook was super popular in 2014s because they were just starting the transition from mostly being about people to mostly being algorithmic rage bait, and they tapped a new market of fox news/conservative talk radio listeners
You don't have to have a technical discussion whether or not React is too complex, you just have to look at the average website created with it.
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...
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")
2. The design constraints had always existed, the previous app just failed to meet them.
Too much VC money and big tech influence in the JS ecosystem made the web worse in some ways.
I've had far more trouble with web pages that only work on a computer that's at least 80% similar to the developers computer, and the RAM sacrifice has been accepted, than from bots diluting real user-generated content, assuming I can even get to the page, if the CDN doesn't think I'm a bot myself, because I'm not logged into a Google or Apple account and their captcha is so bad only a bot could get through it.
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.
Back to HN comments it looks like this wasn't actually intentional?
You've only got yourself to blame, there.
All completions were real people. It's a government website.
JavaScript-heavy approaches are not compatible with long-term performance goals 178 points by luu 3 months ago | 237 comments https://news.ycombinator.com/item?id=47029339 (should be called "Why React is not compatible with long-term performance goals")
Does anybody like React? (jsx.lol) 242 points by brazukadev 15 days ago https://news.ycombinator.com/item?id=48274077
https://news.ycombinator.com/item?id=30528473
SPAs Were a Mistake (gomakethings.com) 692 points March 2, 2022 | 620 comments
Did I miss it, or did the article neglect to explain why this was a problem?
Also, Microsoft.
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.
Sometimes it is just a form that you need, with the web page loading a new one after 'submit' has been clicked. Yes we can do fancy things to ajax-submit the data, but did the customer want that?
Getting to the form in its 'final form' takes work, particularly if asking the customer for more information, such as proof of purchase or important documents. Do you just start the conversation with a 'contact us' box to have customer service ask for the bits they need later, or do you ask the customer for all information up front, reducing the need for back and fore?
You need to actively test what your customers will do, with metrics such as time filling in the form and how big the ticket queue is.
There can also be internal problems that prevent getting the form right. For example, if there is some manager in charge of customer service that is an empire builder, with a vast team. If your form decimates the team because everyone is efficient and able to go home at the end of the day with an empty queue, then you have undermined the empire builder, so he will want you gone!
There are some huge benefits to getting customer service right. You can brazenly have phone numbers, email addresses and even physical addresses, all published on the website. If the forms work then the phone never rings, the inbox is empty. And nobody can accuse the company of hiding behind a wall of corporate website small print.
The word of mouth aspect is also not to be overlooked. You can harvest reviews from happy customers that should have been unhappy under the old system. If you fix their problem in an hour, or get a replacement product to them the next day, then they will write you a rave review, with that being great for the customer because they explain better than you can how dedicated your customer service team is.
I use the word customer lightly here, there is the term 'service user' that is used in the public/third sectors, but that doesn't sound good in front of the 'service user', probably because they have an actual name.
Getting to the form 'in the final form' means quite a few small changes that can be easily reverted and monitored. It could be just making an input box only show capital letters, or show a numeric rather than standard keyboard.
Ideally, a submitted form does something when completed to place the ball in either the customer service court or that of the customer. If the customer need to provide some information before anyone need look at the ticket, the form needs to send out that email, then park the ticket awaiting whatever the customer does next. There should be no need for someone on the team to do that step.
I know AI does everything awesomely under all circumstances, but the 3-6 month journey needed to deeply understand the customer, the product and the team is something that needs a human, simply because you are dealing with humans and their emotions.
What has proven to be a huge bonus is CSS grid styling. Inputs and labels can be written without the div and span cruft, with everything lining up nicely with a few align 'center' CSS things.
What a fun time to be doing forms that actually work!
> 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.
Ideally, they ignore WCAG altogether, then throw on an overlay if compliance is required, which can be easily blocked by a dedicated blocker (e.g. https://www.accessibyebye.org/) or I just add a list of overlay domains to my ad blocker.
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`
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?
Accessibility functions are also helpful; if designed well then it would be helpful for everyone (not only if you are blind or other disabilities), in many possible circumstances.
We have to eat the bullet, there is only one way out: restore noscript/basic HTML interop in "security" infrastructures (can still have a non-mandatory web app on top). And it will probably require super strong _technical_ regulations and expect the 'whatng cartel' to fight hard, because they won't like critical web sites not being web apps then forced to run on their massively complex web engines...
Don't forget, a few years back, most, if not all, online services were able to run on 1D or 2D (simple table) HTML documents.
https://inavoyage.blogspot.com/2026/06/im-building-parallel-... https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
They have also either completely forgotten or for newer devs never learned anything about HTML / non JS front end development. Hence "but that’s a lot more work for us." Somewhere along the line HTML and CSS became Assembly. They somehow became dark magic.
For real users, no one cares about the tech being used. And most of the so called advantage provided by JS front end sites are at best marginal and realistically speaking imaginary unless you are Google Earth or Online photoshop / spreadsheets.
> Shipping them 20MB of javascript before we even render a form would be a ridiculous thing to do.
> I have seen teams waste person-months of effort wrangling React validation libraries.
> It is not acceptable to bounce users on old browsers, users with bad network connections, users using assistive technologies.
> Build a web application that works on a playstation portable on a 3G connection - if you do, it will work for all your users, and it will still work 30 years from now.
The other day I added a fix so that the website would work in a PS5. Before that I didn’t even know that PS5 has a browser.
This is so sad
To some extent, I share the view that forms should be simple (e.g., at one point I built a reservation system that worked in Links2 (the CLI browser)), but having a blog that can't be read in a modern Firefox seems a bit weird when preaching such messages.
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.
Large spa apps are very fast if components are only loaded when needed
Coming from a angular1 -> vue2 -> svelte2 -> settling on pure web components with no shadow dom it's a joy to work with, and fast
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?
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.
Even if it is more work (it isn't, the author of this phrase probably is just not familiar with this "tech stack"), the sum of saved time for the users is far more important.
That's it. I will report back if it works.
To apply for their services, customers could either use an old ASP form on the website, or follow a manual process
"Clutched in her hands is a games console - a PlayStation Portable. She stares at it intensely; blocking out the world with Candy Crush."
>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.
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.
I don't want to be that guy, but the title is misleading. The number of users completing the form doubled.
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 loathe this area of software development, loads of unnecessary frameworks and spinning gears that add complexity while making less and less functional applications
Ah yes, when you have to explain to your esteemed web developer colleagues how the web works xD
This made me really, really angry.