Live data from Hacker News

Building a robust frontend using progressive enhancement

gov.uk

41–50 of 168 posts

Re: Building a robust frontend using progressive enhancement

#41

This advise may have been correct for old-school SPAs, but most if not all points should be fixed in the current generation. E.g. first page load is static or SSR, and then the page is hydrated as a accessible SPA including url manipulation. Also automatic a no-js fallbacks are provided with many.

Yeah— I was thinking the article was not being fair. That said, try using a website across a wide variety of browsers and os and you will get a wide variety of interpretations. Since it’s a government website that is not acceptable.

Re: Building a robust frontend using progressive enhancement

#44

> If you use a JavaScript framework you should: > > be able to justify with evidence, how using JavaScript would benefit users Steady on, guys.

for real, do you want swarms of developers to lose their jobs because software complexity collapsed?

Re: Building a robust frontend using progressive enhancement

#45

This advise may have been correct for old-school SPAs, but most if not all points should be fixed in the current generation. E.g. first page load is static or SSR, and then the page is hydrated as a accessible SPA including url manipulation. Also automatic a no-js fallbacks are provided with many.

[deleted]

Re: Building a robust frontend using progressive enhancement

#46

I started web stuff in the 90s as a child. I didn't know what CSS or JS were, except the latter you could copy/paste some magic scripts to make things flash and suchlike. Later I built dynamic sites with PHP for local businesses. I learnt JS and CSS at this point (to some extent as least). Then I decided to quit web development because I couldn't stand spending so much time things to work with the shittiest browser a…

Similar experience.

Started with html 3.2/xhtml and css as a kid. Some years later got a job and did Django + jQuery, but found myself drawn into infra. A year ago I worked alongside a web dev team and decided to peek into their work--nothing made sense anymore. The amount of complexity was staggering. It seemed like they spent most of their time managing that complexity, eg. reducing build times, solving dependency problems, solving weird TS issues, handling errors in different components, etc.

In the Django+jQuery days, the emphasis was still always on what user got to see and use.

Re: Building a robust frontend using progressive enhancement

#47

I started web stuff in the 90s as a child. I didn't know what CSS or JS were, except the latter you could copy/paste some magic scripts to make things flash and suchlike. Later I built dynamic sites with PHP for local businesses. I learnt JS and CSS at this point (to some extent as least). Then I decided to quit web development because I couldn't stand spending so much time things to work with the shittiest browser a…

I'd argue that doing client validation saves your server from superfluous requests just to validate that your username input has less than 16 characters. Of course, you later still do it in the server again because you can't never trust the clients

Reducing server workload is useful

Re: Building a robust frontend using progressive enhancement

#49
A good rule of thumb is: if your app can/could run offline-first like a desktop app, it's ok to make it a single-page application. They can be snappier and better than a multi-page browser app. Examples would be stuff like Photopea, Google Docs/Sheets, tldraw, etc.

This way, the biggest downsides (moving between pages & requiring an internet connection) are eliminated.

But if your app requires an internet connection and multiple pages, it's better to let the browser handle navigation in a fault-tolerant way.

Post reply on HN