xtemplate

I've also been dissatisfied with http caching not utilizing content hashes enough. If you're using server side templating one issue is that it's not efficient to calculate the hash while you're running the template, it would need to be precalculated to be efficient enough to use. So I wrote https://github.com/infogulch/xtemplate to scan all assets at startup to precalculate the hash for templates that use it, and if a request comes in with a query parameter ?hash=sha384-xyz and it matches then it gives it a 1 year immutable Cache-Control header automatically. If a file x.ext has a matching x.ext.gz/x.ext.zst/x.ext.br file then (after hashing the content to make sure it matches) client requests that support it are sent a compressed version streamed directly from disk with sendfile2. I call this "Optimal asset serving" (a bit bold perhaps).

Yes, that would be useful. Basically, what you have in https://github.com/infogulch/caddy-xtemplate/blob/master/tem... - but without Caddy dependencies and with a way to use any router library (I use gorilla/mux). I would make the templates library take a callback function for every public template: func(method, path string, template). Then the user could add any custom logic to register the route handler and execute the template with any application specific inputs.

XRss is a simple RSS reader web app built to showcase xtemplate, a new web development tool based on Go's html/template and Caddy server. The entire site UI for XRss comes from a single HTML template file. This index.html includes everything from SQL queries and route definitions and handlers to htmx state transition attributes and tailwindcss classes, and developing it requires zero build steps (amortized). Check out the source which manages to be at once banal and gnarly: https://github.com/infogulch/xrss/blob/master/templates/inde... xtemplate preloads the whole template structure into memory and builds the router at startup, so responses to matching requests are rendered after a single lookup. Combined with direct queries to sqlite makes for a very snappy experience typically responding in less than 5ms. (Fingers crossed.) There are v

That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multiple extra round trips and device speed/power. And you could get into the hydration and SSR mess, but then you could just render on the server in the first place and simplify the entire system, reduce your LOC by 5x, opt out of the entire js ecosystem shitshow (or keep it for select high interactivity components, I won't judge), and eliminate an entire api that doesn't need to exist. If you are building the next google maps, mayb