There are cache times other than 0 and infinity. Ideally the XSLT would change rarely, as would things like nav menus. So "relatively short" could mean several minutes to an hour. And with ETags the resource could be revalidated before expiry and never have to be re-downloaded.

▲

b_e_n_t_o_n 3 days ago | parent [-]

ETags still require a round trip. You could cache for longer but now you have to deal with the complexities and struggles of caching.

▲

riehwvfbk 3 days ago | parent [-]

With HTTP/2 multiplexing all of those requests can be made in a batch without round trips. And complexity of caching? An Etag done right is content-based. There's no logic to worry about.

It's really unfortunate that this style of architecture lost the battle. It's elegant. Data cleanly separated from presentation, small digestible entities, and it all kind of makes sense. But what killed it was the verbosity of XML, as well as its extreme pedantry that results in lack of robustness where a single error would kill the entire transform. Also transformation-based systems notoriously lack proper tools for debugging early on. Lastly, typically buggy implementations of pipelining in HTTP/1.1 made it so that you actually had to make those round trips. But conceptually we had all the pieces to make it work well back in the early 2000s.

	▲	b_e_n_t_o_n 3 days ago \| parent [-]
		Hm - how would multiplexing help here? Does the browser read ahead and process cached assets to find dependencies before firing off etag requests in a batch? I'd be surprised if that was the case.