the problem is that every piece of navigation on a site turns a document into an application. separating actual document content from a "frame" that includes navigation and site styling has always been a problem. take hackernews for example. it is not a document. but every message is its own document and the rest is an application to view those documents. you practically can not avoid using application techniques if you have a site with multiple documents.

▲

skydhash 3 days ago | parent | next [-]

Hacker News is very much a collection of documents and forms with hyperlinks creating the whole concept of applications. No need to add desktop interactivity (which is already provided by the browser: loading documents, submit the form,...).

Most SPAs are reinventing the browser features (history, routing, navigation state, submitting forms, showing request's responses). When you really needs a full fledged application, those don't really matter (Figma, music players, document viewers,..).

▲

account42 3 days ago | parent | prev [-]

No, a hypertext document is still just a document and not an application.

▲

em-bee 3 days ago | parent [-]

a single document, yes, but once i have more than one document and i want to add additional documents, i need navigation so that i can browse and find those documents. if each document only links back to the parent, and that parent lists all the documents, fine. but if i want to have the same navigation available on all documents, then i need to start making a distinction. that menu to choose the document should not be part of the document itself. the menu is an application used to navigate between documents.

the distinction i make is that a document is static, an application is dynamic. that menu needs to be regenerated every time a new document is added. if i include the menu in each document then every time i add a new document, i have to edit every other document to update the menu.

that has implications, including the timestamp when that document was last changed. therefore the distinction matters. i do not want to have to touch every document in order to update a menu. the menu should be distinct and be changeable without touching existing documents.

current html standards do not allow that because they do not support include. and http does not support directories. that's one advantage gopher had over http.

i can include the menu with javascript, or i could use xslt. but either way, the menu is an application, and it's not part of the document.

no being able to make this distinction is what forced me to build dynamic websites already in the early 90s. back then we didn't even have javascript, we only had serverside includes and eventually servers that could generate whole pages dynamically. it is in part what led me to a search for better webservers than the ones ncsa and cern were offering. but that's another story.

▲

ndriscoll 3 days ago | parent [-]

The menu is a templated document fragment, and XSLT runs completely before anything on the page exists (so it's not usable for interactive applications unless you run it in a javascript processor). What you're claiming is like saying a linked CSS file somehow makes the page an application. The application is the browser, and it knows how to put together linked fragments, templates, and styles to form a document. XSLT is exactly how current HTML standards allow static client-side includes just like CSS is how they allow styles.

▲

em-bee 3 days ago | parent [-]

The application is the browser

except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links.

compare that to an email client or really any other application. hackernews is a messaging application.

a linked CSS file somehow makes the page an application

no, to keep with the analogy, the CSS part IS the application.

XSLT is exactly how current HTML standards allow static client-side includes

well, kind of. you need a lot of code to describe a simple template: https://news.ycombinator.com/item?id=44398626 [1]

and that still doesn't work for cases where you want multiple document in one view though.

it is at least a step in the right direction. it allows me to keep the document separate and free of navigation artifacts (the linked example is not ideal in that case, but it can be done).

but the same is achived if i build an SPA with javascript. the browser first loads the SPA application, and then the application loads the documents to be displayed. that allows me to keep the documents as original on the server. and unlike xslt this also works for multiple documents in the same view.

[1]: for those reading that thread to the end, the chromium issue turns out to be limited to the fedora build of chromium, nightly builds from the chromium website and chrome work.

	▲	skydhash 3 days ago \| parent [-]
		> except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links. And that is all that needed. If you want to provide a common structure for navigation, usually a menu, it should be sent as part of the page. Which means the document and the navigation needs to be composed server side (either on the fly, or generated once). Then you can enhance the page client side (which is rarely needed).