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

121–130 of 168 posts

Re: Building a robust frontend using progressive enhancement

#121

Post by Frost1x »

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…

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.

Re: Building a robust frontend using progressive enhancement

#122

Post by redman25 »

stavros wrote: post #108
arp242 wrote: post #101

Earlier quoted context omitted.

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

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.

Re: Building a robust frontend using progressive enhancement

#123

Post by tarsinge »

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…

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.

Re: Building a robust frontend using progressive enhancement

#124

Post by andyjohnson0 »

andyjohnson0 wrote: post #117
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?

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

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.

Re: Building a robust frontend using progressive enhancement

#125

Post by Frost1x »

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

Re: Building a robust frontend using progressive enhancement

#126

Post by redman25 »

synergy20 wrote: post #58

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.

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.

Re: Building a robust frontend using progressive enhancement

#127

Post by synergy20 »

endemic wrote: post #93
synergy20 wrote: post #58

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.

Re: Building a robust frontend using progressive enhancement

#128

Post by ksec »

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

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.

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.

Re: Building a robust frontend using progressive enhancement

#129

Post by IshKebab »

philgyford wrote: post #104
IshKebab wrote: post #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…

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.

Re: Building a robust frontend using progressive enhancement

#130

Post by voidr »

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:

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.

Post reply on HN