Very interesting. I've never had occasion to learn Lua, but it seems like it can do some neat things. I really like the JSON-esque template language there.

Lua can also be a cool scripting language to configure/write stuff for your editor (looking at you neovim)

I absolutely do think more people need to use Lua, especially for config. The language does have some rough edges (what language doesn't) but I always suggest Lua tables whenever a thread about JSON and its discontents comes around. It's minimalistic, it allows for comments, you don't have to quote strings. You do have to avoid the temptation to add logic. But at this point most of 'yall are using some bespoke language to generate YAML to probably generate more YAML so the horses of complexity creep have already fled the barn.

That said I'm probably too old school but I really still prefer the "old" method of templating. It's a lot easier for me to reason about the structure of the HTML site-wide when I can actually see the HTML. Of course a lot of modern programmers can't read HTML and it would just seem like noise to them, which is fine. I think a lot of the rationale behind something like this is readability and that's often a matter of what you're comfortable with. I personally worry that this would become difficult to follow once you're dealing with a large and complex site with nested and fragmentary templates.

Then again, this is basically how most modern websites work using front end templates with javascript - all of the HTML is generated, so I'm probably just being an old man yelling at clouds here.

The point about the old design parsing HTML is fair, but if you want a templating language at some point something has to do that and you don't want it to be the browser. You don't want to do what most untemplated PHP does and just toss interpolated strings into the response and just make it the end user's problem. The Lua version here inevitably winds up doing a lot of the same work. Treating a templating language like an actual language and having an actual parser may seem like overkill but it also makes features like context-aware escaping, caching and plugins easier.

I don't think that attribute order is a problem in HTML - the spec doesn't care, the browser doesn't care, you shouldn't care. But if you do care, I don't think arranging attributes in alphabetical order is the best solution. There is apparently an informal HTML attribute ordering standard for this: (https://dev.to/bawa_geek/a-standardised-approach-to-html-att...). Which again, doesn't really matter with HTML but does match what developers would expect to see.

If I had to suggest improvements in terms of architecture it would be to either use something like Teal (a compile-to-lua language that lets you add types,) and LuaJIT, which has plugins that improve the performance of strings and tables. And rather than dynamically generating everything, statically cache as much of the HTML as possible.