Even as you are strawmanning our community[0] you outline well why it is such such a great community ;-)
[0]: most of us are not saying browsers shouldn't be allowed to run code, only that there's no reason why anyones statical documents should need to run code on my machine.
It's HTML, it's designed to link between URLs. Whether the URL is a file on your filesystem or on the web is irrelevant. If you keep all your resources in the same set of subfolders you can use the same html/ images/ CSS as the web and use relative links.
It's literally just a folder full of perfectly normal HTML files. You don't need Javascript or a SPA to double-click one of those and look at it in a browser.
Even better, if your operating system has full-text file indexing, it'll be able to search them normally.
Edit: incidentally, a common way for this to work is that the documentation just comes with the software itself, so it's just sitting there on you computer. If the software updates, the documentation updates.
Websites like https://devdocs.io/ do this exact thing through desktop Progressive Web Apps.
Basically you keep your markup & source as static as possible, and allow a serviceWorker to cache those files locally. This can also be done with a SPA, but if we're talking docs, you get the benefit of only having to update a specific page if its raw html.
I was thinking (assuming this is one's own stuff), use rsync to download the files to avoid transferring lots of unchanged stuff. But if this is for an end user, yes, there would only be html access.
It amazes me that anyone asks this question. I have trouble seeing why you would want put documentaion in a SPA. Search result perhaps, but the rest of it?
I think it's a part of modern web developer culture. Where I work I started on a project which was already 3-4 months down the road and they were fully dedicated to react frontend and Koa on the backend. The whole stack was based on a react boilerplate the company built, as far as I can tell the idea of doing something other than JS on the server was never tabled. Likewise, the idea of rendering HTML on the server was never brought up. Everything is pure client side JS SPA even in places where it might make sense to just render things on the server or load a separate page.
Many SPA examples will try load bits from the server and fail. And a non-SPA site can easily be provided as a download too, or use a service worker to provide offline access in the browser.
Disagree with this. Having the entire documentation site working as normal on my browser when I have bad/no internet connectivity is extremely useful.