Hacker News new | past | comments | ask | show | jobs | submit login

> Your documentation doesn't need to be an SPA.

Disagree with this. Having the entire documentation site working as normal on my browser when I have bad/no internet connectivity is extremely useful.




It really speaks to modern web dev culture when you can't imagine a way of viewing a document offline without running JavaScript.


It really speaks to the Hacker News culture to suggest that in 2020, browsers shouldn't be allowed to run code.


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.


Don't need a SPA for that. Local HTML based documentation was a thing long before SPA was even a term.


How does that work exactly?


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.


Or better yet, one HTML file. Anchor tags are still a thing, last I checked. CTRL-F, does anyone still speak it?


Sure, but you also have to manually redownload the entire site whenever there is a change.


You would with a SPA as well.

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.


To a degree though, thats where PWAs come in.

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.


Documentation doesn't change in real time.


> Documentation doesn't change in real time.

If you are a javascript developer chasing the bleeding edge of web dev, it's pretty close to real time!


That’s what rsync is for.


or wget, since rsync doesn't work with HTTP.


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.


Have a look in your /usr/share/doc folder.

Run this:

    find /usr/share/doc -name '*.htm*'
You'll be surprised.

Your system's package manager is installing the HTML documentation right along with the software you install.

When you update your system, new package versions along with their corresponding documentation are downlaoded.


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.


No advertisment, just an example:

https://en.wikipedia.org/wiki/Doxygen


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: