←back to thread

Show HN: JavaScript-free (X)HTML Includes

(github.com)
210 points Evidlo | 1 comments | 22 Aug 25 18:47 UTC | HN request time: 0.208s | source

(spoiler: its XSLT)

I've been working on a little demo for how to avoid copy-pasting header/footer boilerplate on a simple static webpage. My goal is to approximate the experience of Jekyll/Hugo but eliminate the need for a build step before publishing. This demo shows how to get basic templating features with XSL so you could write a blog post which looks like

  <?xml version="1.0"?>
  <?xml-stylesheet type="text/xsl" href="/template.xsl"?>
  <page>
      <title>My Article</title>
      <content>
          some content
          <ul>
              <li>hello</li>
              <li>hello</li>
          </ul>
      </content>
  </page>
Some properties which set this approach apart from other methods:

  - no build step (no need to setup Jekyll on the client or configure Github/Gitlab actions)
  - works on any webserver (e.g. as opposed to server-side includes, actions)
  - normal looking URLs (e.g. `example.com/foobar` as opposed to `example.com/#page=foobar`)
There's been some talk about removing XSLT support from the HTML spec [0], so I figured I would show this proof of concept while it still works.

[0]: https://news.ycombinator.com/item?id=44952185

See also: grug-brain XSLT https://news.ycombinator.com/item?id=44393817

Show context
msylvest ◴[23 Aug 25 08:24 UTC] No.44994328[source]▶
I remember admiring the intent of XSLT when it was born. And how difficult it turned out to be to write; using XML framing makes it terse/verbose/arcane, eg. when compared to the compactness of regex/subs.

It is 2025 and now we've got LLMs to write our code - that may actually be a strong argument in favor of keeping XSL(T): It is a useful browser mechanism and LLMs makes it easier to harvest.

Does anybody have experience with LLM-generated XSL(T)?

replies(2): >>44994878 #>>45012808 #
1. reacweb ◴[23 Aug 25 10:24 UTC] No.44994878[source]▶
I have 1 "big" xsl file in a project I maintain. I have fixed an issue this year. I have tried to use chatgpt prompt. The scope was perfect: I had the buggy xsl, the buggy result, the expected result and a clear explanation. It generated syntactically correct code (almost) that did not work because chatgpt does not understand. This was not a complete loss: a good refresher of the syntax, but I had to do the thinking fully alone and found alone how to use "node-set".

My previous change in this file was in 2017 when I replaced xalan by the xslt processor built in java. I was very surprised I had to make the following changes:

    -<xsl:if test="string(serverName)=$sName">
    +<xsl:if test="string(serverName)=string($sName)">

    -<xsl:for-each select="attributeList/attribute[self::attribute!='']">
    +<xsl:for-each select="attributeList/attribute[text()!='']">

    -<xsl:if test="preceding-sibling::Connection[featureType='Receptacle'][position() = 1]/@Name!=@Name or not(preceding-sibling::Connection[featureType='Receptacle'][position() = 1]/node()) ">
    +<xsl:if test="preceding-sibling::Connection[position() = 1]/@Name!=@Name or position()=1">
These incompatibility issues with something I considered to be standard greatly damaged my opinion on xslt.