I don't get it, why the data and the final visual have to be both present/created ON THE SERVER. There's been a technology around for so long, that it is forgo

I don't get it, why the data and the final visual have to be both present/created ON THE SERVER. There's been a technology around for so long, that it is forgotten meanwhile (like the semweb itself): xslt. A lot can be done by just publishing raw xml data plus a visual representation generated in the browser right before display. I'm doing so with RDF https://demo.mro.name/geohash.cgi/about https://demo.mro.name/geohash.cgi/about, GPX https://demo.mro.name/geohash.cgi/u154c https://demo.mro.name/geohash.cgi/u154c, homegrown xml http://rec.mro.name/stations/b2/2022/01/12/1005 http://rec.mro.name/stations/b2/2022/01/12/1005 or atom feeds https://demo.mro.name/shaarligo https://demo.mro.name/shaarligo and on and on. The server is a source of data, its filesystem the database, and the client has to make sense of it. There is no API but GET requests. Works wonders for all but big data queries, naturally. So you publish raw data (TimBL, you want it that way) plus a recipe for a visual representation and the browser shows a sensible view to begin with.