This is a valid argument for also providing a useable non-script version of your side, i.e. doing graceful degradation. I absolutely agree that this is still an important thing to do in 2016.
However, I don't see how this is an argument for building only pure-HTML pages. Why can't I use scripting with client-side templates, so I get an its advantages for clients that support it and use a server-rendered version (ideally using the same templates) for clients that don't?
If anything I would see this as an argument for client-side templates, at least if you still want to use scripts for certain parts of your site. Because the other alternative - generating snippets of html on the server, then monkey-patching them into the current page via script - seems like the worst of both worlds to me.
It's less development work to do progressive enhancement than it is to do graceful degradation[0], because you don't duplicate effort. And IMO, the outcome is usually better, as well.
Comments
This is a valid argument for also providing a useable non-script version of your side, i.e. doing graceful degradation. I absolutely agree that this is still an important thing to do in 2016.
However, I don't see how this is an argument for building only pure-HTML pages. Why can't I use scripting with client-side templates, so I get an its advantages for clients that support it and use a server-rendered version (ideally using the same templates) for clients that don't?
If anything I would see this as an argument for client-side templates, at least if you still want to use scripts for certain parts of your site. Because the other alternative - generating snippets of html on the server, then monkey-patching them into the current page via script - seems like the worst of both worlds to me.
It's less development work to do progressive enhancement than it is to do graceful degradation[0], because you don't duplicate effort. And IMO, the outcome is usually better, as well.
[0]: https://www.w3.org/wiki/Graceful_degradation_versus_progress...