> There is no actual need solved by using client side include to load a nav bar.
I disagree: this[1] was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature.
When you find yourself switching stacks to get some feature, trust me, it's really needed.
> Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.
Sure, and in this specific case all the dev had to do was include a link in each blog post to the root of the site `<a href='/'>home</a>`.
So when the JS is turned off the user can still navigate.
Once again, I am going to point out that plain HTML+CSS+JS is conformant to the relevant specifications; when a user wants to to, for whatever reason, deviate from the specification, they already know that most things won't work for them anyway!
IOW, you're not dealing with a clueless user who will wonder why the page has no navigation, you're dealing with someone who spent extra work and effort to get into the state they are, so they're already aware that most things don't work for them anyway!
But you responses throughout this thread is working on the assumption that megabytes of JS is required if you want client-side includes, and you coupled that with an implication that only incompetent developers would go down that route.
I can assure you, as a competent developer, that adding client-side includes with graceful degradation is maybe 60 lines of JS, cached, with no noticeable delays for the user.
If you think that the only options are a) Doing a full SPA with megabytes of JS, or b) No Javascript whatsoever, then I think that you're in no position to be calling other developers incompetent or lazy.
