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

101–110 of 168 posts

Re: Building a robust frontend using progressive enhancement

#101

Post by arp242 »

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.

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 spare time to show it can be done and that it'll be quite nice.

Re: Building a robust frontend using progressive enhancement

#102

Post by simmerup »

endemic wrote: post #84
andrepd wrote: post #59

Earlier quoted context omitted.

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.

And also screw up the browsers back functionality in the process

Re: Building a robust frontend using progressive enhancement

#103

Post by hakanderyal »

In the frontend dev land, there is a constant tension between user experience(UX) and developer experience(DX).

Providing good UX with HTML/CSS/Progressive enhancement usually means less-than-ideal DX. And good DX with JS frameworks tends to end up with less-than-ideal UX.

Poor DX usually results in slower development, thus devs are usually incentivized to prefer DX over UX.

The holy grail of good UX/DX requires exceptional developers whatever path you choose.

Re: Building a robust frontend using progressive enhancement

#104

Post by philgyford »

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.

Re: Building a robust frontend using progressive enhancement

#106

Post by stavros »

willcipriano wrote: post #100
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.

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

This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way.

Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component".

How many developers do you think heed those warnings?

Re: Building a robust frontend using progressive enhancement

#107

Post by shadowgovt »

dariusj18 wrote: post #75
slashdave wrote: post #51

Earlier quoted context omitted.

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.

That's one dream. There are advantages to thick clients as well... less network traffic if the device can do processing on site, A much easier to maintain and update distribution model over the traditional desktop experience for what is essentially application software, etc.

Re: Building a robust frontend using progressive enhancement

#108

Post by stavros »

arp242 wrote: post #101
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.

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

Re: Building a robust frontend using progressive enhancement

#109

Post by shadowgovt »

mrthrowaway999 wrote: post #98
nfw2 wrote: post #56

Earlier quoted context omitted.

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

Because we also have hard data that users absolutely hate a blank or frozen screen and "CONFIRM FORM RESUBMISSION." Users are allowed to hate multiple things at the same time and it's up to the web developers to stack rank those.

Re: Building a robust frontend using progressive enhancement

#110

Post by j45 »

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.

Things like Livewire, and alpine.js are showing simpler ways.

You can build a SPA SSR as well.

Post reply on HN