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

141–150 of 168 posts

Re: Building a robust frontend using progressive enhancement

#141

Post by stavros »

paulddraper wrote: post #139
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.

An SSR site needs to have full stack devs, not front end devs. Else you will have exactly this problem

An SSR site needs a frontend dev to produce the HTML/CSS/JS and a backend dev to provide the template variables. You don't need a developer to do both when the interface is so small.

Re: Building a robust frontend using progressive enhancement

#142

Post by nfw2 »

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

> Companies know what is best for their business. "Companies" don't really know anything. The decisions get made by people, with all the flaws that people have. I have seen many developers make decisions that are detrimental to the company. I do agree that there is a section of HN that will pile on these kind of topics, and I have flagged dozens of low-effort swiped against JS over the years that add nothing. But two…

I agree there are tradeoffs to SPAs, and I shouldn't have implied that companies are a perfect decision-making apparatus.

That said, I think if a certain technology becomes an industry standard, especially one that demonstrates some staying power, as React has, it should not be dismissed out-of-hand, and most of this comments section is doing.

Re: Building a robust frontend using progressive enhancement

#143

Post by EasyMark »

fouronnes3 wrote: post #22
pensatoio wrote: post #4

I wish the whole internet followed this advice.

We could shutdown a few dozen powerplants easy.

Wait until you hear about the next big thing, AI compute centers, and those plant shutdowns will be a drop in the ocean…

Re: Building a robust frontend using progressive enhancement

#144

Post by arendtio »

gryzzly wrote: post #137
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.

But what value does an HTML form alone have? Compared to the old offline version, you have more trouble authenticating before filling it out (which isn't worth anything because you have to sign it anyway...).

Re: Building a robust frontend using progressive enhancement

#145

Post by EasyMark »

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?

I think it’s a nice idea, but given the bean-counting-efficiency-experts that run the company, this will never fly “build for the 90-95%” is what I constantly heard from bosses before I left frontend and went to backend, and eventually leaving the cloud industry all together. I can see it working for government sites though because profit isn’t the sole purpose of the website, it’s more there to serve the public as a whole.

Re: Building a robust frontend using progressive enhancement

#146

Post by EasyMark »

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.

I suspect when you specify “100% availability to the public” then even the most React-ionary devs will soon realize they will have to go down this alley since they have to handle browsers with javascript turned off.

Re: Building a robust frontend using progressive enhancement

#147

Post by valley_guy_12 »

etothepii wrote: post #97
randomifcpfan wrote: post #77

Earlier quoted context omitted.

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.

Huh, for me the very first non-ad result for googleing RFC English is https://en.wikipedia.org/wiki/Request_for_Comments, which is the correct citation.

Re: Building a robust frontend using progressive enhancement

#148

Post by valley_guy_12 »

layer8 wrote: post #99
randomifcpfan wrote: post #77

Earlier quoted context omitted.

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. It means you can’t simply ignore it, and instead have to have compelling reasons to justify any deviation.

Unfortunately, in many organizations, "the library we use doesn't follow this recommendation" is a valid compelling reason. Which means that in practice "SHOULD" effectively means "WOULD BE NICE IF".

Re: Building a robust frontend using progressive enhancement

#149

Post by codethief »

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.

> could be a simple SSR site, but frontend devs don't like writing anything but SPAs

It might be worth asking why that is.

I used to write a ton of SSR'ed pages back when that was really the only option we had (before people introduced jQuery and AJAX), then I wrote SPAs (mostly Angular & React), then again SSR'ed websites (Java/Spring/JSP with a ton of more-or-less vanilla JavaScript) and now I've been on a Vue-based stack (w/ Astro/Vite for SSR) for a number of years. And these were all applications with dozens of teams working on them in parallel and a corresponding number of components & LoC.

Personally, I wouldn't want to go back to traditional SSR stacks (Spring/JSP, vanilla PHP, or Python w/ Django or Flask) ever. People often vastly underestimate the complexity of good UIs. They might start simple ("could be a simple SSR site", as you say) and, before long, the wheels come off the bus and they look at a big unmaintainable ball of vanilla JS on top of HTML templates that are directly coupled to the database schema, with global CSS styles permeating (infecting) the entire code base.

In my experience, there is a certain amount complexity that is inherent to a good UI. It doesn't matter whether you use classic SSR, or modern frontend frameworks like Angular/React/Vue/Svelte/SolidJS, or new kids on the block like HTMX/Turbo/… — that complexity will still be there. However, with modern frameworks you've at least got a chance to tame that beast.

More specifically, what modern frontend frameworks give us is: 1) Modularization into components, 2) scoping of styles, 3) type-safety, 4) unit-testability of components, 5) component-local state management (≠ insanities like Redux), 6) clear separation between view/UI logic and business logic.

If you can replicate these features using a bespoke version of JSP or HTMX or whatever, great! But if you can't, I'd personally rather pick a well-established frontend framework like React or Vue. Yes, your developers might still mess that up and produce shitty code, but the chances of them messing up in a classic SSR stack (without the aforementioned features) are so much greater.

Re: Building a robust frontend using progressive enhancement

#150

Post by WuxiFingerHold »

I don't get it (really, not pretending). I know many SPAs are crap, but if SPAs were inherently crap, then all SPAs would be at least kind of crap.

So, I see those website below as examples and ask myself: What's wrong with those:

https://vitepress.dev/

https://www.solidjs.com/

Both are SPAs. Fast, small, working very well.

Ok, they need JS to work. But honestly, how many people are not using JS because they can't (as opposed to because they don't want to). And how many have so low end devices that running the JS is a problem? People watching videos all day on their smartphones. So, the days where processing JS for creating the DOM is a problem are over. Esp. if using fast frameworks like Solid, Preact, Vue or Svelte.

Of course there're website that load 20 MB JS of analytics and spyware. Those are slow not because they're SPAs but because they do all this additional (of course unwanted) stuff. Also accessibility issues are not caused by using SPAs or not. Svelte even has accessibility warnings built-in.

Post reply on HN