I miss the days when "implement your own blogging engine" was one of the most popular learning projects for engineers.

We should bring that back! Its such a great way to play around with client- and server-side development options in an almost zero-risk environment.

  GET /hello/:world
    |> jq: `{ world: .params.world }`
    |> handlebars: `<p>hello, {{world}}</p>`
  
  describe "hello, world"
    it "calls the route"
      when calling GET /hello/world
      then status is 200
      and output equals `<p>hello, world</p>`

Lua 5.1 to 5.2 was a fairly significant breaking change; one that has forked the community to this day with luaJIT never coming on board. 5.2 to 5.3 also broke things with the introduction of integers but mostly at the level of bindings. There is also very little included in terms of standard library and while luarocks exists many significant packages go abandoned. There are breaking language changes in the upcoming 5.5 as well though they are relatively minor.[1]

All to say I think if long term compatibility is the primary goal there are probably better languages.

Have you already discounted php or perl?

[1] https://www.lua.org/work/doc/manual.html#8

I use Lua for almost all my custom tools these days.

https://akkartik.name/freewheeling-apps

https://git.sr.ht/~akkartik/gen_site

https://redbean.dev/ could be just perfect fit for you

I use perl for the same reasons. The few dynamic scripts that I need I want to write and forget them for years. Odds are with perl they'll still work 20 years from now.

I am not sure why one would have to use an engine for this. A blog consist of mostly repetitive list of posts made from a single identical template. Any 10y old kid could just master it enough to write them in html directly. And pandoc is just installed in seconds from any package manager if one wants to use an even easier different markup language. Heck in age of microblogging and social medias most blogs aren't even seeing a new post every week, barely anyone is on dialup anymore[1] and those who do probably won't load images automatically, one could have all their posts in a year on a single html page and just anchor tags. This is certainly the case from the blog linked here.

A shell function is enough to call pandoc, update any kind of index (date or tag based) and an rss page really. I would hardly call that an engine, it is just an helper to not forget to update indexes and feeds.

[1] loading speed was the main reason blog engines used to split posts in single pages

I spend a lot of time blogging but all I use is a ~50 line Python file that converts my markdown pages to HTML, adds my template, and generates the ToC page. Then I push to GitHub Pages.

I can't imagine needing more than that. Why are these blog stacks so complex?

Author of the blog here in case anyone has questions.

>I often see wisdom in websites such as Hacker News and Lobsters around the idea of "choosing boring" because it is proven, safe, easier to maintain. I think that boring is not necessarily applicable to my case. I don't find Lua boring at all, but all that those blog posts talk about that kind of mindset are all applicable to my own choices here.

I think what is really meant by choosing boring technology is that it be simple, proven, reliable.

That's the key part. Minimize cognitive load, maximize peace of mind.

Some ecosystems are "boring" in the sense that developers are not excited about them, but they also maximize your blood pressure and chance of shipping defects. That's the wrong kind of boring!

I don't know man, every time I tried to learn Lua (to write nvim plugins and HammerSpoon spoons) I disliked the ergonomics of the language. I don't understand why people say it's an easy language—

    easy ≠ simple

Speaking of unconventional languages for web development, there's also Wt, for people who are used to building things using C++.

I found it surprisingly good and considering how little I know on how to use HTML/CSS/JS/PHP, the usual web stack, it would have taken me months or more to learn how to build an equivalent site using the standard stack (and then have to maintain it).

Of course, if you're already familiar with web development, that's the best way I guess, but for those who aren't and don't have the necessary time to learn, there are probably alternatives using languages they're familiar with.

Love the author's mentality. While I would almost definitely not pick Lua (I'd probably pick Go), I like how they arrived at their decision. Nicely done.

I liked this post, and I can totally understand where you’re coming from…

But couldn’t anything you say about Lua also be said about JS? You mentioned how Lua wasn’t batteries included, so you try to limit your libraries. Couldn’t you say the same for JS? JS itself doesn’t change much, it’s the ecosystem. Couldn’t you just pick out some small and stable libraries the same way you could with Lua?

I love the Lua language, has all the nice to have data structures, no need to think about memory management, is straightforward (keep the whole thing in your head easily) and will go forever without changes. Just stick with v5.1.

It’s so cool to take the interpreter source, type make and be using it in one minute.

Mine’s in Python. I took that route when it was a relatively obscure thing and PHP was gaining ground over CGI in Apache (at the time having a Python web server was downright weird) and stuck with it for a long time. These days it’s a purely static site generator and a bit too funky to release (there’s a variant over on https://github.com/rcarmo/sushy) but I really enjoyed maintaining it while it was a small, batteries included environment.

I considered switching to Lua (actually Fennel) but luarocks can be fiddly to use across platforms (I now run everything on ARM servers) and that pretty much was the end of that. So I’m curious as to how maintainable a Lua back-end is over time.

I've been thinking of how to make a blog simple recently, and I came across xslt. It looks really cool and seems pretty set in stone, so I thought I'd ask, what are the advantages/drawbacks of making your own tech stack versus xslt? At first glance, it seems perfectly able to handle rss and other simple linking patterns, and pretty much anything can easily be turned into an xml then xslt could be used to generate an html (server-side, or rather writer-side, not like the blog is gonna change) that you serve?

As a a javascript dev I kinda feel you and agree that the tools are moving faster than most codebases. The thing is though, you don't really have to use that many tools unless you really want to.

You can spin up a node server yourself and use web components and it will run fine probably just as long as the lua code will. It's also way easier today to just use web components and not any framework since LLMs can help you speed up the development.

Just write the blog.

(For years now I publish with Hugo/Bunny CDN ($1/month))

I from time to time wonder if I should write my own engine. Then I laugh and write a blog post.

I'd argue that you could make the same argument for (almost) every other language instead of Lua and still have the same advantages.

For example, take Javascript. With a runtime like Bun, you would have the primitives to serve some HTTP and talk to SQLite right there in the core. And here's the good news, if you carefully implement only the things that you need for your project, you probably don't need NPM. You can write it all on your own, you can peek at how NPM authors solved the problems you run into, but you still can make it all your own. This would leave you with this amazing retrocompatible language with lots of mindshare to boot.

Really, you don't need that whole ecosystem if you're solving your own problems and are not required to interface with someone else's library. And no one is forcing you to use it.

Or you could take Python, and it has a few single-file web frameworks. You can go with one of them and the standard library a very long way. No one tells you you must use any of FastAPI, Jinja, Flask, Django (anyone remembering Pyramid?), SQLAlchemy...

Or you could write it in Go, SQLite module being your only external dependency. You can even pin your go.mod to a particular version of the compiler so you're not bothered with incompatible changes, or changes at all.

Or, you could whip up Perl... but yeah. CGI.pm and DBD::SQLite are not in the core. And anything else has a litany of CPAN dependencies with their quirks. No, don't whip up Perl.

All I'm saying there's nothing that makes Lua somehow inherently more suited to your philosophy than any other mainstream language. Except maybe to be different. And you're still pulling in 29 luarocks, aren't you?

Always glad to read histories of Lua in the wild, it certainly is kind of an odd language but its simplicity and embedability makes it for a great choice for a lot of use cases.

I used to like moonscript coffescript-like syntax, but nowadays I mostly like plain lua, though Fennel looks appealing.

I do the same, but I use turboLua to host, because it has great signals support and I have my private web server wired up to all kinds of devices in my environment. TurboLua is one of those under-acknowledged tools that can do so much. Pretty good mustache support too.

LuaJIT is awesome.

I've been converting my Bash scripts/functions to it, with much success thus far.

I manage to embed lua into my project. https://rapidforge.io its incredible language I don't understand why would you need dsl if you have something like lua to use

You could also do something like this, have Caddy webserver parse your md files through a template

https://github.com/dbohdan/caddy-markdown-site/blob/master/C...

^^ the above combined with caddy git fs to have your md files cloned in memory and refresh every X interval is kind of magical. Git push a new md file and wait X minutes and your website updates.

https://github.com/mohammed90/caddy-git-fs

====

Or a one-file FastHTML (python web framework) solution:

https://gist.github.com/simonMoisselin/f63c52f087704c99b6a62...

I'm curious what the rationale is for so many blogs and even some websites these days limiting their content width to this tall-skinny column of text; the OP takes about 1/5 to 1/6 of the screen width on my (4k) display.

A large proportion of users may very well be on mobile, but do we just not do flexible layouts in 2025?

Speaking for myself at least, after you've been blogging for a quarter century or more there are some nice features you might want like pagination of your table-of-contents, RSS feeds (do it, everyone should do it), support for redirects so that ancient links mostly work across those decades (I've kept redirects from like three or four blogging systems now), tags pages for finding lost treasures and silly things. I been on both sides of "needing" comments tools over the decades, similar with things like WebMentions. With so much of blogging on social media WebMentions don't seem that big a deal this decade as it was in the one where every other person (in college) had at least one Blogger.com Blog or LiveJournal and a lot of discussions were cross-links between blogs.

Admittedly most of my blogging history has been something of a path towards simplification from hand-rolled PHP+MySQL, with custom "forum code" markup language, stuff before "blogging" was even an agreed upon term for it (and before Markdown was anywhere near as pervasive), to complex third-party beasts like Drupal, to homegrown Python (and reStructuredText), to very simple SSG tools (these days still Jekyll, but I don't like working in Ruby much, so I keep debating a switch to Lume but I don't think its Redirects plugin is yet compatible enough with GitHub Pages for my liking and I haven't tested its RSS support yet, both of which are personal hard requirements).

I had a similar setup in the past. The current stack can be explained by:

1. I don't want to rely on any external SaaS but my VPS. No github action to rebuild the site or anything like that.

2. I want to be able to post from multiple devices, which means that SSGs add more friction cause I'd need to make sure the source is up to date on all machines I am trying to post. It is not a hard problem, but opening an editor online and posting is much easier. The key to blogging is reducing friction.

Sometimes people just want to have fun

I just write HTML directly (and use GitHub pages)

I had that thought too. My own blogging engine is ~100 lines of lua that accomplishes the same as you describe, plus RSS, with one additional library for markdown parsing. The author mentions Mustache templates and WebMentions, but ten dependencies still seems like a lot; I wonder what they are.

    cmark
    dkjson
    etlua
    hasher
    lsqlite3
    lua-markdown-extra
    luafilesystem
    lub
    lustache
    multipart
    penlight
    uuid
    yaml
    http
    gumbo
    sleep
    bbcode
    cookie

Why would you build your blog to fail if some article on it ever gets popular? The fact that the most hits you ever received was 50k in a week isn't relevant; a single important post could receive that in seconds.

It basically costs nothing to pre-render a static site, which then serves several orders of magnitude faster. I'm confused why anyone would do it this way in this day and age.

I don't have a background in web development and have a genuine question.

> Your blog is your place to experiment and program how you want it

I 100% agree with your statement and people don't need to justify their hobbies. I've done really pointless things simply for lolz and because I wanted.

My question arises because I was surprised in how ... architected and (dare I say) complex the tech stack in your blog is. In my blogging days I wrote my own HTML/CSS and published it on a Internet facing server. Later, I've used CSS templates and Markdown-to-HTML to generate the static content. What is the purpose of Lua and having a database and all the other complexity for what seems like a static blog? Again, "because I wanted to experiment" or "sharpen my skills" is a totally valid answer but seeing I don't have a background in web development I am inquiring to see if there is a technical reason for doing this. Would be curious to learn what, if any, technical problem warrants such a set up :)

Why not choose Hugo (https://gohugo.io) or Zola (https://www.getzola.org ?. Both are pretty well-supported by communities and have tonnes of blog themes. (Hugo has a truckload and is the top-3 widely deployed SSG's)

What are your thoughts on something like arturo which I know is quite recent but it has a lot of features for scripting and an argument might in fact be made that it is in fact it might have too many batteries but it was an absolute pleasure to learn and I had a lot of aha moments in their discord server and the community was really pleasant to follow through actually.

I know its definitely smaller but I just want your opinions on it and what you might think of the language and I may be a bit sorry if this comes across as a little off topic but your blog really reminded me of arturo and my attempts on creating something like hugo in arturo but the project was abandoned mid way but if I remember correctly it was just some 50 lines of code to convert from markdown to complete website or even less since arturo's battery include markdown syntax as well as well as a web server and its written in nim which I cherish too.

I am genuinely interested in your opinions about it!

https://arturo-lang.io/

I currently run a blog generator I wrote in fennel and have been considering switching to pollen haha. Slightly surprised you didn’t pick fennel over lua since you used racket before. Is there a reason you didn’t?

Perhaps people's tastes vary? I find Lua an easy to use language. Easy to embed into C/C++ projects for scripting purposes. Also great when you can only spare 100 kB or so for an interpreter. (Arguably that was more important in the past.)

There are languages that compile to Lua. Have you investigated those? For example, you can use a TypeScript syntax and pick up free typechecking along the way: https://typescripttolua.github.io/

There's also the venerable MoonScript: https://moonscript.org/

And YueScript, a personal fave: https://yuescript.org/doc/

A whole list: https://github.com/hengestone/lua-languages

I would suggest using it to add scripting functionality to your own C or C++ project. That's when it really clicked for me.

When you're doing stuff in nvim or HammerSpoon, you're dealing with someone else's interface and the decisions that they've made.

Agree, I find it a PITA. I think the good reviews are in contrast to C++ and vimscript. Fine for a small embedded script, but I hope WASM or some better language ecosystem starts to fill this niche.

It all depends on what you been exposed to in the past, right? I find Lua simple because it is a minimalist language in which there are very few things to learn. You can buy "Programming in Lua" for the version you want to use and with a single book you learn about basically all of the language and its internals. That is not the same with some other languages.

I absolutely love Lua. It’s like scheme without the ((())((((()(((())))( noise.

It really depends. I learned Lua in order to contribute to kulala plugin for neovim and found the language nice and easy to learn.

Of course it has its warts, but given the topic, almost everything is better than a vimscript imho.

The thing that always sticks out to me with Lua is the and/or operators. It's such a minor thing but the way they are used drives me absolutely nuts.

it's easy, but the 1 indexes and global by default suck

I’ve never understood what people like about it

XSLT might be removed from the HTML spec soon, see discussion here: https://news.ycombinator.com/item?id=44952185

XSL is neat, and it is a functional language, but between XSL and XPath, it is quite verbose. Here's a small section of XSL I use to generate my website (not my blog):

    <xsl:choose>
    
      <!-- ... other code -->
      
      <xsl:when test="name(.) = 'subsection'">
        <xsl:choose>
          <xsl:when test="not(boolean(ancestor-or-self::*/@next)) or ancestor-or-self::*/@next != 'rev'">
            <xsl:if test="boolean(following-sibling::subsection[@listindex != 'no']/attribute::directory)">
              <link rel="next"  href="../{following-sibling::subsection[@listindex != 'no']/attribute::directory}" title="{following-sibling::subsection[@listindex != 'no']/child::title}"/>
            </xsl:if>
            <xsl:if test="boolean(preceding-sibling::subsection[@listindex != 'no'][position()=1]/attribute::directory)">
              <link rel="prev"  href="../{preceding-sibling::subsection[@listindex != 'no'][position()=1]/attribute::directory}" title="{preceding-sibling::subsection[@listindex != 'no'][position()=1]/child::title}"/>
            </xsl:if>
            <link rel="first" href="../{../subsection[@listindex != 'no'][position()=1]/@directory}" title="{../subsection[@listindex != 'no'][position()=1]/title}"/>
            <link rel="last"  href="../{../subsection[@listindex != 'no'][position()=last()]/@directory}" title="{../subsection[@listindex != 'no'][position()=last()]/title}"/>
          </xsl:when>
   
          <xsl:otherwise>
            <xsl:if test="boolean(preceding-sibling::subsection[@listindex != 'no'][position()=1]/attribute::directory)">
              <link rel="next" href="../{preceding-sibling::subsection[@listindex != 'no'][position()=1]/attribute::directory}" title="{preceding-sibling::subsection[@listindex != 'no'][position()=1]/child::title}"/>
            </xsl:if>
            <xsl:if test="boolean(following-sibling::subsection[@listindex != 'no']/attribute::directory)">
              <link rel="prev" href="../{following-sibling::subsection[@listindex != 'no']/attribute::directory}" title="{following-sibling::subsection[@listindex != 'no']/child::title}"/>
            </xsl:if>
            <link rel="first" href="../{../subsection[@listindex != 'no'][position()=last()]/@directory}" title="{../subsection[@listindex != 'no'][position()=last()]/title}"/>
            <link rel="last"  href="../{../subsection[@listindex != 'no'][position()=1]/@directory}" title="{../subsection[@listindex != 'no'][position()=1]/title}"/>
          </xsl:otherwise>
        </xsl:choose>
      </xsl:when>

      <!-- ... other code ... -->
    </xsl:choose>

And yes, there is other code I've omitted for brevity. This is used to generate the navigation links for the site. I initially write this ... prior to 2009 (that's when I moved it into git). There have been some minor fixes to the XSL over the years, but it's largely unchanged (for a reason that I hope is obvious). Yes, I still use it, because it still works, and it's for a static website.