Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a robust frontend using progressive enhancement

gov.uk

Post reply on HN
Print view View original

81–90 of 168 posts

Re: Building a robust frontend using progressive enhancement

#81

Post by layer8 »

wruza wrote: post #72
projectileboy wrote: post #9

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.

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, t…

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.

Re: Building a robust frontend using progressive enhancement

#82

Post by shadowgovt »

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.

Re: Building a robust frontend using progressive enhancement

#83

Post by [deleted] »

nonrandomstring wrote: post #76
entuno wrote: post #53

Earlier quoted context omitted.

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 wh…

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 g…

[deleted]

Re: Building a robust frontend using progressive enhancement

#84

Post by endemic »

andrepd wrote: post #59
simmerup wrote: post #8

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

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.

Re: Building a robust frontend using progressive enhancement

#85

Post by mrthrowaway999 »

joseferben wrote: post #44
bigfatkitten wrote: post #3

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

Re: Building a robust frontend using progressive enhancement

#86

Post by sscarduzio »

icedchai wrote: post #29
Elfener wrote: post #20

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

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?”

Re: Building a robust frontend using progressive enhancement

#87

Post by layer8 »

WA wrote: 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…

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

Re: Building a robust frontend using progressive enhancement

#88

Post by stavros »

dazzawazza wrote: post #78
stavros wrote: 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.

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 complexi…

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.

Re: Building a robust frontend using progressive enhancement

#89

Post by _dain_ »

dtech wrote: post #57
ksynwa wrote: 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?

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!

Re: Building a robust frontend using progressive enhancement

#90

Post by wruza »

layer8 wrote: post #81
wruza wrote: post #72

Earlier quoted context omitted.

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, t…

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