Do not build your Gov.uk service as a single-page application

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

Steady on, guys.

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.

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.

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

I wish the whole internet followed this advice.

What’s old is new again.

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

Why is Linux not in this list:

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

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?

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

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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