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

151–160 of 168 posts

Re: Building a robust frontend using progressive enhancement

#151

Post by willcipriano »

stavros wrote: post #120
willcipriano wrote: post #116

Earlier quoted context omitted.

> heed those warnings It's not a warning. It's a functional requirement that you put into the ticket. The project isn't done if the rewritten page takes longer to load than the old one did. Don't ship it, don't pay bonuses based on shipping it.

Please read my comment more carefully, you're being patronizing. I can't put "I want feature development on this codebase to be faster than two sprints in six years" in the requirements.

Sounds like you should talk to the person who is actually in charge then.

Re: Building a robust frontend using progressive enhancement

#152

Post by arp242 »

bdangubic wrote: post #135
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…

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..” a…

This is simply not true, and has never been true anywhere I've worked. We can do everything with a much better UX in about 2,000 to 3,000 lines of code, instead of ~25,000 (and almost 2,000 dependencies).

It's a boring tedious "true-ism" that keeps getting pounded. I don't really know what else to say, but it's simply just not true.

Re: Building a robust frontend using progressive enhancement

#153

Post by stavros »

willcipriano wrote: post #151
stavros wrote: post #120

Earlier quoted context omitted.

Please read my comment more carefully, you're being patronizing. I can't put "I want feature development on this codebase to be faster than two sprints in six years" in the requirements.

Sounds like you should talk to the person who is actually in charge then.

I'll have a chat with the mirror.

Re: Building a robust frontend using progressive enhancement

#154

Post by bdangubic »

arp242 wrote: post #152
bdangubic wrote: post #135

Earlier quoted context omitted.

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..” a…

This is simply not true, and has never been true anywhere I've worked. We can do everything with a much better UX in about 2,000 to 3,000 lines of code, instead of ~25,000 (and almost 2,000 dependencies). It's a boring tedious "true-ism" that keeps getting pounded. I don't really know what else to say, but it's simply just not true.

What is the longest you have ever worked on a single piece of software? If you are in some sort of consultancy or jump jobs every 2-3 years it most definitely won't be true. You stay with a product for 5+ years it is bound to happen unless your dev shop is like 10 people. If you think this is not true AND have spent 5+ years with the same piece of software you are an outlier...

Re: Building a robust frontend using progressive enhancement

#155

Post by eddd-ddde »

WuxiFingerHold wrote: post #150

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 (a…

It's easy to make an SPA blow out of proportions and exponentially ruin UX.

Think cascading requests, you need to render a list of user saved posts, you fetch the list, then you fetch details for each item, then you render them (n+1 problem). In a simple SSR app even if you do some inefficient backend queries, the overhead is trivial compared to the equivalent SPA logic. This is just an example, but I think in general is way easier to screw up an SPA than it is to screw up an SSR site.

Re: Building a robust frontend using progressive enhancement

#156

Post by paulddraper »

stavros wrote: post #141
paulddraper wrote: post #139

Earlier quoted context omitted.

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.

Nah that's crazy man

Re: Building a robust frontend using progressive enhancement

#157

Post by stavros »

codethief wrote: post #149
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.

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

You're arguing against something different, though: I agree you shouldn't do components with CSS/jQuery, components should be self-contained. I'm arguing against SPAs, where the state of the user's browsing is replicated on the frontend as well, with all the complexity this entails.

Isn't there a good component framework we can use, and that's it? I want to be able to say and have it work, without having to have a whole SPA attached to my components library, with routing, state, and all the rest. Doesn't that exist?

Re: Building a robust frontend using progressive enhancement

#158

Post by arp242 »

nfw2 wrote: post #142
arp242 wrote: post #118

Earlier quoted context omitted.

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

There are probably more companies not using React than are. Words like "industry standard" don't really mean much. Languages like Ruby or Go are widely used and here to stay, yet there are also many people who don't like it – and that's okay.

There's a lot of self-sorting going on here; I stopped doing the frontend thing because I didn't like the way things were going and even tepid critique of this was (and still is) often met with completely out of proportion aggression, vitriol, and insults. I got more hate and vitriol over my "Why I'm using jQuery in 2018" post than the rest of my website combined. It feels like engaging on the Israel/Palestine debate or something.

Of course every community self-sorts to a degree. That's okay. I would never presume to critique React on a React thread. But "frontend" is very broad and also includes non-React.

Your comments here are fine, but at the same time it also strongly suggests that SPAs are the only way to build good frontends and that everyone who disagrees is just some old coot stuck in their ways. Both of which are rather tiring tropes, and especially that second one is pretty dismissive, if not downright insulting.

So I kind of gave up on this years ago. It's easy to reach consensus if you chase away everyone who disagrees.

Re: Building a robust frontend using progressive enhancement

#159

Post by etothepii »

valley_guy_12 wrote: post #147
etothepii wrote: post #97

Earlier quoted context omitted.

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.

For me it was to do with Rugby Football.

Re: Building a robust frontend using progressive enhancement

#160

Post by derangedHorse »

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?

Because most websites today are more than just informational. Some web apps facilitate complex user interactions which typically require a lot of state which are the raison d'etre of web frameworks.
Post reply on HN