Austin's Blog

A Rose by Any Other Name

I've been exploring HTML templating languages as part of my dive into building a static site generator for my blog. There are many options, almost too many -- far too many to evaluate fully, at least, for one person. But this has me thinking about what I need in a templating language, what's available in existing options, the tradeoffs between them, and what I might gain by building a template language of my own.

The first option I looked at, once I started my journey, was the Go language's offering in the form of html/template and its more generalized cousin text/template. This system is extremely powerful at a glance, and provides a lot of features packed into a small space. I especially like the "pipeline" concept, which lets you chain methods together and process data into a legible format in a really intuitive way.

That said, of course I had to explore all my options.

That led me to MDX, which looks like an extremely expressive extension of the Markdown language that allows for JSX components. I don't know that I need that level of expressive power in my templates -- I'm mostly typing up Markdown by hand without the need for complex interactive elements or 3rd party React integrations. Still, knowing that this was available kind of opened my mind to what is possible in the world of HTML templating.

A quick aside: this also got me thinking about security. I'm not using any user-generated content, so I don't really have to worry about this myself (unless I add comments, which, no, I don't want to open that particular can of worms right now) but it's interesting to consider the types of attacks someone can carry out by injecting markup, scripts, images, or whatever into your page. It's especially interesting because some very straightforward solutions only cover some of the attack surface, like converting angle brackets to HTML entities. Again, not something I have to think about right now but it sure is an interesting topic if you're working in this space (and it sure does come up a lot in documentation).

So with MDX on the brain, I started getting into what these languages can do. Besides generating HTML, the right templating language can turn a tedious chore into something less painful. It can allow for expressing things that would otherwise require a lot of custom HTML and CSS. It makes it easy to incorporate neat 3rd party widgets, different sorts of elements, or new styling into your writing. It makes writing natural.

And naturally, this got me thinking about writing my own template language.

Bilbo Baggins considers keeping the one ring, saying 'After all, why shouldn't I keep it?'

"After all, why shouldn't I make my own template language?"

Before anyone calls the authorities, I am of sound mind and I'm not making any custom template languages at this point in time. However! I thought about it, for sure. I guess the only thing stopping me at this point is that I don't need it. I'm sure I can tweak whatever output I get from the Markdown parser in Golang to suit my needs, at least for now.

If I did build a template language: I'd probably base it on a yaml-style syntax, using indentation to determine hierarchy of elements. It would probably be Lisp-y under the hood, if not on the surface as well. I think I would prefer, in this case, "convention over configuration" in the Rails sense -- that is, I would prefer a language with reasonable defaults that I can lean on to do the thing I want 80+% of the time, but that I can customize as needed. It's kind of nice too, because if I'm the only one using the language, I can make concessions I could never have if I were trying to build this for a wider audience.

That gets me thinking about "bespoke software", or "situated software", but that's another post for another day.

Anyway, I think I'm at a point where I can just use Go's templating system, combined with a Markdown parser, to get what I need out of this. The plan from here is pretty straightforward as I see it:

  1. Render Markdown into HTML,
  2. in a directory hierarchy that matches what I want on my site,
  3. and deploy it to a static site host somewhere.

From there, once I have the pipeline set up, I can rapidly hack out any features or tweaks or fixes that I need, add niceties and convenience features...it'll be a really exciting place to be, once I get there. And I can live-blog the whole thing essentially, which makes for a really interesting writing experiment. Stay tuned, more to come!