5 ms·
Progressive enhancement is largely a myth. A lot of libraries, JQuery, Lodash, Angular, Vue, React, Bootstrap's JS, module loaders, etc aren't simply offering
by Someone1234 9y ago
Progressive enhancement is largely a myth.
A lot of libraries, JQuery, Lodash, Angular, Vue, React, Bootstrap's JS, module loaders, etc aren't simply offering "improved interactivity" they're offering core functionality. In essence the site runs on these libraries, if you remove them there's nothing left to regress too.
I've worked in several companies and never seen progressive enhancement used. It might have made sense back in the IE6 era when JavaScript was just for whiz-bang, these days JS libraries are holding the whole site's data context/state and generating Ajax as needed (Vue, Angular, React, etc). That's core, there's nothing progressive that can be removed from that.
Progressive Enhancement only makes sense for small toy sites or for academics to play with. Even Netflix's famous examples are about web services going offline, not losing core JavaScript libraries.
- madeofpalk 9y agoYou 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.
- Someone1234 9y ago> 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.
- chocolatkey 9y agoI didn't know the term was progressive enhancement, but if it is what I think it is, it's a great thing to aim for. Sometimes users (probably more on HN) like to browse without js enabled, and some people also need websites that are accessible in a more basic environment, whether it be for screen reader, console web browser, archive.org, or simply older browser. Worse case scenario if the JS breaks and throws and error on older browsers, essential content should still be available, especially the content. There's nothing more irritating than "you need JS to view this page" when not appropriate or just an empty page when some dependency breaks due to human error. Instead, if the search button's popup box with suggestions won't work, fall back to just linking to the search page. Use <noscript> to redirect people to a basic version of some interactive content if you need to. Yes, the latest greatest is cool, but I still think it's in style. It also restrains how dependent I am on the perfect javascript, preventing too much JS Lag from building up in my libraries. Of course this is just my opinion
- Someone1234 9y agoYou can write single page applications that are fully aria aware, and we do. In fact we're legally required to, and our pages are audited before they're ever released to the public including for assistive technologies. Screen readers support JavaScript, and have for at least the last ten years. As to users choosing to run without JavaScript? We simply don't support it. We support IE8 and above. You cannot even get to our site using Windows XP due to errors in the TLS negotiation (to avoid SSL downgrade). If users choose to disable a core part of their browser that happens to be a core part of modern web standards, then they shouldn't be surprised when sites using that part no longer work.
- robin_reala 9y agoSorry, but the entirety of GOV.UK is built using progressive enhancement. I’m assuming you don’t believe that a site with 300k+ public documents, multiple hundreds of user critical services (including some built with React and other modern frameworks), and serving 100m+ pages a month is a toy site. To honest answer is that we couldn’t afford to go down in the case of missing or broken JS, regardless of how it was broken (be it CDN failure, deliberate user choice, or some other reason like proxy failures, users on mobile connections that drop out half way through page load, etc etc).
- seba_dos1 9y agoNo. It's just a problem of laziness, and possibly ego, of developers. There are apps using browser as execution environment and there are websites. You wouldn't expect a client-side drawing tool, WebVR game or real time visualization of blockchain transactions to work without JS enabled. However, you can easily expect a social network, mail client, news page, task app, and to some extent even things like IM to work with no JavaScript. "That's core" is just an excuse for poor architecture - it's only core because you chose to make it so. There are apps and there are websites, with only some small part of grey area in between. If you're a web developer wanting to use newest, greatest trendy tools, you see everything as apps, despite of common sense suggesting otherwise, and you end up with no progressive enhancement for no good reason. When you take it to extremes, you end up creating such abominations like the old SPA Twitter frontend, spinning the fans of your laptop for 15 seconds just to display 140 characters of text, because "the core" is implemented as AJAX calls and fully rendered client-side.
- Someone1234 9y ago> No. It's just a problem of laziness, and possibly ego, of developers. We're talking about large organizations. No single developer is making these decisions. And the question is about resource allocation, if the choice is between improving the core experience or implementing an experience that <1% of our users will ever see, the choice is easy. > "That's core" is just an excuse for poor architecture - it's only core because you chose to make it so. It is core because the internet has democratically made it so. You're speaking for a very vocal minority. We're choosing not to implement a special mode for people who self-selected to receive a broken web experience. Fortunately that same demographic knows how to resolve the issue they caused. > no progressive enhancement for no good reason. A richer user experience is a very good reason. If the choice is between making the site richer and more immersive for 99% of users, and leaving 1% of users who wish to be contrarian for no reason out in the cold? So be it. A worthy sacrifice, in particular as this 1% selected themselves for punishment. You're welcome to pick and choose any arbitrary part of the web to disable, maybe JavaScript, maybe CSS, maybe font rendering entirely, maybe disable images, but it gets a little silly when you blame others for your self imposed breakages. You don't want it broken? Don't break it.