Live data from Hacker News

Building a robust frontend using progressive enhancement

gov.uk

61–70 of 168 posts

Re: Building a robust frontend using progressive enhancement

#61

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

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.

Re: Building a robust frontend using progressive enhancement

#62
post #42

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

Re: Building a robust frontend using progressive enhancement

#63
post #52

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.

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”

Re: Building a robust frontend using progressive enhancement

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

Re: Building a robust frontend using progressive enhancement

#65
post #52

Earlier quoted context omitted.

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.

Re: Building a robust frontend using progressive enhancement

#66
post #38

> 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

Re: Building a robust frontend using progressive enhancement

#67
post #49

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…

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.

Re: Building a robust frontend using progressive enhancement

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

Re: Building a robust frontend using progressive enhancement

#69
post #42

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?

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)

Re: Building a robust frontend using progressive enhancement

#70
post #42

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?

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.
Post reply on HN