Huh.
If you think that one of the advantages of JS-required SPA-style applications is that they will help you avoid things getting expensive somehow... I'm not sure where to start, actually. Maybe the situation here is kindof like the old saw about mediation: you should do it for 20 minutes a day, unless you don't have time, then you should do it for an hour a day.
My experience is that sites that start with the focus on their shiny new JavaScript framework and their app-like UI tend to devolve into architectures with overspecific and mixed concerns pretty quickly. If you want to keep things from getting complex and expensive, start by keeping discipline involved in conceiving of the app in terms of plain HTTP and different media representations of the same relevant resources/data. For back ends already producing well-modeled JSON documents, producing equivalent HTML representations should be easy. If it's not, something is likely wrong (and if you're already producing well-modeled HTML documents, it's exceptionally rare that producing good JSON docs with the essential content is anything other than trivial).
Now it's true that some apps just aren't about resources and media types, and you need the browser-as-runtime instead of the browser as document/media viewer. It's nice that the browser keeps growing in capabilities here. But let's be honestly: most of the JS-required apps we're seeing out there these days aren't even close to meeting this bar. And the "extra costs" you're invoking of supporting clients without JS are, in those cases, self-inflicted.
> That's because industry analytics showed that approximately 1% of visitors lack JavaScript.
And I bet those same analytics probably showed even fewer visitors without JS after they used those stats to require it -- problem solved!
Pros for expecting JavaScript to be enabled:
- Cheaper development because you can assume a common, featureful baseline. That leads to less code complexity on both the client and the server because you don't have to implement parallel code paths.
- Freedom to add features that would be difficult or impossible to emulate with traditional static pages
Cons for expecting JavaScript to be enabled:
- The site won't look and act right for the 1% of visitors who are used to every other site also not looking and acting right
There are lots of reasons to use JavaScript in the browser and almost no reasons not to, so everyone collectively decided to stop hamstringing themselves to cater to a teensy portion of users.