I wish the whole internet followed this advice.
We could shutdown a few dozen powerplants easy.
Great idea, more capacity for LLMs!
/s
Building a robust frontend using progressive enhancement
31–40 of 168 posts
Re: Building a robust frontend using progressive enhancement
#32Amen. Amen. Amen.
Re: Building a robust frontend using progressive enhancement
#33Good advice, but > - users of assistive technology would be unaware of changes in context, for example when moving to a new page > - it would fail to handle focus when moving between pages > - the user would be unable to navigate using the back or forward buttons in their browser > - users would be unable to recover from an error, for example if there is an interruption to their network connection These aren’t strict…
How could you possibly make them true, if you are told to respect even deliberately disabled features? If the user does not permit retroactively messing with their navigation history, then you are left with only one option: get the history right, at the time it is written.
Re: Building a robust frontend using progressive enhancement
#34What’s old is new again. Maybe we should prioritize the simplest possible solution rather than what’s trendy today.
Not really. The UK government has never supported the use of JavaScript in its web services and has heavily invested in design systems which use html and css with accessibility at their core.
Just because the rest of the industry has been high on JS doesn’t mean everyone has.
Re: Building a robust frontend using progressive enhancement
#35Singe page apps suck arse. This really isn't news to anyone, except for those who make money by developing that garbage.
Re: Building a robust frontend using progressive enhancement
#36This 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.
Why bring in all that extra complexity in the first place, even if it works?
Unless there's a good reason to, like long-lived sessions or a complex, updating UI, then I can't think of a reason to send a truckload of js to the user that eats through their CPU like a baby eats through a tub of icecream.
Not everyone in the world is sporting the newest MacBook and iPhone. Hell, I'm using a pixel 8 and some sites or components take _seconds_ to load (eg. Twitter search drop-down).
Re: Building a robust frontend using progressive enhancement
#37I am definitely one that believes the fronted is way too complicated.
That said, however, there is a list of four inaccessibilities in the article, and I was thinking that spas have work around for these.
Re: Building a robust frontend using progressive enhancement
#38> If your JavaScript uses a syntax or calls an API that is not supported in the user’s browser, it will error …
Pet peeve: when did “to error” become a verb?
Otherwise, I wish the rest of the web were designed this way.
Re: Building a robust frontend using progressive enhancement
#39Good advice, but > - users of assistive technology would be unaware of changes in context, for example when moving to a new page > - it would fail to handle focus when moving between pages > - the user would be unable to navigate using the back or forward buttons in their browser > - users would be unable to recover from an error, for example if there is an interruption to their network connection These aren’t strict…
I think that section could be more clear if something like "without more effort" was added.
Re: Building a robust frontend using progressive enhancement
#40Good advice, but > - users of assistive technology would be unaware of changes in context, for example when moving to a new page > - it would fail to handle focus when moving between pages > - the user would be unable to navigate using the back or forward buttons in their browser > - users would be unable to recover from an error, for example if there is an interruption to their network connection These aren’t strict…
> These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother
Yes you can, but then it is way more difficult, and the fact that most don't even bother means that it is not exactly trivial to implement. Why to force that garbage when basic HTML basic web sites work just fine out of the box.