Genuine question: Judging from the comments, seems like people like this approach. So why is the general trend more towards approaches that use javascript (sometimes unnecessarily) and frameworks like React?
As an end user, I really like the style of applications that GOV.UK write and endorses - lightweight, clean layouts, accessible, and generally work with minimal (or no) JavaScript. And I dislike most SPAs, because they usually end up breaking lots of expected browser functionally, are useless without JavaScript, and often load all kinds of heavy dependencies from various third party sites.
But what users like and what developers like (and can quickly develop) are often very different things.
Ambivalence is a weird thing. People often speak in two minds. We
hate AI, but we love AI. I love ice-cream and crisps. but I tell my
kid not to eat that. As George Carlin said, when you're driving
everybody going 5 mph slower than you is an idiot, and everybody going
5 mph faster is a maniac.
Here on HN we often see the schism between speaking "as a developer"
and "as a user".
As a user I hate a lot of the shit we gleefully enthuse about here.
As a coder it's super cool.
Nobody got fired for building an app in React? When something is an accepted as an industry standard, it's safe to make a decision that goes with the flow. Also, nobody is doing devrel for html/css/vanilla js - if you search how to do things you will find nearly only exclusively framework related content.
There's no cost to building slow, fragile, and inefficient websites.
When you build programs that run on _your_ computers, you have to pay for that. Or at least have to deal with the finance folks asking why your cloud spend increased 5%.
But if you run your software on other people's devices, like frontend devs do, there's barely any cost to that. Any negative signals need to trickle in through user reports, support tickets, and maybe Twitter posts. There's a ton of selection going on there so you're likely not getting the full picture.
Because the trend is also towards doing more over the web.
The web is replacing traditional thick clients, which also assumed a fairly stable network connection and platform specification.
Government systems need to work with the lowest denominator - even if it's not that common. Tech startups only need 1 client to exist at the start (and can mostly trust that their requirements will become commonplace as they scale).
My gut is that the government wants services that work for 100% of people. In terms of purely costs, people who can't use a site may need to be serviced anyway by more expensive means (e.g., voter registration by mail).
A business probably thinks that it doesn't need 100% accessibility. A nicer site may be thought to get more users/customers, even if the site doesn't work for many (or maybe devs just want to fit in with the other cool devs making cool dev sites)
1. Complexity. Devs like complexity like cats like catnip.
2. Tools. React+JavaScript is the industry monoculture. If they're all you know (and for a significant number of frontend devs this is unfortunately true) then you're invariably going to build something complex because its in the nature of your chosen tools.
3. Career anxiety. Building something simple using simple tools isn't sufficiently hardcore and braggable to get that juicy comp increase at the next performance review, never mind a promotion or hopping to that next job.
a. I once worked on a project where the webapp frontend went through a time-consuming, mid-project framework swapout because the "senior full-stack developer/architect" decided it needed server-side rendering for SEO purposes. Never mind that it was a niche industrial app that required a login to use and simply wasn't visible to search engines.
b. I remember being advised to stay quiet when I asked why a different web developer, upon being asked to build a simple static website, had nevertheless built it in React.
That's one dream. There are advantages to thick clients as well... less network traffic if the device can do processing on site, A much easier to maintain and update distribution model over the traditional desktop experience for what is essentially application software, etc.
UIs in general are pretty hard unless you have a set of primitives that do everything you want. HTML + CSS used to be lacking (and still are in some respects). A thin layer of vanilla js on top of them has a tendency to turn into a mess of spaghetti as more and more features are added. So, you organize it into a framework. But a framework needs to be able to assert control over anything that would affect how it renders, which is pretty much everything a browser might do, leading to an SPA.
I think it’s a nice idea, but given the bean-counting-efficiency-experts that run the company, this will never fly “build for the 90-95%” is what I constantly heard from bosses before I left frontend and went to backend, and eventually leaving the cloud industry all together. I can see it working for government sites though because profit isn’t the sole purpose of the website, it’s more there to serve the public as a whole.
Firstly it's what looks good in demos, both internally to management and when trying to sell things to consumers. Government services have users without a choice and usually that they have to provide it has been decided top down.
Secondly it's less "boring" for developers and arguably less work.
Thirdly you have a large amount of only-frontend (often only-React) devs know who won't think of alternatives.
Because most websites today are more than just informational. Some web apps facilitate complex user interactions which typically require a lot of state which are the raison d'etre of web frameworks.
Because the ux and dx are better once you reach a certain amount of complexity. Companies know what is best for their business.
There were will always be a group of devs that don’t like it because it isn’t the same web as in their heyday, and they all will eagerly pile on anything remotely JS-critical is posted on HN.
There is a selection bias to the comments that does not accurately reflect the industry opinion.
"Companies" don't really know anything. The decisions get made by people, with all the flaws that people have. I have seen many developers make decisions that are detrimental to the company.
I do agree that there is a section of HN that will pile on these kind of topics, and I have flagged dozens of low-effort swiped against JS over the years that add nothing.
But two things can be true at the same time:
1. there is an unpleasant section of HN that will rant about all things JS, and
2. SPAs (or our current approach to them) bring a lot of downsides and are often not worth it.
I agree there are tradeoffs to SPAs, and I shouldn't have implied that companies are a perfect decision-making apparatus.
That said, I think if a certain technology becomes an industry standard, especially one that demonstrates some staying power, as React has, it should not be dismissed out-of-hand, and most of this comments section is doing.
There are probably more companies not using React than are. Words like "industry standard" don't really mean much. Languages like Ruby or Go are widely used and here to stay, yet there are also many people who don't like it – and that's okay.
There's a lot of self-sorting going on here; I stopped doing the frontend thing because I didn't like the way things were going and even tepid critique of this was (and still is) often met with completely out of proportion aggression, vitriol, and insults. I got more hate and vitriol over my "Why I'm using jQuery in 2018" post than the rest of my website combined. It feels like engaging on the Israel/Palestine debate or something.
Of course every community self-sorts to a degree. That's okay. I would never presume to critique React on a React thread. But "frontend" is very broad and also includes non-React.
Your comments here are fine, but at the same time it also strongly suggests that SPAs are the only way to build good frontends and that everyone who disagrees is just some old coot stuck in their ways. Both of which are rather tiring tropes, and especially that second one is pretty dismissive, if not downright insulting.
So I kind of gave up on this years ago. It's easy to reach consensus if you chase away everyone who disagrees.
JS-heavy sites are frustrating to me due to generally worse UX — links can’t be opened in a new tab, because they’re not actually anchor tags. Forms can’t be submitted by the “return” key. Navigation using back/forward buttons is broken. There might be a few companies who get it right, but most don’t.
The OP was asking for an explanation why the preferences of the industry diverge from the preferences of this comment section. The question itself identifies two groups.
The top comment on this page said the frontend community seems like a jobs program. It's interesting that you are only criticizing the view you disagree with as being too divisive.
Because we also have hard data that users absolutely hate a blank or frozen screen and "CONFIRM FORM RESUBMISSION." Users are allowed to hate multiple things at the same time and it's up to the web developers to stack rank those.
But what users like and what developers like (and can quickly develop) are often very different things.