←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: 0s | 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
shakna ◴[22 Aug 25 23:38 UTC] No.44991280[source]▶
As of the next version of Chrome, XSLT will be gated behind a flag.

Google have also asked for it to be removed from the standard [0].

[0] https://github.com/WHATWG/html/issues/11523

replies(5): >>44991471 #>>44991489 #>>44991500 #>>44991526 #>>44992056 #
simpaticoder ◴[23 Aug 25 00:03 UTC] No.44991526[source]▶
It's kind of too bad XSLT didn't take off. It is quite complex, until you compare it to the complexity of what now solves this problem (e.g. a build step with React and webpack and javascript absolutely required on the client-side). As the OP ably demonstrates, XSLT provides a declarative, non-javascript, non-build way to solve the basic HTML component problem. Perhaps a devastating 0-day in V8 will make us really, really want an alternative to the current best practice.
replies(4): >>44992022 #>>44992785 #>>44993179 #>>44993291 #
1. MrJohz ◴[23 Aug 25 04:32 UTC] No.44993179[source]▶
I think the big difference there is that browsers are only responsible for Javascript, which is a big general purpose solution that solves a lot of problems and not just templating/styling XML. Everything else either happens server-side (build steps and webpack) or is userland code that lives inside the sandbox. So there's one task for browsers to do (make a fast and secure Javascript sandbox), and if that works that developers can do whatever they want. Whereas XSLT is not a general purpose tool in the same way, and so needs to be maintained in addition to Javascript and anything else that exists.

If course XSLT can also be used server-side (which is probably a good idea if you want access to the latest features and not some ancient, frozen version of the spec), but browsers aren't the reason that that didn't take off. My guess there is that it's just not an intuitive way of manipulating and templating data in comparison to more traditional HTML templating libraries.