[lelanthran]

> However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website.

If you set the bar to "0% JS at all costs" then you can't very well complain about how hard it was to maintain HTML.

Part of the standards, whether we like it or not, is JS. A sprinkling of JS (say, 60 lines?) to do client-side includes does not in any noticeable way increase the workload of the client, nor deteriorate the experience of the user.

After all, you provide a CSS file, right? The JS to do client-side includes using a custom element (so that `<client-side-include remote-src="...">` works) is unlikely to surpass a modest CSS file in terms of size.

[shkkmo]

The argument is not to never use JS. The argument is that you shouldn't unnecessarily use JS in a way that breaks core functionality if it is disabled.

There is no actual need solved by using client side include to load a nav bar. Doing so will break navigation on your blog for people without Javascript enabled.

Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.

[em-bee]

There is no actual need solved by using client side include to load a nav bar.

i am maintaining a site by hand right now. i am fine with copying from a template to get the structure. styles and formatting should be CSS anyways. navigation is the only thing that is a problem. i'll either figure out if i can do navigation in CSS or i'll end up having to use javascript. client side include in html only is the very thing missing here.

[lelanthran]

> 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.

[em-bee]

looks like you forgot to include the [1]link.

[shkkmo]

> this was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature.

Client side includes would have solved a small part of the pain points that were listed in the article.

This is a developer who explicitly didn't want to add javascript. Compromising a design goal, especially for a hobby project, to only partially solve your pain points, doesn't seem like a good trade off.

> 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

Disabling javacript is not a deviation from any specification.

> 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 that route.

I never said either of those those things. I said "lazy" and I never implied anything about the size of javascript required for client side includes.

I never used "SPA" in my response to you I used it in response to this:

>> Personally I think it's better to distribute the workload across clients. We'll probably see purely client driven UI's dominate the future.

This is not advocating for thin client side include. This is arguing for a world where everything is an SPA.

> 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.

Not only did I never say such a thing, but it is pretty darn clear that I don't hold such a view since you quoted me in your comment as advocating for progressive enhancement, which generally isn't a SPA but uses some javascript.

You should take a breath and try reading things more than once. You've repeatedly put words in my mouth and done so with some oddly aggressive language