All fair points in many contexts, but not all contexts. Some counters:

1. You can embed CSS easily, and images using data: URIs...

2. ... so you can download the whole thing as a single and work offline.²

3. Non-standard clients are not my problem, file under “you can't please everyone, especially those who chose to be difficult to please!”. Accessibility is a concern though, I'd need to look into that before using such techniques without a reliable fallback.

4. This isn't practical for sites/pages needing large resources like high-res images, or that are large generally¹, but not all sites/pages need large resources or are large in general.

5. Not everything needs to be indexed well by search engines, I have things out there that are only relevant to those I refer to them, though I agree this could be a significant issue for many.

6. True. Though that breaks your second point, so you need to choose.

----

[1] you wouldn't want wikipedia done this way!

[2] also with external resources almost all browsers will happily save then when you do file|save, and to be pedantic the description given is “in a single html file” not “in a single file”

Out of curiosity, what aspect of the site would lead it to not being indexed well by search engines?

Edit: I just read tyingq's explanation. Is there anything else?

Just embed both CSS files and images in the HTML file.

And now it's even less scalable to larger sites because you're forcing the eager loading of resources on pages you'll never click on.

Easy solution. Use progressive compression for images and set loading="lazy" https://developer.mozilla.org/en-US/docs/Web/Performance/Laz...

loading="lazy" is for images that are NOT embedded in the same file. So we either have entire site in a single HTML file or we have scalability for large stes. There's no solution that gives us both.

It depends on what your goal is. If you just want to make a single request to the web server, than loading="lazy" will not work as you said. (Technically speaking, TCP is sending multiple packages anyway resulting in higher latency, so not sure if that is a great goal.)

But if you just want to be able to save the entire website with Ctrl + S, then it works fine.

As an aside, loading="lazy" is the way in which images are embedded in the website from TFA https://i.imgur.com/wIkaE5g.png which was the reason why I mentioned it, although it certainly does not fit all possible use cases.

> And now it's even less scalable to larger sites

And how is 20MB js SPA with 20 wss connections more scalable?

I've see too many react/vue projects bundling everything into a single main.js file even pages I never click. e.g. some crazy map or graph module. Is there some magic in webpack to make sure the needed functions gets executed in "eagerly" fashion?

Or does json provide streamable parsing capabilities?

If you are interested in building a single page site, I really doubt that scaling is an issue you'll have to contend with and seems like a waste to even consider it for something so small.

If you get hung up scaling a single page, you have other problems

This isn't a single page site, it's a single HTML file site with multiple (logical) pages.

I see no problem for SEO. I see no problem for screenreaders

This is all classic and supported HTML, so those should work perfectly for this.

The problem for SEO is that either the hidden parts are ignored or the indexing won’t properly differentiate between the different "pages" (sections).