|
|
|
|
|
|
by madeofpalk
2981 days ago
|
|
|
You in Australia? We built 9now.com.au using a degree of ‘progressive enhancement’ thanks to server-side react. I left a while ago, but Normally, users get a single-page-app-like complete with prefetching to instantly display subsequent pages. Turn JS off and it ‘degrades’ into a typical server-rendered experience. Sure, get far enough in and some things will break (videos won’t play), but we were pretty happy about this degrading nicely. We built Qantas’s in flight wifi portal using this same technique, a necessity to deal with providing users with an instant ‘web’ experience over a high-latency connection. Toy sites or for academics? Hardly. |
|
|
You gave two examples, one of which didn't even work correctly when regressed ("videos won’t play") and the other is effectively a toy site (login/terms of service portal).
When you're in the weeds developing complex data entry sites for large companies or government, you aren't going to write the page three times progressively, write three sets of tests, run userability & accessibility studies three times, and maintain all three for tens of years with bug fixes/enhancement.
What you're going to do is lock in your library requirements, and if the library failed to load you're just going to fast fail into a generic error message until the library is available. If for no other reason that it isn't financially feasible to do anything else.
Progressive enhancement of JavaScript libraries was dead the second we went to SPAs and had a library hold the page's data context/scope instead of writing web pages using HTML forms and refreshing every time you click.