Funny enough. I’m opening this on mobile internet connection and it stuck at loading spinner. I don’t know if the problem is with my internet (probably not) or support for mobile so I can’t even read the content.
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 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!
It's still present. JSON/JS parsing still has a delay. And in either case (as the author states) not everyone is using an iPhone over 5G. Heavy React apps are a miserable experience on low end Android phones, even when the connection is fast. I've seen JS/JSON parsing times in the multiple seconds.
"What, support Safari? Isn't that, like, less than 20%? And its standards support is abysmal! No, not worth my time, they can upgrade to a normal browser like everyone else."
Read the article. Typical users had old browsers often with poor reception. One user was using a PlayStation Portable which had very limited WWW capability.
If Rick Rubin could take a tape to his car to listen to his mixes, your product people can try their websites on £20 phones from Tesco. They can ask to sit in on user tests with minority groups. Extending your knowledge like this is trivial, but rarely done.
You're not a good and modern engineer who knows his craft if you aren't defaulting to react and tailwind.
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
I did some work for a company that spent nearly a grand on a Flash animation for their title page of a red bouncing ball that would bounce from right to left along the letters of the word "Yipee" (yeah totally not ripping off Yahoo! were they?) until it landed in the crook of the Y, where it would spread down the middle - the finished logo had the Y made out of blue, yellow, and red stripes.
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.
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.
Go is so awesome for server apps. I should have discovered it much sooner. It somehow sits in the exact optimal point having no bullshit overhead like C, yet also getting out of your way so you can focus on the business logic like Java (not Rust).
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 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.
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.
>One of my sites is image heavy and serves 10 TB of traffic per month
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?
> 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.
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:
I disagree. An HTML website which uses links, forms, buttons and inputs will by default:
* 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.
I find it's way easier to build crappy React apps than an HTML-first approach.
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.
True. Crappy developers will build crappy websites irrespective of the tech.
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.
It's definitely possible to make slow server-rendered website. Most of the slow client-side apps are slow because they're waiting on slow network requests.
(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)
but the host (the company) will need to pay the price in the form of server equipment. Not the user as is the case with client side rendering. If server side rendering becomes slow it will affect all users regardless of their hardware or connection, prompting earlier response from management and devteams.
This is patently untrue, give a craftsman terrible tools, and they'll still produce a decent end result. That said, defaults matter, and astro is going to be significantly more friendly out-of-the-box to low-end clients
Not really, no. Astro requires you to opt a component in to client-side rendering, React (with its server components etc) require you to opt out. Defaults matter in scenarios like this and I'd bet the average developer of crappy websites would have a much faster site with Astro than React for that reason alone.
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've always liked basic HTML pages where one can upload a document without having to restart the entire application. That's a great practice you have there with general forms. With each session ID, it can cross reference a page in a multi page application with that session ID, so that the user can maybe type it in if necessary, but it should be able to determine that with enough information, like IP address, upload date, browser, OS and so on. But the most accurate session would be within the browser so that the cookies for a single application aren't mixed up with another applicant, like a relative, who might be using the Playstation Portable.
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?
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.
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.
> 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.
That hit me, too, specifically thinking about my current gas/electricity provider. I have not heard one single piece of positive feedback from the public, and there's only ever problems. I feel like that's a pretty universal experience here. Even outside the scope of websites, it holds so very true.
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.
> 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.
The full context of that quote makes it clear that it's meant more as a wry joke:
> 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.)
The opposite is why I'd never be a good web developer. I grew up messing around with PHP and if I spent the time to learn the modern stack, I'd constantly be thinking it's stupid.
I think the author is suggesting that Remix was the inspiration for the renaissance, not that it's necessarily the most popular method for doing so.
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.
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.
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?
in the bio ... "has over twenty years of experience building highly accessible and usable web applications"
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 ...
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.
esm.ah let's you include "complicated" JS that isn't usually found in CDNs.
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`
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.
I think that's even more significant, since it's measuring people who cared enough to click the form in the first place, which is juicier than just page loads.
If you're a "React person", as the article puts it, friendly reminder that you can render components to HTML and serve that to the user.
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.
Maybe this is heretical in today's AI hype climate but...weirdly due to the rise of AI, then AI-slop polluting everything, a lot of old fundamentals are coming back. Clear, well-structured, descriptive content on a well-built page has a better shot of being picked up for SEO/AEO/whatever which are the same best practices from 2005. A lot of these tips and tricks and hacks just aren't going to move the needle as much anymore imo.
SEO and accessibility laws have always been the most effective way to convince someone to build clean, well-structured webpages. Guess what, both are measures of how easy it is for a machine to extract content from your pages. AI is just the latest machine that wants to slurp up your soup of tags.
Totally agree, gov pages should be widely accessible. Also gov services should NEVER mandate internet access. There should always be a way for tech-illiterate people to ask someone, and fill their forms
> In the most recent, contractors in another country had built a React app. The React app was online for 3 days before being pulled because of customer complaints. I took one look at it and told my boss “we can’t take ownership of this.” It was a mess of loading spinners and global javascript states. It was not accessible. Image upload was a vital part of the form, and it attempted to store images (along with all other form data) in localstorage which has a 5mb limit!
> contractors in another country
Sorry to spoil but the problem was not react. The problem was clearly this excerpt because we all know which country it was.
No we don't. There are lots of countries with software outsourcing industries, and contractors in any country can be good or bad. Would you rather have a top IIT graduate, or someone who took a year of programming classes at a community college in Fresno?
Idk, the general javascript spinner situation is beyond normalized at this point. I think mainly driven by React and other large/overkill JS frameworks. I avoid JS/TS heavy stuff so I don't really know but that's largely the impression I get. The whole thing reminds me of dialup era internet were we all were watching progressive JPGs load on a slow connection despite the fact I have fiber. I can't believe anyone is Ok with that UX, I don't see how any framework choice justifies introducing that type of behavior.
The counterargument: In Defence of the Single Page Application:
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
Funny enough. I’m opening this on mobile internet connection and it stuck at loading spinner. I don’t know if the problem is with my internet (probably not) or support for mobile so I can’t even read the content.
I think that's the joke :) all other articles load fine instantly, just this one that has a spinner
Heh it got me then :)
Whoosh! Right over my head. I feel a little silly, but also, got me!
Got me too :-)
My guess it’s a joke.
it's a sarcasm loader
Sufficiently advanced parody is indistinguishable from reality.
I wish I hadn't read the replies. I love being made the fool (though not to worry, I'll have plenty of other opportunities, likely today!)
All I got is a "loading" animation. Gave up after 10 seconds. So, not a counterargument, but a confirmation of the article's thesis.
It's a joke/sarcasm
I got wooshed.
Nice work!
lol this got me
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 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!
[0] https://triptychproject.org/
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.
"If our users can't afford the bits, we don't need them!"
They don't know what a megabyte is
They feel the slowness of the page load
Not on their iPhones operating over 5G or the corporate WiFi.
It's still present. JSON/JS parsing still has a delay. And in either case (as the author states) not everyone is using an iPhone over 5G. Heavy React apps are a miserable experience on low end Android phones, even when the connection is fast. I've seen JS/JSON parsing times in the multiple seconds.
There's 5 bars 5G and there's one bar 5G anyway... Citing connection types really is completely beside the point.
You don't think there's any palpable difference as long as the connection is any good?
I think there’s a palpable difference but many young developers have no concept of why.
"What, support Safari? Isn't that, like, less than 20%? And its standards support is abysmal! No, not worth my time, they can upgrade to a normal browser like everyone else."
Read the article. Typical users had old browsers often with poor reception. One user was using a PlayStation Portable which had very limited WWW capability.
The person you are replying to is saying the PMs are using new phones on WiFi, not that the customers are.
But if they dont, where is the disrespect? They dont know what a megabyte is, they dont feel a slow page load. Where is the disrespect?
React is too heavy weight for a lot of things. But it's ridiculous to call it disrespectful.
If Rick Rubin could take a tape to his car to listen to his mixes, your product people can try their websites on £20 phones from Tesco. They can ask to sit in on user tests with minority groups. Extending your knowledge like this is trivial, but rarely done.
You're not a good and modern engineer who knows his craft if you aren't defaulting to react and tailwind.
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
Having been building websites since the mid 90's, I laugh at terms like "HTML-first website"
It's like chai tea.
explain?
> Chai, a word for tea in numerous languages
https://en.wikipedia.org/wiki/Chai
Reminds me of “pre-jit”
I’m sorry I can’t hear you over the Flash animation splash pages I was forced to sit through before being able to look up hours of operation.
I did some work for a company that spent nearly a grand on a Flash animation for their title page of a red bouncing ball that would bounce from right to left along the letters of the word "Yipee" (yeah totally not ripping off Yahoo! were they?) until it landed in the crook of the Y, where it would spread down the middle - the finished logo had the Y made out of blue, yellow, and red stripes.
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.
Same, and it has certainly made me realize that I am now officially entering my "old man yelling at cloud" phase of my life, and I'm "only" 38!
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.
Go is so awesome for server apps. I should have discovered it much sooner. It somehow sits in the exact optimal point having no bullshit overhead like C, yet also getting out of your way so you can focus on the business logic like Java (not Rust).
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 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.
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.
Maybe I'm missing something but aren't PWAs pretty dead-simple on both iOS and Android? Maybe it's the "reliable storage" part that's the gap?
>One of my sites is image heavy and serves 10 TB of traffic per month
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?
> Most of my apps are now simply HTMX + Go + SQLite.
Would like to hear about your Go stack for building htmx apps.
> 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.
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...
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
I disagree. An HTML website which uses links, forms, buttons and inputs will by default:
* 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.
I find it's way easier to build crappy React apps than an HTML-first approach.
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.
True. Crappy developers will build crappy websites irrespective of the tech.
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.
At least it'll be a fast and crappy website.
It's definitely possible to make slow server-rendered website. Most of the slow client-side apps are slow because they're waiting on slow network requests.
(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)
but the host (the company) will need to pay the price in the form of server equipment. Not the user as is the case with client side rendering. If server side rendering becomes slow it will affect all users regardless of their hardware or connection, prompting earlier response from management and devteams.
The cost difference between client-side and server-side rendering is pretty non-existent these days.
yeah, I love when shit loads immediately, so I'm not wasting seconds of my life just to see shit.
You can do a bad job with any tool but you cannot do a good job with any tool.
This is patently untrue, give a craftsman terrible tools, and they'll still produce a decent end result. That said, defaults matter, and astro is going to be significantly more friendly out-of-the-box to low-end clients
true, but where can I find the smallest functional react website where react is needed...?
Not really, no. Astro requires you to opt a component in to client-side rendering, React (with its server components etc) require you to opt out. Defaults matter in scenarios like this and I'd bet the average developer of crappy websites would have a much faster site with Astro than React for that reason alone.
with this logic, why discuss any technology?
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've always liked basic HTML pages where one can upload a document without having to restart the entire application. That's a great practice you have there with general forms. With each session ID, it can cross reference a page in a multi page application with that session ID, so that the user can maybe type it in if necessary, but it should be able to determine that with enough information, like IP address, upload date, browser, OS and so on. But the most accurate session would be within the browser so that the cookies for a single application aren't mixed up with another applicant, like a relative, who might be using the Playstation Portable.
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?
> Arch Linux
You've only got yourself to blame, there.
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.
Can anyone confirm if Web Components work in the old psp web browser?
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.
> […] it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”
Is it more work?
> 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.
That hit me, too, specifically thinking about my current gas/electricity provider. I have not heard one single piece of positive feedback from the public, and there's only ever problems. I feel like that's a pretty universal experience here. Even outside the scope of websites, it holds so very true.
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.
I moved to the UK in 2016.
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...
> 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.
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.
The full context of that quote makes it clear that it's meant more as a wry joke:
> 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.)
The opposite is why I'd never be a good web developer. I grew up messing around with PHP and if I spent the time to learn the modern stack, I'd constantly be thinking it's stupid.
I can relate to that.
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 think the author is suggesting that Remix was the inspiration for the renaissance, not that it's necessarily the most popular method for doing so.
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.
Opt-in = action is required to opt in = off by default.
Remix has been nonetheless influential in the space, in the same way preact and signals have been.
I think Remix brought back interest in Form Actions and other meta frameworks took inspiration from that.
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.
I read the article in the source code mode and thought it was intentional until I came back to the comments
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?
Yes
I wish more people take this approach, specially public services.
in the bio ... "has over twenty years of experience building highly accessible and usable web applications"
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 ...
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.
esm.ah let's you include "complicated" JS that isn't usually found in CDNs.
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`
I understand people need to make arguments for things they like but provide more please.
What were some of the downsides? Illuminating the tradeoffs would elevate this post from good to great.
Interesting they went with Astro.Makes sense for a form-heavy site. No JS until you need it,and it handles page transitions cleanly.
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.
Users visited the site and couldn't even begin the form, nor get seen as a visitor, due to javascript metrics and rendering failing.
I think that's even more significant, since it's measuring people who cared enough to click the form in the first place, which is juicier than just page loads.
may be he meant, doubled our users who actually submitted the form
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.
If you're a "React person", as the article puts it, friendly reminder that you can render components to HTML and serve that to the user.
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 took a very bold decision and built a new version of the site using Astro"
Maybe this is heretical in today's AI hype climate but...weirdly due to the rise of AI, then AI-slop polluting everything, a lot of old fundamentals are coming back. Clear, well-structured, descriptive content on a well-built page has a better shot of being picked up for SEO/AEO/whatever which are the same best practices from 2005. A lot of these tips and tricks and hacks just aren't going to move the needle as much anymore imo.
SEO and accessibility laws have always been the most effective way to convince someone to build clean, well-structured webpages. Guess what, both are measures of how easy it is for a machine to extract content from your pages. AI is just the latest machine that wants to slurp up your soup of tags.
Totally agree, gov pages should be widely accessible. Also gov services should NEVER mandate internet access. There should always be a way for tech-illiterate people to ask someone, and fill their forms
It shows just how far gone webshit is when the obvious must be stated time and time again
It'll be replaced by a new react app within a few hires lol
> In the most recent, contractors in another country had built a React app. The React app was online for 3 days before being pulled because of customer complaints. I took one look at it and told my boss “we can’t take ownership of this.” It was a mess of loading spinners and global javascript states. It was not accessible. Image upload was a vital part of the form, and it attempted to store images (along with all other form data) in localstorage which has a 5mb limit!
> contractors in another country
Sorry to spoil but the problem was not react. The problem was clearly this excerpt because we all know which country it was.
No we don't. There are lots of countries with software outsourcing industries, and contractors in any country can be good or bad. Would you rather have a top IIT graduate, or someone who took a year of programming classes at a community college in Fresno?
Considering the rampant fraud in a certain country's university system, give me local CC graduates.
As opposed to the US, where nobody ever cheats in school?
Idk, the general javascript spinner situation is beyond normalized at this point. I think mainly driven by React and other large/overkill JS frameworks. I avoid JS/TS heavy stuff so I don't really know but that's largely the impression I get. The whole thing reminds me of dialup era internet were we all were watching progressive JPGs load on a slow connection despite the fact I have fiber. I can't believe anyone is Ok with that UX, I don't see how any framework choice justifies introducing that type of behavior.
> The problem was clearly this excerpt because we all know which country it was.
Oh yeah? Which?