|
HTML (or any SGML-derivative, really) + CSS is the only application view format we have in common use that allows for clients of all shapes and sizes to reformat the page to fit them (with reflow rules, browser-default styles, and user-agent styles); and for alternative clients like screen-readers or "scraper"-like API clients to work with the view without the author having considered their needs ahead of time; and, best of all, for client-supplied optional third-party extensions to go into the view and mutate it to suit whatever custom purpose the client desires. In other words, by mandating that the application view layer interacts with the client by delivering declarative (HTML) or imperative (JS) instructions to populate a semantic document (the DOM), rather than to populate a particular viewport; and by mandating that styling considerations are kept as separated as possible from that document; we can then operate on that document apart from the application's control, and render it the way we want to, or parse it into something entirely else. A large part of the point of "the web" as a technology stack, is to provide exactly that capability. There's even a name for explicitly targeting such use-cases as a developer: HATEOAS (i.e. making your API endpoints act like web pages as well, in that they're also "documents" embedding hyperlinks to related documents, and form-input descriptions for making queries against the document—so that API clients can "navigate" your API just like browsers navigate your site. In extremis, your API becomes your site—since, if every endpoint is already responding with hyper-documents, your controllers can just have a logic for "Accept: text/html" that renders that hyper-document into hypertext, and attaches styling to it.) If you don't care about any of that, you don't need the web. You just need a Hypercard viewer with an address bar. Or Lotus Notes. |
The DOM is a relic from the 90s that refuses to die.