Building an HTML-first site doubled our users overnight

https://mohkohn.co.uk/writing/html-first/

by edent • 1 month ago

1278 562 1 month ago

mohkohn.co.uk

freedomben• 1 month ago

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.

simonw• 1 month ago

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

someonebaggy2• 1 month ago

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.

afavour3• 1 month ago

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.

arowthway• 1 month ago

Opt-in = action is required to opt in = off by default.

pspeter3• 1 month ago

I think Remix brought back interest in Form Actions and other meta frameworks took inspiration from that.

epolanski2• 1 month ago

Remix has been nonetheless influential in the space, in the same way preact and signals have been.

entropichorse• 1 month ago

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

afavour3• 1 month ago

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.

whstl4• 1 month ago

Small correction: it's other frameworks that require you to opt-out, most notably Next.js. Although I've been seeing so many people confusing Next.js with React lately...

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.

hyperhello2• 1 month ago

You can do a bad job with any tool but you cannot do a good job with any tool.

swiftcoder3• 1 month ago

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

someonebaggy2• 1 month ago

At least it'll be a fast and crappy website.

cyanydeez• 1 month ago

yeah, I love when shit loads immediately, so I'm not wasting seconds of my life just to see shit.

nicoburns2• 1 month ago

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)

adjejmxbdjdn• 1 month ago

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.

TSiege3• 1 month ago

with this logic, why discuss any technology?

malteg2• 1 month ago

true, but where can I find the smallest functional react website where react is needed...?

wmanley2• 1 month ago

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.

mike_ivanov• 1 month ago

"What one man built, another will always find a way to break"

manuhabitela• 1 month ago

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.

elxr2• 1 month ago

I agree. Server-rendered React can also send down 100% HTML apps.

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

tootie• 1 month ago

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.

myself248• 1 month ago

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.

robofanatic• 1 month ago

may be he meant, doubled our users who actually submitted the form

yCombLinks• 1 month ago

Users visited the site and couldn't even begin the form, nor get seen as a visitor, due to javascript metrics and rendering failing.

yawaramin11• 1 month ago

Doubling conversions, in digital marketing-speak. Marketing firms probably give out fat bonuses for this kind of result.

ungreased0675• 1 month ago

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.

ai_slop_hater• 1 month ago

They don't know what a megabyte is

jorisw3• 1 month ago

They feel the slowness of the page load

alok-g7• 1 month ago

+1.

I have been asked by someone in late 40s why uploading a video takes a lot longer than uploading a photo.

They are not dumb people. They just do not know.

The onus is on the engineers to design for them.

pier253• 1 month ago

The consequences of MBs of JavaScript can be perceived by anyone in terms of performance and mobile data consumption.

HumblyTossed• 1 month ago

"If our users can't afford the bits, we don't need them!"

epolanski2• 1 month ago

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

pier253• 1 month ago

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.

wmanley2• 1 month ago

The counterargument: In Defence of the Single Page Application:

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

__natty__2• 1 month ago

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.

TSiege3• 1 month ago

it's a sarcasm loader

elmigranto• 1 month ago

My guess it’s a joke.

frisia• 1 month ago

I think that's the joke :) all other articles load fine instantly, just this one that has a spinner

TSiege3• 1 month ago

lol this got me

pegasus• 1 month ago

All I got is a "loading" animation. Gave up after 10 seconds. So, not a counterargument, but a confirmation of the article's thesis.

tele_ski• 1 month ago

It's a joke/sarcasm

sorenjan• 1 month ago

Sufficiently advanced parody is indistinguishable from reality.

bryanrasmussen2• 1 month ago

https://medium.com/luminasticity/on-the-triumph-of-satire-fa...

"Satire isn’t dead.

Satire won.

This is what it looks like from inside, looking out. "

Izkata• 1 month ago

Ages ago when writing.com was first modernizing its site, they started by hiding story content to display a spinner, waiting a second or two, then re-displaying the content. It was on the page the whole time, they just made it look like it was loading in the background.

650REDHAIR• 1 month ago

I got wooshed.

Nice work!

sodapopcan• 1 month ago

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

pkphilip• 1 month ago

I have to say that I hate SPAs. It is often a far worse user experience than the vanilla multi-page websites.

bryanrasmussen2• 1 month ago

Like most defenses of Single Page Applications it managed to make me angry, at least at first.

dang• 1 month ago

Discussed at the time:

In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - May 2022 (32 comments)

brianwmunz• 1 month ago

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.

kijin• 1 month ago

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.

jrochkind1• 1 month ago

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.

Quarrel• 1 month ago

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

Uncle_Brumpus• 1 month ago

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.

t1234s• 1 month ago

Having been building websites since the mid 90's, I laugh at terms like "HTML-first website"

hamburglar2• 1 month ago

Reminds me of “pre-jit”

re-thc3• 1 month ago

ie "aot"?

thewebguyd• 1 month ago

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!

naravara• 1 month ago

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.

ErroneousBosh3• 1 month ago

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.

danudey• 1 month ago

As a teenager I remember going to a website for... a city, I think? And their 'sidebar' was a Java applet that did nothing but provide links for you to click with on-hover effects. The page used frames; the applet was in the left-side frame and the content was in the main frame on the right.

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.

kkkqkqkqkqlqlql• 1 month ago

It's like chai tea.

nonethewiser3• 1 month ago

explain?

calvinmorrison• 1 month ago

ATM Machine

wpollock• 1 month ago

The Sahara desert. It's not only repetitive but it repeats itself too as well.

These gems are brought to you by the department of redundancy department.

jppope• 1 month ago

  - shrimp scampi
  - Old Adage
  - chai tea
  - Naan Bread
  - Rio Grande River
  - Lake Tahoe
  - PIN/ VIN number
  - ATM machine
  - GPS system
  - Panini sandwich

rjsw2• 1 month ago

With au jus.

addandsubtract• 1 month ago

I thought this article was missing a (1999) in the title.

melon_tsui• 1 month ago

Interesting they went with Astro.Makes sense for a form-heavy site. No JS until you need it,and it handles page transitions cleanly.

masa-kozu• 1 month ago

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.

faangguyindia3• 1 month ago

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.

miroljub• 1 month ago

Most of my apps are now simply HTMX + Go + SQLite.

Would like to hear about your Go stack for building htmx apps.

creesch4• 1 month ago

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.

paytonjjones• 1 month ago

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?

rjsw2• 1 month ago

You can still buy KaiOS phones, I have one.

ChiperSoft• 1 month ago

Alternatively, you could try to keep HP from killing the TouchPad

inigyou8• 1 month ago

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. It feels like it's specialized for that and not trying to be a jack of all trades.

shit_game• 1 month ago

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?

grebc• 1 month ago

Lots of legitimate businesses that deal in maintenance have ridiculous amounts of image data.

I have a civil engineering firm as a client, they take video & photo’s of roads they help project manage the maintenance on.

Small towns of 10000 can have ridiculously big road networks in Australia. And you take a photo every 10m, likely more but you only care about every 10m. It adds up, quick.

I’m only now investigating a web version of the app I wrote them because I think origin file system will work for them but I would never consider serving their 200TB+ of their imagery as a website.

pragma_x2• 1 month ago

Since you're using HTMX, I have to ask: do you have any tips or idioms for composing complex forms and UI without things getting out of hand? I love the approach, but I'm having a bad time figuring out where the ideal balance is between too few or too many HTMX-replaced areas in a page. Thanks.

pphysch3• 1 month ago

My #1 advice is not creating separate server endpoints for every HTMX fragment, unless you are 1000% sure that endpoint will be used in multiple different pages.

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.

shakna4• 1 month ago

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.

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

faangguyindia3• 1 month ago

Looks like "Section 2.8 to give Cloudflare the means to preserve the original intent of the CDN: limiting use of the CDN to webpages." is gone.

https://blog.cloudflare.com/updated-tos/

interesting, it seems now i can host stuff directly on r2 and put CF in front and serve images, video and other files!

inigyou8• 1 month ago

10TB is nothing these days. All Hetzner virtual servers in Europe have 20TB/month traffic included (excess less than $2/TB) and all their dedicated servers have unlimited fair use (which is probably about 200TB/month averaged over many months).

bearjaws2• 1 month ago

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.

Because there isn't a 30% walled garden you can create with that.

jimbokun4• 1 month ago

Where do you store the SQLite database files? What is your strategy for partitioning your data into SQLite files? One per user or…?

mrweasel2• 1 month ago

Where do you store the SQLite database files?

What? On the server, where else would you put it?

jimbokun4• 1 month ago

Developing webapps only for iPhone was Jobs original strategy. Only changed when developers complained.

wild_egg2• 1 month ago

On the mobile point, there is https://github.com/instawork/hyperview

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.

mpweiher• 1 month ago

Most of my apps are now simply HTMX + Go + SQLite.

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.

sethops1• 1 month ago

Are you me? I've been on a tear building stuff with HTMX + Go + SQLite. It's like the trifecta of boring technology that jives with me. Stuff gets deployed to a colo server using a generic bash script.

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.

https://github.com/cattlecloud/webtools

https://github.com/cattlecloud/litesql

eestrada2• 1 month ago

Can't vouch for it's effectiveness, but Hotwire Native might meet the needs for mobile paired with plain HTML. Despite the name, it doesn't seem that using Hotwire for the web UI is necessary to use Hotwire Native. I could be wrong about that though.

https://native.hotwired.dev/

mplewis• 1 month ago

Hotwire doesn't work anywhere you can't guarantee a high-quality low-latency connection. Every UI interaction in Hotwire includes that round trip.

aturek2• 1 month ago

I've learned about several frameworks that are system language + web frontend. The general approach is, ship a small binary compiled for the specific platform, and use the platform's native browser (and whatever html frontend tech you like) for frontend. The whole binary can be 1mb or less.

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.

tartieret• 1 month ago

have you considered Capacitor? it works pretty well for cross platform web development

AWTom• 1 month ago

Cloudflare will not let you run an image heavy site on its own

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.

faangguyindia3• 1 month ago

yes, you are right i didn't see their update: https://blog.cloudflare.com/updated-tos/

lenkite• 1 month ago

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

nobleach2• 1 month ago

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.

Natfan• 1 month ago

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`

nobleach2• 1 month ago

Yeah in this case, I needed to pop up a <dialog /> and take some form info, persist it via POST and then show the result of a "used" card/token. So there just wasn't a lot of need for libraries. I'm from the VERY old school so I do recall the fresh hell of including many deps via script tags (pre-Bower!)

qsort• 1 month ago

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.

malteg2• 1 month ago

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

oulipo23• 1 month ago

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

yawaramin11• 1 month ago

FTA: 'To apply for their services, customers could either use an old ASP form on the website, or follow a manual process.'

alok-g7• 1 month ago

> There should always be a way for tech-illiterate people to ask someone, and fill their forms

Isn't that more open to fraud and abuse though by the "someone" whether that is a gov employee or otherwise.

oulipo23• 1 month ago

If it's a government employee (as it should), it shouldn't be open to fraud and abuse, no. There should be a trail of what happened

dirkc2• 1 month ago

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?

kcrwfrd_• 1 month ago

Yes

dirkc2• 1 month ago

Guess I should have stated the questions as "what makes Astro worth while to try out?" :)

sjtgraham• 1 month ago

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.

initramfs3• 1 month ago

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.

devnull3• 1 month ago

I am actually impressed by the gov.uk websites. Its minimal and just about right for its purpose.

May I ask what tech is used for mobile apps? I am guessing not a full mobile app but it uses webview.

petepete• 1 month ago

It's still happening.

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.

https://govuk-form-builder.x-govuk.org/

https://govuk-components.x-govuk.org/

dotsp• 1 month ago

The MoJ have moved on to using Forge now. https://www.npmjs.com/package/@ministryofjustice/hmpps-forge

Steve16384• 1 month ago

Great work. The gov.uk site is a beacon of light on the web.

oybng• 1 month ago

It shows just how far gone webshit is when the obvious must be stated time and time again

skylovescoffee• 1 month ago

"I took a very bold decision and built a new version of the site using Astro"

tgtweak• 1 month ago

It'll be replaced by a new react app within a few hires lol

theandrewbailey• 1 month ago

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.

Zak2• 1 month ago

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.

simonmysun2• 1 month ago

I read the article in the source code mode and thought it was intentional until I came back to the comments

P.S. your solution seems to have disabled the custom font instead of fixing it

Zak2• 1 month ago

You're right. Seems like it fails when the font is correctly selected. Another machine running Firefox on Linux didn't have a problem.

NopIdoN• 1 month ago

[…] it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”

Is it more work?

0xpgm• 1 month ago

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.

dlcarrier7• 1 month ago

I keep hearing the term "dead internet theory" getting thrown around, and at first thought it was referring to web pages that don't work, not high rates of bot-generated content.

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.

graypegg• 1 month ago

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/

shlewis• 1 month ago

In the mean time, HTMX is pretty much that with much more. Definitely recommend.

drchaim• 1 month ago

I wish more people take this approach, specially public services.

joelanman• 1 month ago

UK government services guidance is to use progressive enhancement

https://www.gov.uk/service-manual/technology/using-progressi...

IFC_LLC• 1 month ago

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.

aidanbeck2• 1 month ago

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.

genewitch7• 1 month ago

just use firefox with an adblocker like adnauseam and a fairly decent chunk of the internet stops working, including chase.com and several other massive corp 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.

nunez2• 1 month ago

Chase works with ad blockers, though.

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

natbobc2• 1 month ago

And that is what pixel tracking is for. :)

kristianp4• 1 month ago

What's wrong with web server logs? That would give you the number of visitors, if not the pageviews on an SPA.

kristianp4• 1 month ago

The PSP has 32MB of RAM plus 4MB of embedded RAM, upgraded to 64MB of RAM in later models, the browser also is limited to only a subset of that. I wonder how old the anecdote is? It's hard to imagine any websites now working on that. It does have javascript, but a version shipped with Netfront browser from 2011 or so. https://en.wikipedia.org/wiki/PlayStation_Portable#Web_brows...

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.

dlcarrier7• 1 month ago

I used PSP browser a lot in the mate 2000's, and don't remember having much trouble. It could even display pages that, at the time, ware pretty bloated, like the Flash-based Homestar Runner cartoons.

simonmysun2• 1 month ago

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?

ErroneousBosh3• 1 month ago

Arch Linux

You've only got yourself to blame, there.

nilirl• 1 month ago

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.

aidanbeck2• 1 month ago

The downside mentioned by the author's replacement in the article is the unfortunate explanation for why this is rare in practice.

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

hiccuphippo• 1 month ago

Can anyone confirm if Web Components work in the old psp web browser?

phyzome2• 1 month ago

The point is that they don't have to! That's what progressive enhancement means.

initramfs3• 1 month ago

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

sethammons2• 1 month ago

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.

KolmogorovComp• 1 month ago

Certainly not the b52, which arrived after the end of WWII…

sethammons2• 1 month ago

whoops, yeah. Likely b17. My brain subbed "bomber" for the more prominent bomber in my head.

ecshafer• 1 month ago

I am not familiar with this astro framework they used. But having built some sites using Pure HTML/JS back in the day, React, Angular, Vue, Rails ERB, Rails Hotwire, and HTMX. I think HTML first websites are absolutely the way to go. Rails Hotwire with View Components makes rails sites super fast, faster to develop and easy to re-use components. HTMX more generally, but Ive used it with Spring boot and Thymeleaf. I really don't want to go back to SPAs. Development time is less and the website performance is better, and I haven't really seen any regressions in capability. With HTMX and some url parameters, I can make a pure HTML site that seems like a Single Page Application but without the excessive loading times.

xavortm• 1 month ago

I first tested Astro on my site and never went back. Now every new project defaults to Astro and I have to have a reason not to use it. So far no reasons. It's simple, fast and it kinda fits my desire to keep things minimal. For example, yes, page content matters, but all but one page on my site is under 10kb, most hovering in the 3-4kb range (100% of the downloadable content)

Lio• 1 month ago

Yep Hotwire and Hotwire Native are amazingly useful tech.

ElijahLynn• 1 month ago

Beautiful story!

bastawhiz• 1 month ago

I'm not convinced from the article that HTML-first was the thing that fixed the problem. What fixed the problem was 1) the person building it knew what they were doing and 2) it had design constraints from the get-go to be user-friendly. You can do that with React. It's arguable whether it's easier or better, but you can get there regardless of the approach you use.

yawaramin11• 1 month ago

1. Presumably the team that made the previous app also thought they knew what they were doing. Presumably they were not hired on the assumption that they couldn't make a good app.

2. The design constraints had always existed, the previous app just failed to meet them.

gbacon• 1 month ago

1a. They may have thought they knew what they were doing, but their work product shows otherwise.

1b. They may have thought they knew what they were doing and spoke confidently enough to convince whoever was doing the acquisition, likely non-technical, of the same, but the bad hire and the bad hire’s work product shows that neither was the case.

2. Ideas merely exist. To be constraints, they must be enforced.

ernsheong• 1 month ago

Everyone reinventing what Rails has been saying all along...

etaioinshrdlu• 1 month ago

It's true. Also, if you despise bloat, you may like my JS-free LLM site: https://ch.at/

Dwedit• 1 month ago

There is one hard wall that stops very old clients from connecting: Not supporting a new enough version of TLS. TLS 1.2 is from 2008, and TLS 1.3 is from 2018. Web browsers older than 2008 can't connect to modern websites since TLS 1.0 and 1.1 were deprecated from web servers in 2021.

Telaneo7• 1 month ago

I still think it's worth it to provide connections over plain HTTP for this reason. It probably doesn't apply to many people, and you shouldn't allow anything really important to happen over plain HTTP (logins, payment), but normal viewing should still be possible.

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.

alok-g7• 1 month ago

Having HTTPS as mandatory it more mistake-proof.

zzo38computer3• 1 month ago

I agree; you should allow non-TLS connections as well as TLS. (At least, access that does not require authentication should not require TLS, but should still allow it if that is what the client wants.)

If you are concerned about accidental login or API keys without TLS, then you can consider supporting mutual TLS, which improves security (and flexibility) in other ways as well. (You do not necessarily, have to require mutual TLS, in case someone prefers to use a username/password login, or 2FA or something else like that instead.) (In the case of login forms, you can have the links to the login forms to always use HTTPS, in order to avoid the problem.)

bigstrat20033• 1 month ago

The push to have everything be served over HTTPS is absolutely insane. Very few things actually need to be served securely. But sadly, browser makers don't give a damn about actual benefits for the users, but rather shove their out of touch ideas about what the Web should be down everyone's throats.

Mr_Minderbinder• 1 month ago

...browsers older than 2008 can't connect…

TLS 1.2, the standard, may be from 2008 but support for it in browsers did not start to appear until around 2013.

callumprentice• 1 month ago

Excellent article but I am always torn when I read inspirational articles like this - it makes perfect sense to me and I love the idea of simple, non-nonsense sites that work well, load quickly and don't rely on the latest browsers to function.

Then I start to wonder if that's just because I'm not smart enough to understand React or whatever the fancy technology of the day is.

Feels like I have a hard understanding threshold that cannot be breached - give me a simple editor like Sublime and ask me to make a web page - even with JavaScript - and it's my happy place. Give me VSCode or Zed, Claude/Copilot/ChatGPT plugins everywhere, React tutorials and my brain goes to mush.

thesuitonym3• 1 month ago

If it makes you feel any better, the people using the fancy frameworks and whatnot usually aren't smart enough to understand them either.

LNSY5• 1 month ago

I love the web. I hate what the React cretins have done to it.

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.

elxr2• 1 month ago

React has helped folks like vercel/convex/cloudflare to build fantastic dashboards. There's just as many examples of well done React as there are the opposite.

I generally prefer solidJS nowadays, but the react ecosystem has enabled lots of amazing user experiences (and developer experiences too if you don't fall into the trap of overcomplexity).

zem• 1 month ago

you might enjoy this post on complexity and why it is bad: https://tengstrand.github.io/blog/2019-09-14-the-origin-of-c...

keeping things simple is not a bad thing, and often requires you to be smart enough not to overcomplicate them.

motoboi5• 1 month ago

Old people. They exist.

Not even that old. 60 year people can't user your fancy site because then don't have an internal model of how a computer works.

You know that when pressing a button a hidden engine runs in the backend (or something runs in the backend). You expect an answer and if the expectation do not match the result, the model in your mind creates an hypothesis about what maybe happened and iterate from there. Maybe you should have clicked something before? Maybe you should mark some form checkbox?

Old people don't have that because they didn't grow up with computers.

What is on the screen is what they see. I clicked next and nothing happens. Well... the site is broken.

You known when you plug your refrigerator and nothing happens and instead of reflecting on the possible blown out resistor that you can bypass with a small wire you understand that your only relationship with the refrigerator is plug and unplug or call for help? That is an old person using your site. They won't fight against it. They'll give up immediately.

pmontra2• 1 month ago

Giving up is a wise choice: there are so many other sites to interact with. On the other side they have only one refrigerator.

dghlsakjg• 1 month ago

Next time I have trouble checking in on an airline site I’ll remember that there are so many other sites to interact with that whatever I was trying to do probably doesn’t matter.

I wouldn’t sweat the broken fridge either though, there’s so many other electrical appliances in the house to use.

natbobc2• 1 month ago

Is entirely context dependent. I can agree in some scenarios but when it’s a utility or gov site that I can’t really avoid it’s less straightforward.

Telaneo7• 1 month ago

I wish I could convince my grandmother of this.

"Why did the bank change the layout? I want the old one back!" - Don't like it? Change bank then. That's what I did.

I get that changing to another bank is a big unknown, but it's probably still worth it to show your displeasure. Plus her bank are morons when it comes to several other things.

initramfs3• 1 month ago

There's a great book that explains how abstract computer systems have become from the machinery: https://dabacon.org/caelifera/2017/02/05/book-overcomplicate...

breakwaterlabs• 1 month ago

Old people don't have that because they

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.

isityettime• 1 month ago

Automation generally goes along with a transition to more "self-service" approaches that require the user to model internal states and workflows of whatever they're dealing with.

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.

ryukoposting• 1 month ago

As a firmware engineer, my philosophy is this: if I'm doing my job properly, the user should never even know I exist.

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.

cosmic_cheese• 1 month ago

Usability was thrown to the wolves in favor of more readily available designers from non-UI backgrounds, brand identity (“UI as branding”), and pretty screenshots for slideshows and marketing.

The pendulum is overdue for swinging back the other way, but I don’t know who or what has both the capability and will to give it the push needed to send it on its way back.

SkeuomorphicBee• 1 month ago

When did the industry put the onus on the user to understand how the computer works?

Just after the turn of the century, that was when there was a big shift in the industry to move all user interface design work to artists, and away from original user interface specialists. The whole profession of user interface designer (one who understood "form follows function") ceased to exist in the early 2000s, as all work was assigned to graphic designers (who only understand aesthetics).

This movement can be seen clearly in the evolution of widget toolkits for desktop applications, which peaked in usability in the late-90s/early-2000s, and have been losing usability while getting prettier with every iteration since.

Hard_Space2• 1 month ago

60 year people can't user your fancy site because then don't have an internal model of how a computer works.

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.

rewgs• 1 month ago

GP clearly isn’t talking about 60 year olds who were full stack devs and get on Hacker News.

dijksterhuis• 1 month ago

practicing and writing about machine learning ... full stack developer ... digital revolution.

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

asdfasvea• 1 month ago

Dude, you know what he meant. Don't be the internet pedant. No need to be the protector of your class, especially one so inconsequential as "literal 60 year olds".

Instead of "old person" he put a number on it. (Cue the people who need to cut me down because I used a male pronoun for an unknown poster)

motoboi5• 1 month ago

Some people know how to fix a fridge.

StableAlkyne• 1 month ago

I would argue it's not even old people. Most people do not have any understanding of what's going on when you click a button. Website either acts as expected, or it doesn't "work"

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.

black_puppydog• 1 month ago

Yep, I changed town a few years ago and my new social circles are mostly like that.

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

andrewflnr• 1 month ago

Yeah, it's really, really not an age issue. If there's an age distinction, it's the range of people who were brought up on computers before the UI was really polished, but even then it's not consistent, and they may not have deep understanding. Kids brought up on iPads, and who aren't forced to learn by their interests or educators, have no clue.

celsoazevedo• 1 month ago

And now also a lot of young people. They grew up with iPhones and many think that "Wi-Fi" = "internet".

Keep it simple and light. HTML+CSS first, JS to expand functionality. Don't re-invent the wheel.

dotBen• 1 month ago

"Old people don't have that because they didn't grow up with computers."

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 :/ )

antasvara3• 1 month ago

I think the relationship people are seeing is "80 year old can't fill out my form, must be because they can't use a computer." But international surveys like PIAAC [0] indicate that adaptive problem solving is the real problem. 30 percent of adults are at or below Level 1; I've copied and pasted what that level represents below:

Adults at this level are able to understand simple problems and develop and implement solutions to solve them. Problems contain a limited number of elements and little to no irrelevant information. Solutions at this level are simple and consist of a limited number of steps. Problems are embedded in a context that includes one or two sources of information and presents a single, explicitly defined goal.

This test is administered on a tablet, so I think scores can be interpreted as a sort of combo of computer use and problem solving.

A full 40% of adults from 55-64 are at that level or lower. Wikipedia thinks that a novel online form would be a Level 2 task, provided it involves navigating across more than 1 page. Based on that framework and assuming your dad can use the sort function in his email, he represents a top 20th percentile adult for the 55-64 age group. It's probably even higher considering his age as the trend is towards older groups having a rougher time with the survey.

I also think it's ageist to assume that older people can't use a computer. But assessments like this indicate that a full quarter of the US regardless of age would have trouble with some of the basic tasks we associate with computer use. So designers should consider their intended audience when deciding what's simple or not simple enough.

[0] https://nces.ed.gov/surveys/piaac/2023/national_results.asp

bearjaws2• 1 month ago

You are just describing a broken site?

I've seen static sites with these same problems, 404 was invented decades before React...

foxglacier• 1 month ago

I think he means the submit button is disabled because some field failed validation. It might have turned red or have a message appeared next to it - and it might be scrolled off the screen so you have no idea. Or just the common "I have read and agree to ..." checkbox you didn't tick. Possibly because you didn't read the T&C or because it won't let you tick it until you click the link to the T&C. Nobody else read them either but they've learned through trial and error that when the checkbox doesn't work, you have to click the link to fool the computer into thinking you read it.

motoboi5• 1 month ago

Yeah. And reflect on the fact that you know that a 404 error is not a form error. Old people won't. Heck then won't understand that a chrome error page is not your site.

pugworthy• 1 month ago

Old people don't have that because they didn't grow up with computers.

You realize that someone who was 18 when the Mac was first released would be 60 now?

reaperducer2• 1 month ago

Old people. They exist.

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.

antasvara3• 1 month ago

I'm going to link my favorite survey [0] to illustrate this point. Its called the PIAAC, and it's a internationally standardized assessment of adult skills in literacy, numeracy, and problem solving.

28% of the US is at Level 1 or below. That level roughly corresponds to reading a simple text and being able to answer a question about it that requires limited inference (i.e. if the question is "what color are pigs," the answer would be in the text as "pigs are pink in color.")

[0] https://nces.ed.gov/surveys/piaac/2023/national_results.asp

frayed0654• 1 month ago

This describes all non-technical users, not just "old people."

motoboi5• 1 month ago

Yes, but even non-technical users have a different relationship that formed over the young (neural plasticity) days.

"I click the <next> button on this form, nothing happens. Given that I have an internalized notion of forms as a multistep flow, maybe it couldn't advance because something is missing on the current step? Maybe it will give me those messages below or above the form? Maybe some read message somewhere? I'll search for those and try again"

"I click the <next> button on this form, nothing happens. Not sure what would happen next. Maybe the thing will tell me? I can't see no dialogs, no messages, no error screen. Nothing changed. Maybe if I press it again? Nothing? Hum, maybe is disconnected from the network? It's the wifi again? Maybe if I power cycle the wifi router it will reconnect? I click next again now I get a clear error message: no internet connection. I suppose my internet is broken again. Will call my tech-savvy friend."

xdennis• 1 month ago

60 year people can't user your fancy site because then don't have an internal model of how a computer works.

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 tried a lot, but every time he received an email saying the address is invalid. After a lot of frustration he asked me for help (he's not the kind to ask for help).

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

Telaneo7• 1 month ago

Wait til he learns that email addresses can contain spaces and line breaks. They just have to be quoted.

"why

ohgodwhy"@example.com is a valid email address (although I suspect most providers will reject it).

Try having that make sense without all the prerequisite knowledge the average computer toucher has. "Well you see, [...]"

onion2k2• 1 month ago

This isn't "We replaced a React app with an HTML form and performance improved." It's "We replaced a bad web page with a good web page and performance improved."

Attributing this to the technology driving the browser experience is silly. You can make a brilliant user experience with React. You can make a terrible website with plain HTML.

The improvement comes from the change design, not tech.

iammrpayments• 1 month ago

Of course, is just what with React is 100x harder, and when you fail the fans will blame you instead of the technology.

lucumo2• 1 month ago

The standard answer to that is that some technologies make one harder than the other. That's kind of true from first principles, but it requires making the case that e.g. React is actually harder to make good than a plain HTML page.

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.

andersmurphy2• 1 month ago

Is it slow though? Like in practice? This demo [1] using Datastar (a streaming HTML framework) every action including scrolling roundtrips to the server. Even the checkboxes changing colour is a roundtrip.

https://checkboxes.andersmurphy.com

PebblesRox• 1 month ago

I don’t like multi-page forms when I’m not able to see at a glance all the info needed to fill out the form. Though I guess if my progress is durably saved that makes it not so bad. The worst is when I fill out a bunch of stuff and then realize it’s asking for info I don’t have, and after I get the info I have to fill everything out again from scratch!

Aurornis• 1 month ago

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.

jason_oster• 1 month ago

Plain old HTML with vanilla JS is not exactly a pit of success but React is much closer to a pit of despair. The former tends to be clunky but effective, while the latter requires a PhD in complexity avoidance to stand a chance.

JavaScript: The Good Parts by Douglas Crockford is a comically short book. React: The Good Parts would be shorter still.

dwb• 1 month ago

Totally wrong, re-read the article. React requires JavaScript, which the new page doesn’t. That’s a strict accessibility improvement. (And I’m not a React hater!)

ninalanyon• 1 month ago

The quote from Terence Eden almost made me cry. Actually the whole article did.

skybrian• 1 month ago

What do people like for form validation?

In this article he recommends the “validation-enhancer” library:

https://www.npmjs.com/package/validation-enhancer

I’ve also seen one called “formisch” that the author of valibot is working on:

https://github.com/open-circle/formisch

They’re both pretty new. Has anyone tried them?

kccqzy• 1 month ago

My biggest tip to reduce complexity of data validation if you are using React is to stop using React controlled components and switch to React uncontrolled components. They are an underused part of React. You usually don’t need React to handle every single keypress and every single character being entered by the user. In fact before React popularized it, it was unusual for form components to update on each key press; traditional desktop apps tend to validate when a field loses focus only, not on each key press. This has at least three benefits: (a) good for performance, (b) reduces unnecessary error UI when the user is in the middle of entering data, and (c) simplifies your own code by not having to deal with prefixes of valid input that’s not itself valid.

yawaramin11• 1 month ago

Also allows user scripts to interact with the forms, eg I can run a bookmarklet to fill out certain forms. With React controlled components all these changes are wiped out and reset with the state that React has in its app memory.

yawaramin11• 1 month ago

I actually like the built-in stuff and the Constraint Validation API. I wrote about using it with htmx: https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg

marticode• 1 month ago

I try to stick to plain HTML5 / Javascript validation. Trying to not reinvent the wheel and use what the browser already has built-in seems best.

danielrhodes• 1 month ago

I've tried this before and I think this constraint is something that has to be kept top of mind for a designer not just the engineer. Most designs these days assume a single page app and there are interaction patterns that make plain HTML not suitable. But if you incorporate this in from the start and stick with it, there's no reason you can't do this.

yawaramin11• 1 month ago

Also possible to just ignore interaction patterns that don't work well with HTML and replace them with ones that do.

regnull• 1 month ago

When we launched, the number of people completing the form doubled.

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

yawaramin11• 1 month ago

No, it's actually people. FTA: 'My client was a utility company, and they had a big problem. To apply for their services, customers could either use an old ASP form on the website...'

Ie customers of the utility company were completing the form, not random users from the internet.

replwoacause• 1 month ago

FTA? Free Trade Agreement?

OskarS• 1 month ago

As a non-web dev, I have a question about this part:

There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”

Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard <input> components for the form, have a submit button at the bottom. When I was making my own websites many years ago now, that's how it worked, and it wasn't that hard. Maybe it's reflecting my ignorance in this field, but doing fancy front-ends seems much harder to me.

simpaticoder3• 1 month ago

Simpler doesn't mean easier. Consider a chef who at their previous job started using a wood-burning stove. This is an objectively simpler tool than a gas or electric stove, yet it would be very difficult (even impossible, depending on local architecture and regulations) for a new kitchen to add one.

LNSY5• 1 month ago

I don't understand how having to pay 20 different vendors so hackers can run commands on your server barely impeded is somehow simpler.

squidbeak• 1 month ago

I'm interested to hear what architecture and regulations prevent the use of something that is foundational to web develpment and backwards compatible by design? Which also, by the way, comes with the advantage of not incinerating other parts of the restaurant (accessibility, user experience...), forcing expensive countermeasures or total rebuilds of the things destroyed every time you turn it on.

kstrauser• 1 month ago

90% of the SPAs I use could be Django/Rails/Flask apps with no noticeable difference, other than that they'd be many times more responsive on slower devices.

"Old" SSR apps are mature, not obsolete. It's ridiculous when they're not considered even when they'd be the right tool for the job. I wouldn't try to clone Google Docs in Django, but something like Linear could 100% be modeled as a CRUD app with new page loads on click without a substantial loss of functionality from the user's POV. Not to mention built-in, automatic support for pervasive "deep linking", aka "linking", because you access a URL's contents by GETting and rendering that URL is just how it works.

inigyou8• 1 month ago

How is that objectively simpler?

theflyinghorse• 1 month ago

It probably has to do with what technology people are used to. There has been a couple of generations of web developers who have only known javascript and its ecosystem for building webapps, and so anything other than pure javascript solution looks foreign.

LNSY5• 1 month ago

Because before there was AI Slop, there was React.

EGreg• 1 month ago

I think Facebook with their money and Vercel with their VC funding tried hard to push the React and then the Next.js everywhere. So it arrived in time for AIs to all train on it. And now it’s the one true way :)

But do we really need all that stuff? Build steps, bundling, tree shaking, all for what? And is it really simpler… hmm

atoav3• 1 month ago

By this point people don't appear to have any real clue how to write HTML anymore. Writing semantic HTML isn't significantly harder than say writing Markdown. You copy some HTMl skeleton and you literally just stack your elements into the body. I managed to do that as a 13 year old on MySpace without any deep instruction. Sure you have to close elements as well so the syntax is slightly harder than markdown, but that allows you to differenciate between for example <article>, <section> and <aside>.

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

autoexec• 1 month ago

Large websites resorted to PHP and server side includes to get headers and footers. Smaller websites resorted to frames and copy/paste. It wasn't perfect, but it also wasn't horrible or unusable either.

jmye2• 1 month ago

I think it was... SHTML? that allowed for server includes. My recollection from... 25ish years ago was that it was generally quite well supported and worked quite well (and was dead simple to implement). Not sure why, if that was the issue, the fix didn't quite catch on (but it's totally possible I'm mis-remembering the state of browser support).

p-t• 1 month ago

yeah editing all the footers and navigation parts in html is too annoying to me so i've resorted for my websites to just a back button to a page that has links to everything else lmao

WorldMaker2• 1 month ago

(and to this day: fails)

The `<template>` tag has gotten very close. Right now you still need JS (optionally wrapped as a Web Component) to load a `<template>` from an outside HTML file (at which case, yeah, it's so easy to just use a JS-based HTML renderer instead of a template today), but discussions are ongoing about closing that loop for simpler "JS-free Web Components".

I don't know when that will be accepted into the web platform, but it still feels more like a matter of time that it may happen eventually.

I've found at least some of my static page generation has moved to just dumbly appending `<template>` tags to the bottom of a page rather than use some other template language, so it feels like we are closer every day to finally having "HTML-native" simple part reuse.

8note5• 1 month ago

writing straight html and css sucked. building reddit css themes sucked

rhelmer• 1 month ago

I suspect they are both more familiar with client-side rendering, and also thinking of things being able to share components, reuse existing libraries, and so on. So re-implementing everything with vanilla HTML and forms feels like reinventing the wheel to a team used to an SPA component library, it's not that it's intrinsically harder, it's that they don't have the existing building blocks they'd normally reach for.

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.

chao-2• 1 month ago

Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done.

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.

concinds• 1 month ago

You are far too empathetic to them. They should not hold the jobs they have.

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

opem• 1 month ago

Don't you think they have a legit skill issue here and should they be better off upskilling themselves?

This is a direct effect of being a low barrier industry to enter. Most of the ppl among us are mostly here because of a good paycheck. And it SUCKS!

kleiba22• 1 month ago

In the olden days, people wouldn't take office jobs or factory job necessarily because they thought: "Yes! That's my passion! That's exactly what I've always wanted to do." Passion isn't your first and foremost thought when you have a family to feed.

A few decades ago, IT jobs were for the most part done only by people who were in it for the kick they got out of working with computers. They already hacked at their dad's computer in their early teens (or sometimes even younger), and just could just never let go. It was for people who loved it because it was a niche.

But today, IT is no longer that. It's the backbone of much of our society. And so the field no longer attracts just the die hard fans, the nerds. It attracts ordinary "career people", who just need to have a job to feed the family. Who turn the machine off after 8 hours. Who don't go on coding all through the evening on their hobby project. Who don't try out new tech just for the heck of it.

I think it's hard to understand if you belong to the first group, the nerds, that anyone working in the field isn't like you. Because they all used to be! But those days are gone. We live in the times of enshitification for a reason. If you have the hacker spirit, you don't enshitify because you simply can't. You know what is the right way to do it. Sometimes that's a React app but sometimes it's just an HTML page.

You're not just in it for the money. You care. Not necessarily for the end user, although that would be nice. You care for the tech. And when - like in this article - both come together, sweet things can happen.

reaperducer2• 1 month ago

A few of them would outright not know how to do anything else.

It's like how a lot of people these days reach for an electric drill/driver for even the most simple projects like tightening a screw. It never occurs to them to use a screwdriver, or even a butter knife.

indigodaddy• 1 month ago

Kinda sorta analogous to the cloud engineers who can standup complex monstrosities in AWS-land, but don’t know the first thing about how to troubleshoot say a connectivity or simple problem where they have to ssh to an ec2 box and do the needful

fiedzia• 1 month ago

There is a reason we use React today - if you want dynamic and complex site, HTML is PITA to work with. Either you reload everything on any change (not good), or end up with a maze of partial reloads in event handlers (not good either). It was done, it was bad, React (and similar frameworks) was the solution. If you don't need complexity of React, fine, use HTML. But if you do, who can guarantee that 5 min later someone will not start requesting site not to reload here and there, but update this bit here. So I don't blame people for just using React. And in this case the issue wasn't that react was used, but that it was used poorly.

jfaliwejrliawj• 1 month ago

Absolutely

I'm not a web developer. I built a few websites in high school, but these days I write safety-critical real-time code for robots.

A few years ago I was back in grad school and I took a class with undergrad senior CS students. We had to write a fairly simple web service, and I was blown away by how complicated they were making it. Based on the requirements we easily could have written 90% of it in plain HTML, but everyone else insisted it should be 100% react. Part of that is honors students wanting to do everything the most complex way possible to impress teacher, and part of it is them simply not knowing that other options exist.

cgh• 1 month ago

I’ve long thought frontend web developers are the ones most threatened by LLM-assisted programming for a bunch of reasons and now I can add “many don’t understand web fundamentals” to the list.

Eric_WVGG• 1 month ago

Yup. It’s exactly like the dismal state of CSS frameworks we're mired in.

All these new kids walk in and learn the CSS framework du jour first, then find themselves stranded when things move on. If they had just learned CSS the first time, they'd be set for life.

Nobody should learn React before learning HTML and vanilla javascript.

HN last week: Learn SQL Once, Use It for 30 Years https://news.ycombinator.com/item?id=48347483

protocolture• 1 month ago

My wife used to maintain a website for a non profit organization that was just HTML/CSS. After that she started building a lot of stuff in HTML without javascript.

bandrami• 1 month ago

And (now that I'm in management I understand this better than I used to) this problem becomes self-reinforcing. If every candidate out there only knows react and doesn't actually know how to do a simple front-end without it, you need to use React because at some point you'll need to hire someone to replace the person doing it. Even when management understands why the design is bad, if that's what the labor market supports it exerts a definite pressure.

bigstrat20033• 1 month ago

They may not be stupid people, but they are bad at their jobs. One needs to be able to at least try other approaches to a problem, and not have a one size fits all approach. The latter isn't engineering, it's cargo culting.

seangrogg• 1 month ago

As a web dev a lot of this is simply ongoing maintenance of a largely unknown quantity. Most web devs know React and use it extensively; Astro is something they'll have to learn on the job or hire for specifically.

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.

oldandboring2• 1 month ago

Astro is something they'll have to learn on the job or hire for specifically.

Before LLMs I would have agreed.

freehorse• 1 month ago

Not a web-dev myself and I was wondering if, apart from unfamiliarity with astro or HTML being treated as unknown technology, it also has to do with having to handle fallback cases, eg the 3 point validation (web component, browser default, server), esp when one is used to have react (libraries) just handling it all without any more considerations.

egeozcan• 1 month ago

I think the problem is hearing just one side.

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.

electromech• 1 month ago

The author open sourced the validation library: https://gitlab.com/alistairldavidson/validation-enhancer

c-hendricks• 1 month ago

As an application becomes more stateful it gets harder to keep that state aligned across the frontend and backend, especially if they're in different languages.

WorldMaker2• 1 month ago

A lot of developers have made or just perceive very strong silos between frontend and backend today. Any coordination that needs to happen between frontend and backend is potentially a communication challenge.

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.

hacker_homie• 1 month ago

I have had issues where the Frontend team is unable to explain how to communicate with their SPA, they say "just use this package/just run node" and are unable to explain the workflow in primitives.

Then they just validate on the front end, and we validate on the backend.

brightball2• 1 month ago

This was the jQuery way. It was called Graceful Degradation.

The entire approach went out of style with the advent of single page apps, React, Angular, VueJS, etc.

wccrawford• 1 month ago

That's generous. I always heard people espouse that ideal, but I rarely saw them actually do it. And I never saw it at work.

There were always certain UX requirements that required JS, and that meant the company wasn't interested in testing to make sure it worked without JS. None of their customers were going to use it that way.

Angular, React, etc helped force it further, but they didn't cause it.

IshKebab• 1 month ago

jQuery and graceful degradation are different things. The vast majority of sites in the jQuery era that used jQuery did not gracefully degrade.

8note5• 1 month ago

the shockwave and flash way was simpler.

download the whole app and run it in browser. you can even run it off line!

apothegm• 1 month ago

They don’t know how to compose and style elements without someone providing them with a prebuilt library of $framework components.

bachmeier• 1 month ago

Why is it more 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.

nosioptar• 1 month ago

I used to do web dev. (Got out of it due to js frameworks and their bloat.)

I'd pee myself in happiness to take over a project like this.

duderific• 1 month ago

I was confused by that too, but then I thought maybe the new replacement was commenting that using javascript in the app would provide more work for contractors, which he perceives as a good thing. So not using javascript provides less work. I could be wrong though.

iamjs• 1 month ago

Two years ago, I started a new company, and decided at the outset to avoid using any heavy JavaScript SPA framework. We stuck to simple server-rendered html and only use progressive-enhancement style JavaScript.

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.

aturek2• 1 month ago

I also prefer simple web tech, but I'm really glad you brought these points up! Ecosystems matter more than a lot of purist devs think.

creesch4• 1 month ago

I feel like there is some context missing in your story here. There is a lot of middleground between heavy SPA frameworks and creating everything from scratch. More importantly, I am left wondering what sort of functionality was your team trying to build that requires that much interactivity? At least that is what I assume with "rich user experience"?

gosub100• 1 month ago

I'm risking being wrong here, but I think the difficulty is getting conforming behavior across all device and browser combos.

sublinear• 1 month ago

This is the only correct answer in this entire thread! Congrats!

dapperdrake• 1 month ago

Computers are very good at repeating a known "recipe". They can add numbers billions of time per second. Yes, billions with a bee.

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.

victorbjorklund3• 1 month ago

It is harder to do more with less. There is a reason React and other is used so much. Makes it easier to make interactive websites. It’s like asking why backend engineers think it’s harder to code an api using C instead of using Django.

acdha3• 1 month ago

I used to think that was true but I now think it’s only true for very interaction-heavy apps: if you have hundreds of interactions on a page over many minutes, using an SPA is amortized across a lot of time, but if it’s something you could do with e.g. a simple Django app you’ll not only be done faster but will spend an order of magnitude less time on maintenance and accessibility work.

bigstrat20033• 1 month ago

There is a reason React and other is used so much.

Yes, it's because many people are quite bad at their jobs and reach for the same tool regardless of whether it's the right one. Let's not make excuses for incompetence.

pbalau• 1 month ago

The short and sad answer is that most people that work in web development do not understand how the web works or how web apps work.

Traubenfuchs• 1 month ago

Modern web/frontend devs do NOT understand whole page navigating form POST calls from a pre JS era.

meander_water2• 1 month ago

As someone who has built both react based frontends and html based ones (with htmx), there is a law of diminishing returns at play.

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.

meander_water2• 1 month ago

Really curious to understand why I'm being downvoted. I don't think it's a particularly spicy take - Just choose the right tool for the job.

em-bee2• 1 month ago

my most recent website is fully static html and css. it contains several pages and a menu that is duplicated in all pages.

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.

creesch4• 1 month ago

While purists will disagree, a little bit of javascript is fine. Having said that, you are talking about a personal website. Most companies will have a backend of some sort anyway.

Also, here is a little secret. If you want something that is future proof, try something that has been around for decades and still runs large parts of the internet. People will scoff at this, but PHP is actually really neat for personal websites and has been for decades.

A while ago I also found myself looking at static site generators, workflows from github to my host, etc. Eventually I realized I don't update things nearly enough, don't blog, etc.

For similar reasons as you I didn't want to go completely static as that is just too much hassle when doing multiple pages. So I decided to utilize that good old lamp stack to basically do something like this.

    <?php
    $pages = json_decode(file_get_contents('pages.json'), true);
    $page = $_GET['page'] ?? 'home';
    if (!isset($pages[$page])) {
        $page = 'home';
    }
    $pageData = $pages[$page];
    $contentFile = basename($pageData['file']);
    $contentFilePath = "content/{$contentFile}";
    ?>
    <html>
    <head>
        <title><?= htmlspecialchars($pageData['title']) ?></title>  
    </head>
    <body>
        <main>
        <?php include $contentFilePath; ?>
        </main>
    </body>
    </html>

Slightly more, but the base principle is the same. Just 10 lines of php code, and now I can just add pages by uploading their contents and adding them to the json file for whitelisting. For your use case it would be trivial to add a menu based on the json file and I'd be confident that it will still work in 10 years with minimal adjustments.

As a bonus I also rediscovered PHP in itself works really well as a templating language (as you can see) so no need for extra stuff like handlebars. As an extra extra bonus, I can just go to any shared webhosting party and get it running with no issue at all.

I am not saying you'd need to go down this road. But I just want to illustrate how stupidly simple a website can be with "old" basic technologies even if you want some form of backend.

thedays• 1 month ago

This seems like a very complicated way to maintain a menu on a static website. Have you considered using old school server side includes? It’s what they were designed for.

nailer• 1 month ago

Why is it more work?

People expect the entire screen not to redraw whenever they interact with an app and expect behaviour asides from the HTML defaults.

Shellban2• 1 month ago

I like JavaScript-light websites just as much as anyone (my own website works on the same principle). However, I do wonder how much of the increased traffic has to do with AI agents that now have an easier time working with the more standard web forms. My own contact form had a bunch of bots quoting Scorpion lyrics before I added a rate limiter.

yawaramin11• 1 month ago

None of the increased traffic was from AI agents. FTA: 'The results? When we launched, the number of people completing the form doubled.'

All completions were real people. It's a government website.

fd-codier• 1 month ago

Nice clickbait title.

Shitty-kitty• 1 month ago

I'm not a web dev and my needs are pretty simple but I've had a lot of success with jekyll. It's a open source static-site generator.

arnorhs2• 1 month ago

This post is good, and it's a great example of taking a problem and solving it with the appropriate tech with the right amount of depth. It really helps to have full domain knowledge of your customers as well.

However, I do not like how it is framed as "simple html is better than react" - because you could just as well have told the same story as a react developer.

(Nb. I could go on forever about the complexities and intricacies of storing things session based on a server vs browser based and etc - and lots of other things that were skimmed over in this article, but that would be too long)

All of those things that are simple in html are also simple in react.

It's literally the same code - there's nothing preventing you from using browser based html validation in react - all the same code that gets complicated in react (overly complicated validation logic) also ends up being complicated in astro - they have their own thing around schema validation etc and integrating it within an astro site means you have to integrate their client router etc etc.. so it's very easy to go overly-complicated there as well.

The comparison is also with an off-shore team doing development for you with probably incomplete knowledge and the way projects are structured they have an incentive to create the solution as fast as possible, in as little time as possible, with the biggest amount of complexity as possible.

The last point is devious - it's not necessarily that the contractor does this by design, but the incentive structure makes it so something that's overly complicated actually benefits them, so they don't have a direct incentive to go with something simple.

Anyways, a simple solution, directly addressing the problem at hand is always better - no matter what stack you pick.

(I'd like to say that I don't have anything against Astro's form validation, I was just trying to highlight how there's more to it than "native html browser validation")

arkmm• 1 month ago

Seems like LLMs embrace that last point as well.

arnorhs2• 1 month ago

I think you might be on to something there

neya2• 1 month ago

Sadly, this is the story of nearly every React project I've reluctantly inherited. In my experience, it's because React is not opinionated like its peers Vue and Svelte. So, a bunch of devs will use something for state management and and another team will use something else completely. Eventually both teams leave after making a mess. But, if you look at the graphs and numbers that MBAs chase, they will all look like everyone was productive until the very last minute. The ultimate casualty is unfortunately the user. Even Facebook hasn't figured out React across their properties. Just use Instagram / Facebook on the web. Bunch of spinners to load a static list of items in a drop down menu. Not even joking, click on the bhamburger menu on Instagram web. It makes a dozen requests, shows you a loading skeleton and takes 5 seconds before you can see a finite list of menu items. Ironically Facebook was super popular in the 2014s because they didnt have much React based BS going on. Everything was just good old hyperlinks.

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

8note5• 1 month ago

Ironically Facebook was super popular in the 2014s because they didnt have much React based BS going on.

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

disgruntledphd2• 1 month ago

To be fair, Facebook invented React slightly before 2014 so the original point seems very very strange to me.

MrBuddyCasino• 1 month ago

If there is one thing developers hate its admitting that something is too complex. They feel it makes them look dumb, and for some it is perhaps some form of job security.

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.

neya2• 1 month ago

and for some it is perhaps some form of job security.

Bingo. And that's one of the reasons you will face a lot of friction whenever any discussion surrounding this comes up.

Havoc• 1 month ago

Yeah the uk gov website is indeed petty damn good. For once all the money dumped into studies and what not produced an outcome.

65106• 1 month ago

It will still work 30 years from now! 300 years! 3000 years. There will be no strange error messages in the log, no browser updates breaking stuff.

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.

hit8run• 1 month ago

So funny to me that the kids nowadays are rediscovering HTML lol.

TZubiri• 1 month ago

She’s connected to the complementary WiFi and is browsing the GOV.UK pages on Housing Benefit. She’s not slicing fruit; she’s arming herself with knowledge.
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.

dlcarrier7• 1 month ago

The best way to filter out unwanted users is to make them install software that just displays a webview of what could have been a completely open web page. That way, you only get the ones you can track, which is more important than their wealth, as poor customers often end up spending more on commodity items than someone who is wealthy.

In my experience, Apple and Google are the worst offenders at software bloat, maybe because they can afford to create releases every few weeks, so the bloat accumulates faster.

miki1232112• 1 month ago

How many people are using browsers which don't support Javascript in 2026, and doing so out of necessity rather than out of choice? I can't imagine this number to be >1%.

How many such devices can still support modern TLS certificates anyway? By this logic, shouldn't we also use plain HTTP instead of TLS?

munificent• 1 month ago

It may only be 1%, but that small fraction of users are also probably the people who sure as hell don't need even one more tiny thing going wrong in their life.

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.

miki1232112• 1 month ago

A decade-old phone was released in 2016 (yes, we're old).

React already existed in 2016, so did Vue and Typescript. Never mind good old JS.

I frankly can't imagine a device capable of supporting modern TLS stacks but incapable of supporting JS. Much less a phone, which in many countries basically requires LTE (and sometimes even VO LTE) support to function at all, due to the 2G and 3G shutdowns.

zzo38computer3• 1 month ago

By this logic, shouldn't we also use plain HTTP instead of TLS?

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

phyzome2• 1 month ago

Remember, "don't support JS" is just a shorthand for a broader variety of situations:

- 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

James_K• 1 month ago

I will never stop singing the praises of plain HTML. It's accessible, it's portable, it's simple, but for some reason we need horrid JavaScript nonsense to operate.

Telaneo7• 1 month ago

I'm curious how many web issues can be solved by having the people responsible for the relevant sites only be allowed to use them on a Windows 11 machine with only 4 GB of RAM using Firefox with the network throttled to 3G speeds.

Assuming the processor isn't horrible, I can still browse plenty of sites with those specs without much issue, and on the sites that do require more, it's very rarely because the sites actually needs it (i.e. I'm not running Windows XP in a VM in the browser or something). It could just be normal HTML and CSS and normal forms, sprinkled with some light JS to help out a bit. But the amount of sites made with that level of care and attention are sadly rare, since the people responsible rarely feel the pain or have the empathy to fix the problem.

alok-g7• 1 month ago

+1 to the idea. Developers should have a powerful machine to develop, but a minimal machine to run and test.

McGlockenshire• 1 month ago

Windows 11 machine with only 4 GB of RAM using Firefox with the network throttled to 3G speeds

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.

mrweasel2• 1 month ago

And with a small screen.

The number of websites that are almost useless on the iPhone SE is getting pretty insane. Many site have a massive header, maybe a footer and a sticky ad. That frequently leaves less than half (~4.5cm) the screen usable.

I don't even think Apple cares about smaller screens anymore, because iOS UI elements also overlaps in some places.

digital_voodoo• 1 month ago

As a public policy specialist (and a tinkerer when it comes to tech), I read the article with pure joy.

This is the "wonder" that happens when you build for the client instead of for yourself. It takes being truly intentional: sometimes the client (especially that kind of client) does not know what he needs or want; sometimes you as a dev simply build something with good intentions but just out of habit.

Taking the time to ask true, relevant questions, and build backwards, is one of the ways you achieve this. It takes time, energy, intentionality (once again)... but it's worth it.

Theodores• 1 month ago

Everyone pays lip service to 'user experience' and 'putting the customer first', but, only with experiences such as acing customer service forms can one really claim to know what 'putting the customer first' means.

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!

righthand• 1 month ago

HTML doesnt have hundreds evangelists writing blogs about how cool it is. So it doesn’t really matter what the benefits are if juniors are going to keep showing up writing client-side react components. And the product managers letting them because of their sparkling (but naive) personality.

tweetle_beetle• 1 month ago

My client was a utility company
Adding a lot of pressure, this was a regulated monopoly
Some requirements I derived: ... We had to meet WCAG accessibility (the team settled on AA rather than AAA)

The author doesn't doxx their employer by giving any dates, but if we take the story at face value and assume it took place in last few years, it is pretty shocking.

How does it take a single hero to be fighting for AA compliance as an afterthought for a project with this scope in the 2020s?

I've worked on much more niche projects that treated this with the respect it deserves as a quasi-legal requirement.

dlcarrier7• 1 month ago

It didn't say anyone was fighting for it just that they had to. Whoever fought for the least possible compliance is the real hero. The less of that feel-good nonsense that is implemented, the easier it is for a text-only browser to parse, and the better a graphical browser works with the keyboard navigation that has been built into pretty much all web browsers since their conception.

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.

lo_fye• 1 month ago

Great work. I love it. We need more developers like you.

simonbarker87• 1 month ago

I want to work with people like this. Build the right solution to the problem with the simplest technology you can.

unsungNovelty• 1 month ago

I still to this day is baffled by all the idiot geniuses who thought it was OK to have "Please enable javascript" when opening a website without JS enabled. A good chunk in many pages are just static content. You should be able to render HTML. Ashte!

reacharavindh• 1 month ago

HTML first, minimal JS, not using any frameworks unless absolutely justified is already part of my prompts to LLMs when I build stuff for myself. I’m not a frontend developer, and have not kept up to date with the ton of frameworks. That HTMl first approach already makes the LLM outputs faster/fresher for me. I wish more people went this route for public facing services.

butterfi• 1 month ago

I remember when YouTube implemented a new html player and suddenly, unexpectedly, they had all the is traffic coming from rural Africa. Size matters.

7xmohamed• 1 month ago

Most of my apps are now simply HTMX + Go + SQLite. I've found it's enough for most projects.

geroge_kyaw2• 1 month ago

Use Next.js Bro just know React and complaining it.

geroge_kyaw2• 1 month ago

Use Next.js!!! Bro just know React and complaining it.

zzo38computer3• 1 month ago

I think it is a good idea. JavaScripts and CSS can enhance it but should not be required.

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.

dlcarrier7• 1 month ago

I have a theory that "accessibility" is just a euphemism for "usability", when it's so bat that a noticeable portion of your userbase is locked out.

LyalinDotCom• 1 month ago

OMG its JavaScript, I can't even.

MoonWalk2• 1 month ago

"customers could either use an old ASP form on the website"

Did I miss it, or did the article neglect to explain why this was a problem?

bruhlikereally• 1 month ago

You ever tried to maintain or enhance an ASP form that was built 20 years ago and enhanced by random devs with no documentation? I was working with ASP forms 15 years ago that were hopelessly outdated, included tons of technical debt and were not in the least bit user friendly. You can accomplish so much more with things that ship in every browser now. It’s not a very modern technology and you miss out on things that are now very standardized and much, much easier and quicker to develop and maintain.

Also, Microsoft.

bpbp-mango• 1 month ago

In the age of LLMs it shouldn't be a big deal to migrate any legacy ASP to .net core, surely

_pdp_• 1 month ago

The landing page for our latest tool is a static website (exported from nextjs). It has no marketing on it. It just has simple instructions to copy a prompt into ChatGPT / Claude.

That's it. I will report back if it works.

erlkonig• 1 month ago

Someone should send this doc to papajohns.com, which has overcomplicated their website to the point it doesn't even work in Firefox anymore.

sjs382• 1 month ago

"And then the whole bus clapped..."

jklinger410• 1 month ago

There are truly an amazing amount of red flags in this otherwise well meaning and short post.

casey2• 1 month ago

We are still in the early days of software and web development. This is the food service equivalent of a restaurant operator discovering that if they serve dog poo vs edible food they get more return customers.

flufluflufluffy• 1 month ago

form submissions and redirects took a while to explain to my colleagues, on account of everyone being used to heavily client-side web applications.

Ah yes, when you have to explain to your esteemed web developer colleagues how the web works xD

kristianp4• 1 month ago

Related recent threads about react performance:

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

kristianp4• 1 month ago

I should have added this one from 2022:

https://news.ycombinator.com/item?id=30528473

SPAs Were a Mistake (gomakethings.com) 692 points March 2, 2022 | 620 comments

abraxas• 1 month ago

We have the "social media" companies to thank for this innovation. They introduced these stupid patterns primarily to keep users locked into their walled gardens and the rest of the industry followed them to the bad place like lemmings. Software is a fashion industry.

mghackerlady• 1 month ago

I'm personally of the mind that any .gov or utility website should work on old browsers, or at least have a lite fallback to ensure everyone can at least read how to do something the pen and paper way

iamflimflam1• 1 month ago

They replaced an ASP form on the website with something better.

To apply for their services, customers could either use an old ASP form on the website, or follow a manual process

sublimefire• 1 month ago

This takes me back close to 15 years ago: using backend session management in Grails and the html forms that were enhanced with “some” JS, using responsive CSS. The difference at that time was browser tech not being as advanced as now, we had to care for different browsers and deal with IE7 and even IE6, it was difficult and we needed extensive QA (Browserstack would appear later). There is a reason why we had JS library evolution. Dude there was no npm, not even bower. Then we had Backbone.js - loved it, then AngularJS - amazing, then Angular version which had huge breaking changes then React, Polymer etc. Native browsers can do a lot these days, it is easy to enhance the functionality as well. But it was not always the same, the decisions to use React made sense for a variety of reasons at the time, maybe it was the case here as well.

LoganDark• 1 month ago

form submissions and redirects took a while to explain to my colleagues

This is so sad

ezbie• 1 month ago

That this article even has to be written proves how stupid web development as a whole has become.

I loathe this area of software development, loads of unnecessary frameworks and spinning gears that add complexity while making less and less functional applications

tomcon7• 1 month ago

I'm not a fan at all, but the thing I don't get about react sites is do they not lazy load at all?

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

ThomW• 1 month ago

I teared up at the PSP talk. I feel terrible that life requires a level of technology that not everyone is capable of affording and it doesn’t seem right.

Henchman21• 1 month ago

It doesn’t seem right because it isn’t .

dlcarrier7• 1 month ago

I had a PSP long before a cell phone, and the built-in browser was like a peek into the future. It really was janky, and could only scroll a page at a time, like an e-reader, but back then web pages didn't need a top-of-the-line computer with gigabytes of ram, to display text and the occasional image, so it was extremely useful when a laptop wasn't available. The button mapping was pretty good, and navigated similar text-based browsers like Lynx, but with the benefit of seeing images.

digitaltrees• 1 month ago

I loved this post. Awesome commitment to users. Breath of fresh air.

zoetaylor003• 1 month ago

Two failed React attempts before this. Shows how chasing fancy frameworks over solid basics can cost millions. Simple HTML wins for public services every time.

wolfi1• 1 month ago

but it's not simple html, it's a npm-package

zoetaylor003• 1 month ago

"Simple HTML" in 2024 means HTML generated by a tool built on a tool that installs 300 node_modules. We've come full circle.

clemiclemen• 1 month ago

This reminds me of the story of the "Feather" project at YouTube where they improved a lot the page weight and the average page latency went higher just because they were actually seeing a lot more traffic from places with slow Internet.

https://blog.chriszacharias.com/page-weight-matters

thisOtterBeGood• 1 month ago

“but that’s a lot more work for us.”

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.

Mystery-Machine• 1 month ago

What a great article!

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.

assimpleaspossi• 1 month ago

Note: the <input> tag does not use and does not need a closing slash and never has in any HTML specification. https://html.spec.whatwg.org/dev/input.html#the-input-elemen...

vanshsoni0027• 1 month ago

nooo

psp99• 1 month ago

Literally signed up here after 20+ years of lurking, because reading that the PSP had Candy Crush made me stop everything I was doing. This game is a mobile game and did not exist on PSP.

"Clutched in her hands is a games console - a PlayStation Portable. She stares at it intensely; blocking out the world with Candy Crush."

deltarholamda• 1 month ago

You missed the point. The guy thought she was playing a game, but she was actually using the built-in web browser on the PSP. Whether it was Candy Crush or Tony Hawk Pro Skater or Super Mario Bros. (also not on PSP) doesn't matter.

She was using what is broadly comparable to a WebTV browser to access a government site, and it worked because the guidelines for gov.uk are so very, very good.

(The UK gov sometimes gets a bit of stick for being needlessly useless, but their web guidelines are extremely good. Absolutely a fantastic starting point for anybody interested in web development.)

sylware• 1 month ago

Open your eyes: the "web" was stolen by the 'whatng cartel'. Their web engines are abominations, the c++ language is making things even worse because now it requires a compiler of an obscene complexity to handle "~right" the absurd and grotesque complexity of the c++ syntax.

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.

bomewish• 1 month ago

He was appalled and said, “but that’s a lot more work for us.”

This made me really, really angry.

ksec• 1 month ago

The industry as a whole stopped caring about users. They cared about their resume or CV. Resume Driven development.

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.

arendtio• 1 month ago

So ironic that I had to start Chromium just to read his blog post, because my Firefox 151.0.3 was unable to render the font on his blog...

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.

zoetaylor003• 1 month ago

1KB for working form validation without all the library drama is just common sense. But common sense got replaced by "I like the shiny new thing" somewhere around 2015.

Building an HTML-first site doubled our users overnight

Related Stories