I don't completely agree. If you're working on an SPA that targets higher-income (e.g. better internet) consumers, a developer could be forgiven for doing as mu

I don't completely agree. If you're working on an SPA that targets higher-income (e.g. better internet) consumers, a developer could be forgiven for doing as much as possible using JS. I choose to sacrifice the <1% of my target users who have JS turned off or have poor connections to benefit the UX of the other 99% of users. I think the time and resource investment in strictly adhering to these guidelines is cost-prohibitive for many lean engineering teams, particularly those at early-stage startups. I get that the web was designed to be optimized for HTML/CSS first, JS last. However, the web was also not originally designed to support web applications as complex as the marketplace currently supports. As the web matures as the only universal application platform (to compete with various native platforms), I think a paradigm shift is required -- towards replacing as much markup with programmatic code as possible. Such a paradigm shift is required for complex web applications to compete with native environments going forward. Of course, none of this applies if your organization just requires static websites. Choose the right tool for the job, and all that.