Why I chose Lua for this blog

Reasons for Lua and Current Stack

  • OP uses Lua with SQLite and CGI for a dynamic blog to:
    • Provide an admin interface and write/edit posts (Markdown) from a phone.
    • Run queries for “recent posts”, tag pages, etc.
    • Avoid external SaaS (no GitHub Actions, no separate build step) and rely only on a VPS.
  • Lua is chosen largely for familiarity, small codebase, ease of tinkering, and stable, minimal core. OP prefers “what makes me happy” over an objectively optimal stack.
  • Many dependencies exist mainly to support legacy content and IndieWeb features (Webmentions, Micropub, YAML front matter, etc.).

Static vs Dynamic and Handling Traffic

  • Critics argue that:
    • Static generation is nearly free, dramatically more scalable, and should be default.
    • A popular post could spike to 50k hits in seconds and overwhelm a dynamic setup.
  • OP and others respond:
    • Current performance (millisecond render times) is “good enough”; premature optimization isn’t worth extra complexity.
    • Previous SSG setup made incremental rebuild logic and maintenance annoying.
    • If a personal blog briefly fails under load, that’s acceptable; it’s a hobby, not critical infra.
  • Alternatives suggested: Caddy + markdown, simple SSGs, client apps that publish to static hosting.

Learning Projects and Security Concerns

  • Several commenters celebrate “roll your own blog engine” as an ideal learning project covering templating, CRUD, and deployment.
  • Others warn that any custom dynamic app is riskier than static or a mature framework: input sanitization, CSRF, etc. are easy to miss.
  • Counterpoint: risk can be contained via isolation (containers, microVMs, separate VPS). Failure can be a valuable learning experience, especially for developers.

Lua’s Ergonomics and Ecosystem

  • Mixed reactions to Lua:
    • Fans praise its simplicity, small interpreter, embeddability, and long-term stability (especially 5.1).
    • Detractors dislike 1-based indexing, globals-by-default, and ergonomics compared to Python/JS; “simple ≠ easy”.
  • Discussion of:
    • Fragmentation between 5.1/LuaJIT and newer versions; slow but breaking releases.
    • Upcoming changes (e.g., better global control in 5.5).
    • Alternatives/adjacent tools: LuaJIT, Fennel, MoonScript, Arturo, OpenResty, redbean, TurboLua.

“You Could Do This in Any Language”

  • Several participants note that the same “small core + few dependencies” philosophy could be applied with JS (e.g., Bun), Python, Go, Perl, or PHP.
  • Consensus: Lua isn’t uniquely capable; the choice is mostly about personal taste, ecosystem comfort, and desired “boring but stable” operational characteristics.