Comment by b_e_n_t_o_n
2 months ago
I guess I just don't get the point. In order for the page to load it needed to make four round trips on the server sequentially which ended up loading slower than my bloated javascript spa framework blog on a throttled connection. I don't really see how this is preferential to html, especially when there is a wealth of tools for building static blogs. Is it the no-build aspect of it?
It did make all those requests, but only because the author set up caching incorrectly. If the cache headers were to be corrected, site.xsl, pages.xml, and posts.xml would only need to be downloaded once.
The cache headers are correct, you can't indefinitely cache those because they might change. Maybe you could get away with a short cache time but you can't cache them indefinitely like you can a javascript bundle.
Not to mention on a more involved site, each page will probably include a variety of components. You could end up with deeper nesting than just 4, and each page could reveal unique components further increasing load times.
I don't see much future in an architecture that inherently waterfalls in the worst way.
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.
3 replies →
The appeal of XML is semantic. I think about things in a certain way. I write the text the way I think, inventing XML elements and structure as I go. Then I transform it into whatever. This obscures the semantic, but the transformation is transient, merely to present this to the user.
To do this dynamically I serve the content as I wrote it with a single processing instruction that refers to a stylesheet. This is elegant, isn't it? It is less efficient than a static site, but not that different from a typical HTML: HTML, CSS, JS. It is also trivial to change it to build statically (or to embed all the resources and XSLT into individual XML files, although this would be strange.)
And if browsers supported alternative stylesheets it would be trivial to provide alternative renderings at the cost of one processing instruction per rendering. Why don't they? Isn't this puzzling? I think it is even in the specification.
I get it, but if we're building things for others to use the elegance of our solutions doesn't matter. What matters is things like the efficiency, the experience of using it, not writing it. And I think browsers should serve the end user, not the developer. If we sacrifice some elegance for security that seems like a win for the user. Even if we lose some of the elegance of the abstraction, that's not what it's about.
Of course everyone is free to create things they want with their own abstractions, but let's not pretend that it's an optimal solution. Elegance and optimal are often at odds.