Can Gov.uk become the new W3C? Pretty please?
Building a robust frontend using progressive enhancement
91–100 of 168 posts
Re: Building a robust frontend using progressive enhancement
#92Why is Linux not in this list: https://www.gov.uk/service-manual/technology/designing-for-d...
Less than 2% of users?
Re: Building a robust frontend using progressive enhancement
#93For 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.
Re: Building a robust frontend using progressive enhancement
#94Genuine 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?
There's no cost to building slow, fragile, and inefficient websites.
When you build programs that run on _your_ computers, you have to pay for that. Or at least have to deal with the finance folks asking why your cloud spend increased 5%.
But if you run your software on other people's devices, like frontend devs do, there's barely any cost to that. Any negative signals need to trickle in through user reports, support tickets, and maybe Twitter posts. There's a ton of selection going on there so you're likely not getting the full picture.
Ie. It's all about incentives
Re: Building a robust frontend using progressive enhancement
#95Can Gov.uk become the new W3C? Pretty please?
You mean the new WHATWG.
Re: Building a robust frontend using progressive enhancement
#96Why is Linux not in this list: https://www.gov.uk/service-manual/technology/designing-for-d...
The flippant answer: because it's a kernel.
The non-flippant answer that is related to the flippant answer: because there are dozens of distros and within those distros about a dozen browsers if you factor in all of the Mozilla forks. They could probably choose a blessed one, but any individual blessed one turns out to have an incredibly small user base (Even Ubuntu, to the extent that numbers can be generated as a secondary signal, looks to be about 1% desktop OS share).
Re: Building a robust frontend using progressive enhancement
#97Earlier quoted context omitted.
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”.
This translation guide is usually helpful.
https://polish2english.files.wordpress.com/2011/11/55551980-...
I'm afraid I don't know what RFC English is and neither does Google.
Re: Building a robust frontend using progressive enhancement
#98Genuine 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.
How is increased FCP, LCP, ttvc better ux and DX? We've had hard data that decreasing page load time make for better user experience[0].
Please don't make this an Us vs. Them thing.
[0]: http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....
Re: Building a robust frontend using progressive enhancement
#99Earlier quoted context omitted.
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”.
To be fair, here is the RFC meaning:
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Re: Building a robust frontend using progressive enhancement
#100OMG 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.
> I can't win this battle
You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire.
The bad way to do it: "You made a single page app with PHP and {other tech} and {database}! I hate those! Don't you read (reddit, twitter, hacker news)? Best practices say..."
The good way to do it: "Our users often share links within the application with each other to navigate and the new single page app you demoed doesn't allow that."
Or: "While the page load times look great on the metrics in your power point, as everything is lazy loaded it takes 10 seconds for the page to actual become usable, the old site loaded in under a second why are we regressing the user experience here?"
Or the evergreen: "What does that buy us?"