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

131–140 of 168 posts

Re: Building a robust frontend using progressive enhancement

#131

Post by dracos »

IshKebab wrote: post #129
philgyford wrote: post #104

Earlier quoted context omitted.

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.

I agree the tax-free childcare form could certainly be improved (I've even written a script to do the three-monthly reconfirmation for me, see my latest gist, though that's policy rather than tech!), but you can set up payments for the same day, you put today's date in (that is what I do; it gives a "You've asked for a payment of £x to be made to [site] today" extra confirmation step). There's nothing in the service manual page that says they couldn't enhance this form with a button as you're suggesting, and hopefully one day they will, though you're always actually worrying it could get worse...

Re: Building a robust frontend using progressive enhancement

#132

Post by eddd-ddde »

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.

Then why hire front end devs for a project that doesn't need one?

Probably 80% of websites could do with a good designer that knows how to get their designs from concept to CSS and a good backend engineer that know how to output decent markup.

Re: Building a robust frontend using progressive enhancement

#133

Post by stavros »

eddd-ddde wrote: post #132
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.

Then why hire front end devs for a project that doesn't need one? Probably 80% of websites could do with a good designer that knows how to get their designs from concept to CSS and a good backend engineer that know how to output decent markup.

Because someone needs to turn the concept to browser-ready, responsive, cross-browser, lightweight markup, and that person is a developer who specializes in the frontend, ie a frontend developer.

Re: Building a robust frontend using progressive enhancement

#134

Post by bdangubic »

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

or be stateless… ;)

Re: Building a robust frontend using progressive enhancement

#135

Post by bdangubic »

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…

after you re-write it (either immediately or with time) you will end up with the same thing, just a different kind of soup. using vanilla-whatever you will eventually notice you are doing “X” over and over again and then you’ll start writing small libraries (or even worse, some internal “framework”) which over time will get stale or will get bunch of features from devs that need “just that plus a few more things..” ad infinitum…

Re: Building a robust frontend using progressive enhancement

#136

Post by imacrayon »

ksec wrote: post #128
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.

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.

There’s a draft proposal to get some of HTMX in the browser: https://github.com/alexpetros/triptych

Re: Building a robust frontend using progressive enhancement

#137

Post by gryzzly »

arendtio wrote: post #73

In 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 design…

I on the contrary applaud whoever built the new citizenship application form as HTML. It saved state money and users time. I’m quite sure it would have taken longer and worked worse if it was a SPA built by the gov. contractors.

Re: Building a robust frontend using progressive enhancement

#138

Post by avaldez_ »

mentalgear wrote: post #10
wg0 wrote: post #6

When even governments knows the web better than the tech industry by and large itself. I despise React, ended up with Svelte+Typescript and now I realise that could do it all mostly with HTMX + templating with bit of alpine.js if at all.

Despise React's unnecessary complexity and non-standard-compliant non-separation-of-concerns squeeze-it-all-in-js approach as well. Svelte(kit) is still the most W3C compliant of the major frameworks out there. Also, it's not even a runtime-framework but a compiler, meaning you're left with nothing but the necessary HTML, JS & CSS just relevant for your page.

>Svelte(kit) is still the most W3C compliant of the major frameworks out there. Also, it's not even a runtime-framework but a compiler, meaning you're left with nothing but the necessary HTML, JS & CSS just relevant for your page.

I'd argue that it's way easier to master the internals of a library than a whole bespoke compiler.

Re: Building a robust frontend using progressive enhancement

#139

Post by paulddraper »

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.

An SSR site needs to have full stack devs, not front end devs.

Else you will have exactly this problem

Re: Building a robust frontend using progressive enhancement

#140

Post by nfw2 »

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

The OP was asking for an explanation why the preferences of the industry diverge from the preferences of this comment section. The question itself identifies two groups.

The top comment on this page said the frontend community seems like a jobs program. It's interesting that you are only criticizing the view you disagree with as being too divisive.

Post reply on HN