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!
Building a robust frontend using progressive enhancement
71–80 of 168 posts
Re: Building a robust frontend using progressive enhancement
#72OMG 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, 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).
Re: Building a robust frontend using progressive enhancement
#73In 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...
Re: Building a robust frontend using progressive enhancement
#74Why is Linux not in this list:
https://www.gov.uk/service-manual/technology/designing-for-d...
Re: Building a robust frontend using progressive enhancement
#75Genuine 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.
Re: Building a robust frontend using progressive enhancement
#76Genuine 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?
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 gleefully enthuse about here. As a coder it's super cool.
Re: Building a robust frontend using progressive enhancement
#77“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”.
Re: Building a robust frontend using progressive enhancement
#78OMG 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.
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.
Re: Building a robust frontend using progressive enhancement
#79Ok 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.
Re: Building a robust frontend using progressive enhancement
#80Genuine 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 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.