3 ms·
Progressive enhancement isn't about supporting the minority of users that disable JavaScript. It's about sound engineering and building a robust system that is
by bitbasher 2y ago
Progressive enhancement isn't about supporting the minority of users that disable JavaScript. It's about sound engineering and building a robust system that is tolerant to errors. A system that can fail gracefully.
There's nothing wrong with using JavaScript. There's nothing wrong with depending on JavaScript for specific functionality. However, I don't think it's acceptable to completely break down if that JavaScript fails to load.
With SPAs and "modern" web development practices, it's all or nothing. Either everything works, or nothing works.
Not with things I build.
- pie_flavor 1y agoHave you ever given an iota of thought to how your website looks when the CSS doesn't load? Contemplated arranging elements into `<table>`s to preserve some semblance of formatting, crammed some truly necessary styling into `style=`? If not, then the users that disable JS are the primary driver of thinking about how your website looks when the JS doesn't load; any two given files are about equally likely to not load, JS isn't privileged here compared to CSS (and is much harder to gracefully handle its absence).
- bitbasher 1y agoI do a fair amount of thinking around all failure states (CSS included). I think you may be overthinking the appearance aspect of a failure state. The application doesn't need to look the same when CSS fails to load. However, the application should be functional. This thinking carries over to the backend as well. My application server doesn't require all services to be up and running. Instead, it's able to query and tell what is working and what isn't. That information is then bubbled down to the UI in one way or another. That may mean certain functionality is unavailable (ex, if solr isn't reachable then search is disabled).