←back to thread

116 points vgr-land | 6 comments | | HN request time: 0.001s | source | bottom

A few weeks ago a friend sent me grug-brain XSLT (1) which inspired me to redo my personal blog in XSLT.

Rather than just build my own blog on it, I wrote it up for others to use and I've published it on GitHub https://github.com/vgr-land/vgr-xslt-blog-framework (2)

Since others have XSLT on the mind, now seems just as good of a time as any to share it with the world. Evidlo@ did a fine job explaining the "how" xslt works (3)

The short version on how to publish using this framework is:

1. Create a new post in HTML wrapped in the XML headers and footers the framework expects.

2. Tag the post so that its unique and the framework can find it on build

3. Add the post to the posts.xml file

And that's it. No build system to update menus, no RSS file to update (posts.xml is the rss file). As a reusable framework, there are likely bugs lurking in CSS, but otherwise I'm finding it perfectly usable for my needs.

Finally, it'd be a shame if XSLT is removed from the HTML spec (4), I've found it quite eloquent in its simplicity.

(1) https://news.ycombinator.com/item?id=44393817

(2) https://github.com/vgr-land/vgr-xslt-blog-framework

(3) https://news.ycombinator.com/item?id=44988271

(4) https://news.ycombinator.com/item?id=44952185

(Aside - First time caller long time listener to hn, thanks!)

Show context
b_e_n_t_o_n ◴[] No.45009540[source]
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?
replies(2): >>45009634 #>>45011470 #
1. riehwvfbk ◴[] No.45009634[source]
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.
replies(1): >>45009969 #
2. b_e_n_t_o_n ◴[] No.45009969[source]
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.

replies(1): >>45021207 #
3. riehwvfbk ◴[] No.45021207[source]
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.
replies(1): >>45022850 #
4. b_e_n_t_o_n ◴[] No.45022850{3}[source]
ETags still require a round trip. You could cache for longer but now you have to deal with the complexities and struggles of caching.
replies(1): >>45025398 #
5. riehwvfbk ◴[] No.45025398{4}[source]
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.

replies(1): >>45031845 #
6. b_e_n_t_o_n ◴[] No.45031845{5}[source]
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.