5 ms·

It is too bad that the HTML standard has no built in way to fallback. They've added a cryptographic hash/integrity and the async/defer attributes to the script

It is too bad that the HTML standard has no built in way to fallback. They've added a cryptographic hash/integrity and the async/defer attributes to the script tag, but something as essential as a fallback if a script or stylesheet fails to load (which the browser is best placed to know), has no built in functionality. Instead you're left doing JavaScript tricks which for missing CSS gets a little ugly[0]. But CDN with local fallback (or visa versa) has been common now for decades but yet no official support at all. Honestly if the integrity attribute is specified the browser should just be able to fall back to a cached copy it has (e.g. jquery.1.2.3.min.js has a crypto hash of ABC123, and I have that file already). [0] https://stackoverflow.com/questions/7383163/how-to-fallback-to-local-stylesheet-not-script-if-cdn-fails https://stackoverflow.com/questions/7383163/how-to-fallback-...

_jmar777 9y ago
Yeah, I think the latest and greatest in web standards for solving this problem would probably be using a Service Worker to transparently handle the failure and serve up a fallback... but like you said, that's a JavaScript-based solution.
robin_reala 9y ago
I mean, the fallback mechanism is progressive enhancement. It’s a reliability mechanism more than anything - if JS (or part of the JS) fails to load the site should fall back to a version that potentially reduces the interactivity but allows essential functions to continue.
- 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 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.
    - 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 ago
    I 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
deleted 9y ago
[deleted]
ohazi 9y ago
> Honestly if the integrity attribute is specified the browser should just be able to fall back to a cached copy it has (e.g. jquery.1.2.3.min.js has a crypto hash of ABC123, and I have that file already). I really want this feature. I think there might be some cross-origin issues that need to be handled correctly (e.g. you might be able to fingerprint a user by probing for parts of their cache), but for common things like exact copies of jquery, this would be super useful.

_jmar777 9y ago

Yeah, I think the latest and greatest in web standards for solving this problem would probably be using a Service Worker to transparently handle the failure and serve up a fallback... but like you said, that's a JavaScript-based solution.

robin_reala 9y ago

I mean, the fallback mechanism is progressive enhancement. It’s a reliability mechanism more than anything - if JS (or part of the JS) fails to load the site should fall back to a version that potentially reduces the interactivity but allows essential functions to continue.

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

deleted 9y ago

[deleted]

ohazi 9y ago

> Honestly if the integrity attribute is specified the browser should just be able to fall back to a cached copy it has (e.g. jquery.1.2.3.min.js has a crypto hash of ABC123, and I have that file already). I really want this feature. I think there might be some cross-origin issues that need to be handled correctly (e.g. you might be able to fingerprint a user by probing for parts of their cache), but for common things like exact copies of jquery, this would be super useful.