Building a robust frontend using progressive enhancement | Hacker News Reader

Building a robust frontend using progressive enhancement

gov.uk

244 pointsartbristol164 comments

> If you use a JavaScript framework you should: > > be able to justify with evidence, how using JavaScript would benefit users

Steady on, guys.

for real, do you want swarms of developers to lose their jobs because software complexity collapsed?

If we want full employment, we should mandate people use spoons instead of shovels.

https://en.wikipedia.org/wiki/Perverse_incentive

Use? I look at all the time to keep it running.

A good rule of thumb is: if your app can/could run offline-first like a desktop app, it's ok to make it a single-page application. They can be snappier and better than a multi-page browser app. Examples would be stuff like Photopea, Google Docs/Sheets, tldraw, etc.

This way, the biggest downsides (moving between pages & requiring an internet connection) are eliminated.

But if your app requires an internet connection and multiple pages, it's better to let the browser handle navigation in a fault-tolerant way.

This is a good point. Web platform is now doing both websites and GUIs cross-platform. If you need anything offline or desktop GUI alike across multiple OSes, SPA is your friend, if you just want to build a website, SPA might not be the best fit.

You have to test a lot though, especially in contexts like gov.uk, since a significant number of users is still using older phones with browsers that aren’t updated anymore (like for example iOS 15 Safari).

Snappier is an outdated concept. HTML has lots of tools in it now.

SPA's are one thing, the complexity to create it is another.

I started web stuff in the 90s as a child. I didn't know what CSS or JS were, except the latter you could copy/paste some magic scripts to make things flash and suchlike. Later I built dynamic sites with PHP for local businesses. I learnt JS and CSS at this point (to some extent as least). Then I decided to quit web development because I couldn't stand spending so much time things to work with the shittiest browser available (IE6).

After almost 6 years away I came back around 2015 when I realised a web server would be useful for whatever I was doing. I was shocked to find the world had forgotten about so much regarding HTML and CSS. We used to build multiple stylesheets for our sites. That was forgotten. We used to make stuff work without JS first, then add JS as a nice-to-have afterwards. That was forgotten. I saw web devs just doing all their form validation in js and the server doing none. Shockingly, this is still common today. I'm not aware of a common pattern where you get the server to do validation and just display it in js. Everyone seems to either duplicate or not even do it on the server at all!

When I saw this I was no longer impressed by what people were doing on the web because it wasn't the web I knew, it was just "applications" built in JS. Trying to argue for "web first" was a losing battle.

Similar experience.

Started with html 3.2/xhtml and css as a kid. Some years later got a job and did Django + jQuery, but found myself drawn into infra. A year ago I worked alongside a web dev team and decided to peek into their work--nothing made sense anymore. The amount of complexity was staggering. It seemed like they spent most of their time managing that complexity, eg. reducing build times, solving dependency problems, solving weird TS issues, handling errors in different components, etc.

In the Django+jQuery days, the emphasis was still always on what user got to see and use.

I'd argue that doing client validation saves your server from superfluous requests just to validate that your username input has less than 16 characters. Of course, you later still do it in the server again because you can't never trust the clients

Reducing server workload is useful

Good advice, but

> - users of assistive technology would be unaware of changes in context, for example when moving to a new page

> - it would fail to handle focus when moving between pages

> - the user would be unable to navigate using the back or forward buttons in their browser

> - users would be unable to recover from an error, for example if there is an interruption to their network connection

These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother

You kind of get it out of the box with plain old HTML though. Once you get into SPA territory you’re reinventing a lot of wheels to get back to parity, or replacing native functionality with JS alternatives.

Consider multi-page forms: how many SPAs just store all of that in memory and then make one request at the end? Without JS, the BE would be saving the state for each step so you could come back to the form later or refresh without losing anything.

You can easily store intermediate state in sessionStorage or localStorage and prevent all the unneeded requests to the server just for moving between steps.

Yes, hence why it’s good advice.

How could you possibly make them true, if you are told to respect even deliberately disabled features? If the user does not permit retroactively messing with their navigation history, then you are left with only one option: get the history right, at the time it is written.

I think that section could be more clear if something like "without more effort" was added.

> These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother

Yes you can, but then it is way more difficult, and the fact that most don't even bother means that it is not exactly trivial to implement. Why to force that garbage when basic HTML basic web sites work just fine out of the box.

I wish the whole internet followed this advice.

We could shutdown a few dozen powerplants easy.

Great idea, more capacity for LLMs!

Wait until you hear about the next big thing, AI compute centers, and those plant shutdowns will be a drop in the ocean…

What’s old is new again.

Maybe we should prioritize the simplest possible solution rather than what’s trendy today.

Just watched the recent DHH keynote at Rails World, I might not do Rails, but fully on-board with his point of view with where modern Web has gone.

Following trends is why 99.9% of developers are useless and should never hold an engineering title.

Not really. The UK government has never supported the use of JavaScript in its web services and has heavily invested in design systems which use html and css with accessibility at their core.

Just because the rest of the industry has been high on JS doesn’t mean everyone has.

Why is Linux not in this list:

https://www.gov.uk/service-manual/technology/designing-for-d...

Less than 2% of users?

The flippant answer: because it's a kernel.

The non-flippant answer that is related to the flippant answer: because there are dozens of distros and within those distros about a dozen browsers if you factor in all of the Mozilla forks. They could probably choose a blessed one, but any individual blessed one turns out to have an incredibly small user base (Even Ubuntu, to the extent that numbers can be generated as a secondary signal, looks to be about 1% desktop OS share).

Why should it be on that list? When does a webpage work on macOS and Windows but not Linux?

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?

Because browsers are being used as application frameworks (i.e. for making applications) rather than what they were designed for.

The dream has long been to have code distributed to thin clients while allowing intensive tasks to be run on servers.

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.

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.

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

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.

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.

How is increased FCP, LCP, ttvc better ux and DX? We've had hard data that decreasing page load time make for better user experience[0].

Please don't make this an Us vs. Them thing.

[0]: http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....

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.

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.

> Companies know what is best for their business.

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

Are entirely compatible.

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.

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.

>Secondly it's less "boring" for developers and arguably less work.

Humphrey: But what happens to us?

Bernard: Well, much less work.

Humphrey: Yes! Much. Less. Work. So little that fullstack engineers might almost be able to do it on their own!

Because the people who like this approach aren't frontend developers.

In fact, I think that people dislike this approach because they are frontend developers, as otherwise there would be very little frontend to develop.

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)

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.

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.

Ie. It's all about incentives

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 couple of anecdotes relating to point 3 above:

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.

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.

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.

This is what I try to follow - serving html with prefetch data from the server, what could be done on client I do on client to minimize server round trips, minimum css (responsive layout) and vanilla js. Separate web pages as needed. Somehow that sounds weird and oldfashioned with my colleagues since I'm using only html, css and vanilla js? I don't miss a thing...

Even the article notes that mindless server-side is not good software engineering. (Note the use of the phrase "can cause problems" instead of "does cause problems".):

> If you do choose to use client-side JavaScript frameworks, be aware that although they can be helpful when building a service with a complex user interface, they can introduce problems.

> Using a client-side JavaScript framework can:

> - increase the overall size of your code base and push processing to the client-side, causing performance issues for users with a slower network connection or lower powered device

> - create a reliance on third-party code that your developers do not have control over, requiring you to make major changes to your service in order to stay up to date with changes in the framework

> - make it difficult to find people with the skills required to maintain the code, if the framework’s loses popularity over time

> If you use a JavaScript framework you should:

> - be able to justify with evidence, how using JavaScript would benefit users

> - be aware of any negative impacts and be able to mitigate them

> - consider whether the benefits of using it outweigh the potential problems

> - only use the framework for parts of the user interface that cannot be built using HTML and CSS alone

> - design each part of the user interface as a separate component

> Having separate components means that if the JavaScript fails to load, it will only be that single component that fails. The rest of the page will load as normal.

User first programming rather than work inflating bloated frameworks mainly used to justify further dev work. Which one do engineers choose

The one they can put in their promo packet, obviously.

I think SWE must be the only (allegedly) engineering discipline where developer convenience is overtly prioritised above product quality or user experience.

If you doubt this, think how many times you've seen a framework advertised due to its ease of use for developers vs due to e.g. performance in low bandwidth.

The funny thing is that DX for JS apps is usually _worse_: 2x the code just so we don’t have a page transition.

And also screw up the browsers back functionality in the process

Some different type of praise: I absolutely love the voice used throughout gov.uk (this page being no exception). The language and tone is clear, straightforward, to the point, neutral, as technical as it needs to be and no more, and stripped of unnecessary flourish, without being dry. Amazing!

If only the rest of the UK Gov IT system is as good as their Web Design teams. Instead they pay huge sums of money to Oracle or Accenture.

On another note a lot of the UK Gov Web services runs on Ruby Rails.

https://github.com/alphagov

A lot of (younger?) people seem to think that you need JS when just a regular html form would do.

ah ageism. If younger guys think that it's the old lot writing shit docs/blogs giving them the idea.

I’ve run into developers that don’t understand how regular HTML forms work and think everything needs a REST call with JSON. Many of them were not young.

Me too, I was devastated. The guy was a super expensive senior react dev. He literally went like: “Wdym multipart form data?”

Sadly, we now have a whole generation of web devs that don't know anything other than SPAs.

“You should consider using this in your requirements” implies that this is not a hard rule, it’s just an ignorable suggestion. It would be interesting to audit gov.uk web pages over time to see whether this advice is being followed.

Don't forget the rules of British English that make it very clear that the grammatical construction: "you should consider" means "you must in all circumstances save for the immediate alternate outcome being a genocide."

Thanks for explaining! That’s quite different from the US English (and RFC English) meaning of “should”.

This translation guide is usually helpful.

https://polish2english.files.wordpress.com/2011/11/55551980-...

I'm afraid I don't know what RFC English is and neither does Google.

Huh, for me the very first non-ad result for googleing RFC English is https://en.wikipedia.org/wiki/Request_for_Comments, which is the correct citation.

For me it was to do with Rugby Football.

To be fair, here is the RFC meaning:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

It means you can’t simply ignore it, and instead have to have compelling reasons to justify any deviation.

Unfortunately, in many organizations, "the library we use doesn't follow this recommendation" is a valid compelling reason. Which means that in practice "SHOULD" effectively means "WOULD BE NICE IF".

Having

> You should consider

Is Gov UK's way of allowing people internally to point to it and say 'Well, did you consider it?'.

UK Digital don't have any direct power to force change - they have to use sensible advice and internal process to encourage better design.

Singe page apps suck arse. This really isn't news to anyone, except for those who make money by developing that garbage.

OMG it feels so good to not be the lone voice in the woods. I would say about 3/4 of my frustrations as a user are from sites that should have simply been built with HTML + CSS and minimal Javascript. The front end community most days feels like a jobs program.

Same here as developer, I only put up with SPAs at work, because job title isn't doing fronted stuff.

However on side projects it is pretty much vanilla.js without any kind of SPA related stuff.

You aren't alone, I'm a technical director and even I can't win this battle. We have a ton of complexity on what could be a simple SSR site, but frontend devs don't like writing anything but SPAs, so it's hard to change.

Hope next.js 14 isn’t the framework behind the “simple SSR site”

It's Django. Next.js fails the "simple" part.

My constant battle in the last 15 years (of 30 years of development) has been the unending torrent of completely unneccesary complexity that teams inflict on themselves. I feel it's often just to pad their CVs or because the current *perfectly usable* stack is boring.

Limiting complexity to where it's *really* needed is the hidden magic of a great leader in my opinion. A great engineer knows how to wall that complexity off from the rest of the system as well because complexity spreads like cancer through a codebase.

I've never been a TD but I can imagine your pain.

Hey, at least I managed to consolidate all our services into a monolith, which developers ended up really liking, and it works well for us.

One battle at a time, I guess, but the "let's simplify the frontend" effort is meeting much more resistance from people who are interested in the frontend having a lot of state.

Part of the issue in the complexity battle is competition and levels of expectations from features. Non technical decision makers (and there are lots of them, I’d say most of them) see services from Facebook, Google, etc. and have the same level of feature expectations in their one off small app. They have no clue how much effort exists behind it to maintain what seems simple and now even standard (across large services).

Ultimately they come up with ideas and write feature requirements (indirectly) based around this premise with their shoestring budget and ad hoc team. And we end up in a world with not so well developed applications attempting to create similar features to competitors in budget which leads to a lot of corner cutting and barely working implementations with no thought towards long term maintenance requirements. At least, this has been mostly my experience.

There are of course those out there simply bored with life who want to build unnecessary complexity because they have to be doing something (heaven forbid there be idle time in any work environment either from their own pressure and/or internal organizational pressures) and they start trying to be clever or skill up to some wider marketable skillset (e.g. react).

It’s really business environments that create this sort of complexity requirement from needless feature requests to wide adoption of specific trendy skills in their stack to make hiring easier/cheaper, etc.

Everybody is incentived to use the tools FAANG+ are using even if completely unnecessary, ie follow fashion. Developers for Resume Driven Development, and execs because it reassure investors and is good for marketing. The industry doesn’t reward smart engineering choices.

> I can't win this battle

You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire.

The bad way to do it: "You made a single page app with PHP and {other tech} and {database}! I hate those! Don't you read (reddit, twitter, hacker news)? Best practices say..."

The good way to do it: "Our users often share links within the application with each other to navigate and the new single page app you demoed doesn't allow that."

Or: "While the page load times look great on the metrics in your power point, as everything is lazy loaded it takes 10 seconds for the page to actual become usable, the old site loaded in under a second why are we regressing the user experience here?"

Or the evergreen: "What does that buy us?"

This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way.

Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component".

How many developers do you think heed those warnings?

Not enough. But they will scoff at other technologies old and new.

> heed those warnings

It's not a warning. It's a functional requirement that you put into the ticket. The project isn't done if the rewritten page takes longer to load than the old one did. Don't ship it, don't pay bonuses based on shipping it.

Please read my comment more carefully, you're being patronizing. I can't put "I want feature development on this codebase to be faster than two sprints in six years" in the requirements.

Sounds like you should talk to the person who is actually in charge then.

I'll have a chat with the mirror.

Our frontend is a bunch of barely working wonky react-soup, and we really need to rewrite it. It's mostly a "tables and forms"-type frontend with a lot of complexity in the backend: it's a great use case for htmx (or even vanilla/jQuery).

But I'm not really sure how we're going to handle that or who we'll hire for it, because I fear we'll end up with another react-soup. My current strategy is to make a MVP in my spare time to show it can be done and that it'll be quite nice.

The main part is to avoid holding state in two places (frontend and backend) if you can do with holding state in only one (either frontend or backend).

Unless you're building an app that holds data locally, for most web apps, you should be pushing state down into the backend. Fat models should be your single source of truth, skinny controllers, and service functions in order to separate data from code for testability.

Avoid caching as much as possible until you absolutely need to. As soon as you introduce caching you now have multiple sources of truth instead of one.

or be stateless… ;)

after you re-write it (either immediately or with time) you will end up with the same thing, just a different kind of soup. using vanilla-whatever you will eventually notice you are doing “X” over and over again and then you’ll start writing small libraries (or even worse, some internal “framework”) which over time will get stale or will get bunch of features from devs that need “just that plus a few more things..” ad infinitum…

This is simply not true, and has never been true anywhere I've worked. We can do everything with a much better UX in about 2,000 to 3,000 lines of code, instead of ~25,000 (and almost 2,000 dependencies).

It's a boring tedious "true-ism" that keeps getting pounded. I don't really know what else to say, but it's simply just not true.

What is the longest you have ever worked on a single piece of software? If you are in some sort of consultancy or jump jobs every 2-3 years it most definitely won't be true. You stay with a product for 5+ years it is bound to happen unless your dev shop is like 10 people. If you think this is not true AND have spent 5+ years with the same piece of software you are an outlier...

Things like Livewire, and alpine.js are showing simpler ways.

You can build a SPA SSR as well.

And it doesn't help when the Browser, the Web Spec and front end dev are all aligned into making SPAs with JS.

I really wish something like HTMX is built into the browser or part of HTML5 spec.

There’s a draft proposal to get some of HTMX in the browser: https://github.com/alexpetros/triptych

Then why hire front end devs for a project that doesn't need one?

Probably 80% of websites could do with a good designer that knows how to get their designs from concept to CSS and a good backend engineer that know how to output decent markup.

Because someone needs to turn the concept to browser-ready, responsive, cross-browser, lightweight markup, and that person is a developer who specializes in the frontend, ie a frontend developer.

An SSR site needs to have full stack devs, not front end devs.

Else you will have exactly this problem

An SSR site needs a frontend dev to produce the HTML/CSS/JS and a backend dev to provide the template variables. You don't need a developer to do both when the interface is so small.

Nah that's crazy man

> could be a simple SSR site, but frontend devs don't like writing anything but SPAs

It might be worth asking why that is.

I used to write a ton of SSR'ed pages back when that was really the only option we had (before people introduced jQuery and AJAX), then I wrote SPAs (mostly Angular & React), then again SSR'ed websites (Java/Spring/JSP with a ton of more-or-less vanilla JavaScript) and now I've been on a Vue-based stack (w/ Astro/Vite for SSR) for a number of years. And these were all applications with dozens of teams working on them in parallel and a corresponding number of components & LoC.

Personally, I wouldn't want to go back to traditional SSR stacks (Spring/JSP, vanilla PHP, or Python w/ Django or Flask) ever. People often vastly underestimate the complexity of good UIs. They might start simple ("could be a simple SSR site", as you say) and, before long, the wheels come off the bus and they look at a big unmaintainable ball of vanilla JS on top of HTML templates that are directly coupled to the database schema, with global CSS styles permeating (infecting) the entire code base.

In my experience, there is a certain amount complexity that is inherent to a good UI. It doesn't matter whether you use classic SSR, or modern frontend frameworks like Angular/React/Vue/Svelte/SolidJS, or new kids on the block like HTMX/Turbo/… — that complexity will still be there. However, with modern frameworks you've at least got a chance to tame that beast.

More specifically, what modern frontend frameworks give us is: 1) Modularization into components, 2) scoping of styles, 3) type-safety, 4) unit-testability of components, 5) component-local state management (≠ insanities like Redux), 6) clear separation between view/UI logic and business logic.

If you can replicate these features using a bespoke version of JSP or HTMX or whatever, great! But if you can't, I'd personally rather pick a well-established frontend framework like React or Vue. Yes, your developers might still mess that up and produce shitty code, but the chances of them messing up in a classic SSR stack (without the aforementioned features) are so much greater.

You're arguing against something different, though: I agree you shouldn't do components with CSS/jQuery, components should be self-contained. I'm arguing against SPAs, where the state of the user's browsing is replicated on the frontend as well, with all the complexity this entails.

Isn't there a good component framework we can use, and that's it? I want to be able to say <carousel></carousel> and have it work, without having to have a whole SPA attached to my components library, with routing, state, and all the rest. Doesn't that exist?

> I'm arguing against SPAs, where the state of the user's browsing is replicated on the frontend as well

What state exactly are you referring to? I'm not trying to play dumb, I'm genuinely curious because in my experience there can be "good" and "bad" state in the frontend (where "good" roughly translates to "inherent to the problem").

> I want to be able to say <carousel></carousel> and have it work, without having to have a whole SPA attached to my components library

A carousel sounds like a great example for something that could be standalone. However, what if 1) the data shown in the carousel needs to be loaded lazily (e.g. because the carousel is near the end of the page and loading the data is expensive), and 2) the carousel's display settings (e.g. how many items are shown at once) depend on the content being shown? I recently had to work on exactly this case. Suddenly, your once static carousel component isn't so static anymore and you have to add a bunch of JavaScript, and also state.

> without having to have a whole SPA attached to my components library, with routing, state

Maybe I'm missing something here but pure React/Vue doesn't require your page to be an SPA or to have any routing mechanism at all?

> where "good" roughly translates to "inherent to the problem"

I don't mean per-page state (that one is inherent to the problem, as you say), but cross-page state (the one typically handled by backends, such as authentication, account info, stuff you've done in your current session, etc).

> Suddenly, your once static carousel component isn't so static anymore and you have to add a bunch of JavaScript, and also state.

You're right, all of this is inherent to the problem as well, and you do need state. Generally, however, I haven't found a need for state to cross pages, which is a really good reducer of complexity (things are easier to reason about if every page load starts with a known state).

> Maybe I'm missing something here but pure React/Vue doesn't require your page to be an SPA or to have any routing mechanism at all?

They don't require it, but they make it easy, and that's the default that all frontend development pretty much starts with. Nobody says "hey, do we really need routing?". They start from "the way you make an app is with routing", and now you have a SPA where you just needed components. That's the big problem, and we've had a fair amount of issues with this...

> cross-page state (the one typically handled by backends, such as authentication, account info, stuff you've done in your current session, etc).

Yeah, that one is a different beast. We've been trying to keep it very simple in our SPAs lately: Account information & other backend data get retrieved from the backend upon page load (its all one big GraphQL query) and then it ends up in the GraphQL cache. If we then do a SPA-like soft page switch, that cache will speed up the next page's page load. However, the next page's GraphQL query will still be fired (it will likely need some other data that's not in the cache yet, anyway) which ensures the UI stays consistent with the backend state. In other words: The client-side cache is merely a mirror of the backend state and its presence or absence only affects loading behavior. There is no cross-page state beyond that (almost, see below).

> Generally, however, I haven't found a need for state to cross pages, which is a really good reducer of complexity (things are easier to reason about if every page load starts with a known state).

Agreed! If I do have a bit of client-only state which I'd like to persist (e.g. some kind of user selection / filter / …), then I simply encode it in the URL. Components then don't keep their own (mutable) copy of that state but simply mutate the URL to modify state. In that way, I end up with a one-to-one correspondence between URLs and UI states.

Yeah, that's a great way to do it, and that way your URLs always work properly as well. Maybe our frontend devs just need a bit more discipline...

I get it. And to be clear, I have seen SPAs that justified their existence. I just feel very strongly that for most of the apps I use on a regular, daily basis (email, messaging, newspapers, bank, etc), SPAs are just totally unnecessary.

A hill I will die on: the users NEVER asked for them. The UI community likes to pretend otherwise, but the users never asked for SPAs. What users want is the simplest, clearest and fastest possible experience, that changes only gradually and only when necessary. SPAs often stumble on simple and clear, and straight up explode on fast.

It seems that the pendulum of public opinion is swinging back towards simple, mostly HTML-based solutions, with the rise of intermediate solutions like htmx.

I don’t make sites like gov.uk or any random-user facing sites, but they are fast, frustrationless and “frontend”. I use them myself. Coming from desktop UIs (from most of them, and they are like 100x superior), writing 1.0 websites is a sort of bdsm to me. I actually avoided web programming before 2.0 became a thing.

I’m sure, and it will be hard to convince me otherwise, that it’s NOT a client model (thin client, thick client, mixed approaches) that is a source of your frustrations, but the amount of bullshit that “frontend developers” tend to serve to everyone including themselves and at the same time leave ends loose by e.g. never checking for errors or assuming incorrect lifetimes or phases of page loading.

If you just write a regular non-wEbApp app with js as a scripting lang and dom as a poor man’s ui lib, it works like any other ui app. All problems arise from trying to jump over the head to render empty frames 200ms faster out of total 12 seconds of loading.

My “stack” is mithril.js, bootstrap.css and just js runtime for “state”, for those curious. Yes, I manage “state” by storing it in js objects and transform it via assignment operators (shocking I know).

I started avoiding web programming after 2.0 became a thing, because it turned into an unmanageable time sink and usability nightmare, and it still is.

And I remember when 1.0 sites erased most of the form on an apparent mistake on my part and took ages to load aspx. There are facets in each version of web that we tend to see or ignore, but it’s clear that the common facet is poor and/or overcomplicated programming, not a paradigm itself.

It's not entirely the fault of developers that we are in this state, where they follow every "fad" (if it's a fad). People get paid better when they do modern tech, especially if they do slightly mundane work, e.g. apps that boil down to forms and CRUD, that have a lot of detail to get right, but aren't that challenging on its own (they often end up being). I remember about 10 years ago, I did a bit of Angular in some projects and there was a client that knew that and insisted I was working for them. I even heard my boss on the phone once saying "yes so and so is not the only one that does Angular". So I had it good just because I dabbled in tech that was hot at the moment. Other devs also want to be in that place so they follow the trends.

It is partially the fault of developers because they do their best to make this field what Alan Kay calls "pop culture and not really a field". I spent recently a lot of time questioning certain tools we use that I consider useless for us, but it's "standard" because someone else uses it and it spreads around because again you don't want to be left behind in your CV. For a lot of people the most important is to check all the tech boxes (spa, docker, kubernetes, cloud), but that the actual product is poor is less relevant. The outcomes are poor because a lot of this stuff is actually really hard, but if you take that approach it will take you forever to really master all the details of your craft. So instead you make it barely work on the happiest path and you've shipped your app as a full stack developer.

I don't know the solution, but articles like these are a good start.

I don't get it (really, not pretending). I know many SPAs are crap, but if SPAs were inherently crap, then all SPAs would be at least kind of crap.

So, I see those website below as examples and ask myself: What's wrong with those:

https://vitepress.dev/

https://www.solidjs.com/

Both are SPAs. Fast, small, working very well.

Ok, they need JS to work. But honestly, how many people are not using JS because they can't (as opposed to because they don't want to). And how many have so low end devices that running the JS is a problem? People watching videos all day on their smartphones. So, the days where processing JS for creating the DOM is a problem are over. Esp. if using fast frameworks like Solid, Preact, Vue or Svelte.

Of course there're website that load 20 MB JS of analytics and spyware. Those are slow not because they're SPAs but because they do all this additional (of course unwanted) stuff. Also accessibility issues are not caused by using SPAs or not. Svelte even has accessibility warnings built-in.

It's easy to make an SPA blow out of proportions and exponentially ruin UX.

Think cascading requests, you need to render a list of user saved posts, you fetch the list, then you fetch details for each item, then you render them (n+1 problem). In a simple SSR app even if you do some inefficient backend queries, the overhead is trivial compared to the equivalent SPA logic. This is just an example, but I think in general is way easier to screw up an SPA than it is to screw up an SSR site.

For medium to large projects, SPA or not basically boils down to the question where you want to manage the state and logic, is it at frontend(SPA) or backend(MVC,CRUD,etc), you still have to do that somewhere with complexity.

If the website is simple then definitely no SPA is needed, either htmx or alpinejs or vanilla can get the job done.

> you still have to do that somewhere with complexity

Don’t forget about the other “invisible” requirements with a JS solution — more tests, more code, longer builds, more 3rd party libraries.

or you have to test Model View and Controller at the backend, the backend can be messy as well over time, not to mention it has to sync with frontend team. it depends on team experience, e.g. stronger at backend or frontend and more importantly, how they work together.

Unless you're building a local first app (i.e. google sheets), the backend for most web apps is the source of truth. SPAs that lazy load tons of data on the frontend are introducing a lot of complexity trying to sync state between the frontend and backend.

Having a single source of truth by push things down into the backend is a godsend in terms of limiting complexity.

I love simple and accessible websites as much as everyone else, but I believe this leans way too much into extremity and dictates solutions instead of requirements.

JavaScript has appeared in 1995, it's now technically impossible to use a browser that doesn't support JS, because it will fail to load the website due to its old SSL/TLS stack, worrying about JS support is just insane.

Not using JavaScript doesn't give you accessibility by default, see: <a href="/121/"><img src="abcd.jpeg"></a>

The whole article feels like it was written my someone stuck in the early 2000s, you can make a well designed and accessible SPA. Using stone age technology should not be the goal, accessibility should be the goal.

The tax section of the gov.uk domain follows these guidelines and it's a mess, other pages can also be very difficult to use.

hopefully developers will start paying attention some day, if i see a webpage that renders blank with js off, i leave

I do the same for sentences starting in lower case and missing punctuation.

Great that government organisations are putting a break into the insanity of SPA frameworks for static content.

This is very good advice.

In the frontend dev land, there is a constant tension between user experience(UX) and developer experience(DX).

Providing good UX with HTML/CSS/Progressive enhancement usually means less-than-ideal DX. And good DX with JS frameworks tends to end up with less-than-ideal UX.

Poor DX usually results in slower development, thus devs are usually incentivized to prefer DX over UX.

The holy grail of good UX/DX requires exceptional developers whatever path you choose.

When even governments knows the web better than the tech industry by and large itself.

I despise React, ended up with Svelte+Typescript and now I realise that could do it all mostly with HTMX + templating with bit of alpine.js if at all.

Despise React's unnecessary complexity and non-standard-compliant non-separation-of-concerns squeeze-it-all-in-js approach as well.

Svelte(kit) is still the most W3C compliant of the major frameworks out there. Also, it's not even a runtime-framework but a compiler, meaning you're left with nothing but the necessary HTML, JS & CSS just relevant for your page.

Lit is also totally web standards compliant to be fair.

React in the hook's era has gotten overly complex. The cods is unreadable and hard to reason about. Check any longer/complicated component as an example riddled with hooks.

Comparatively, Svelte has a much simpler mental model and at the end, leaves nothing but basic plain old javascript.

But I tend to question these days that do we need this much Javascript?

Mostly for reactive rendering in response to incoming small data packets (or user supplied changes) mutating state.

I have not seen an example of how to do that using vanilla HTML and CSS without some JavaScript support. Maybe it exists and I haven't come across it.

>Svelte(kit) is still the most W3C compliant of the major frameworks out there. Also, it's not even a runtime-framework but a compiler, meaning you're left with nothing but the necessary HTML, JS & CSS just relevant for your page.

I'd argue that it's way easier to master the internals of a library than a whole bespoke compiler.

I suspect when you specify “100% availability to the public” then even the most React-ionary devs will soon realize they will have to go down this alley since they have to handle browsers with javascript turned off.

Can Gov.uk become the new W3C? Pretty please?

You mean the new WHATWG.

This advise may have been correct for old-school SPAs, but most if not all points should be fixed in the current generation. E.g. first page load is static or SSR, and then the page is hydrated as a accessible SPA including url manipulation. Also automatic a no-js fallbacks are provided with many.

Having to deploy a dedicated server unit to render your frontend is a lot of additional complexity for zero benefit when you still require an API server to actually drive everything.

Have your API server render the HTML itself and your entire stack becomes radically simpler. Iteration speed goes through the roof.

If you're not building Google Sheets, skipping the entire SPA universe provides massive benefits with no notable downsides. The same UX can be provided either way but often with improved performance which actually means a better UX

Why bring in all that extra complexity in the first place, even if it works?

Unless there's a good reason to, like long-lived sessions or a complex, updating UI, then I can't think of a reason to send a truckload of js to the user that eats through their CPU like a baby eats through a tub of icecream.

Not everyone in the world is sporting the newest MacBook and iPhone. Hell, I'm using a pixel 8 and some sites or components take _seconds_ to load (eg. Twitter search drop-down).

Yeah— I was thinking the article was not being fair. That said, try using a website across a wide variety of browsers and os and you will get a wide variety of interpretations. Since it’s a government website that is not acceptable.

I am definitely one that believes the fronted is way too complicated.

That said, however, there is a list of four inaccessibilities in the article, and I was thinking that spas have work around for these.

I’ve helped build significant portions (nearly all, technically speaking) of a few small US government services through contracts, so I’ll share my opinion although I realize US government agencies may be a bit different than those in the UK government.

In the US, tech you can deploy varies significantly agency to agency. In my case they were using a dated PHP CMS and we’d have to go through significant efforts and sign offs to get our own simple RDBMs in place on their services. Deploying to cloud infrastructure also was filled with red tape, especially for small applications. Internally they had little experience so forget just spinning up and hosting some AWS service. Then there’s costs, it’s not that such services might be too costly so to speak but money has color in the government and money to build the application is often a different color, maybe entirely different group, than those who will maintain it. So deployment/transfer for handoff is pretty much a nightmare, yet agencies often want (for good reason I’d say) full ownership of the application and surrounding infrastructure.

Stakeholders pop up from the agency your working with and any sort of collaborations between other agencies they’re trying to leverage, then if you have your own organization you end up with a superset of “idea makers” from a couple agencies and your own coming up with “wouldn’t it be nice” features from what otherwise should be a simple application.

Ultimately for deployment to arbitrary infrastructure and maintenance, SPAs simplify a lot if you absolutely need dynamic content and absolutely struggle to get real server side service infrastructure (eg most government organizations from my experience). So you pack as much complexity as you can into JS because it can somewhat take it, and you rely on user browsers to pickup the slack. This only goes so far of course, as there’s only so much you can do in an SPA that actually runs on a lot of devices but needs some real application functionality, so think small desktop applications, wizards, small computational models (a lot of what I do), etc.

So SPAs are the land I’ve been pushing in this space, no matter how much I loathe them in general, they’re one of the best fits for the constraints in these environments (which is why they get them a lot).

There are bad sever side apps and “single page apps”.

Ok but let's not deify gov.uk. Yes it's very good compared to most government websites but it's not the peak of web design. They are so anally averse to any form of JavaScript or interactivity that often the web pages become quite tedious to use, e.g. when picking dates for payments, they don't have a "tomorrow" button even though that's what you want 99.999% of the time because that would need the dreaded JavaScript.

There is no need for JavaScript for a Tomorrow button.

Personally I'd always want "today", never "tomorrow".

So now we have two extra buttons on the form.

And perhaps the extensive user testing that gov.uk do would discover that for most people this added UI complexity makes the form less usable than keeping it as simple as possible.

Today isn't an option for the form I'm thinking of (tax free childcare); you can't set up payments for the same day. Really you want "asap" but I was simplifying for discussion.

I agree the tax-free childcare form could certainly be improved (I've even written a script to do the three-monthly reconfirmation for me, see my latest gist, though that's policy rather than tech!), but you can set up payments for the same day, you put today's date in (that is what I do; it gives a "You've asked for a payment of £x to be made to [site] today" extra confirmation step). There's nothing in the service manual page that says they couldn't enhance this form with a button as you're suggesting, and hopefully one day they will, though you're always actually worrying it could get worse...

They can have whatever rules they want, but for what it's worth there's nothing about SPAs that makes those four bullet points a reason not to do them. You can write an SPA that is accessibility friendly, maintains focus, and respects the back button.

But, when you were writing one you do take on all of those responsibilities as the author. You are substituting the browser's standard behaviors with behaviors of your own choice.

> If your JavaScript uses a syntax or calls an API that is not supported in the user’s browser, it will error …

Pet peeve: when did “to error” become a verb?

Otherwise, I wish the rest of the web were designed this way.

it depends which release of the english language you are using

Amen. Amen. Amen.

In Germany, a government service is considered digital when there is an online form where you can enter the data. Afterward, it doesn't matter if you must print it out and send it via postal services (no kidding); all that is required is an online form.

I don't know why many HN users don't like SPAs but I don't know any sites where I have a problem with it from a user perspective. IMHO there are far more badly designed sites. From a developer side it is a completely different story, due to the added complexity and I get it if someone doesn't want to build an SPA/PWA.

However, I would take any SPA any day, compared to what the German government offers...

I on the contrary applaud whoever built the new citizenship application form as HTML. It saved state money and users time. I’m quite sure it would have taken longer and worked worse if it was a SPA built by the gov. contractors.

But what value does an HTML form alone have? Compared to the old offline version, you have more trouble authenticating before filling it out (which isn't worth anything because you have to sign it anyway...).

Reply on news.ycombinator.com