This site no longer uses the RtflSite system. It worked, but pretty poorly. It was also very slow.
I liked the fine-grained control it gave me, but a lot of things were pretty hacky. For this reason, I wrote a new static site generator in JavaScript which is a lot simpler but more powerful. It's called simple-js-ssg and allows sites to be written in a manner similar to traditional JavaScript web applications.
I wrote a new static site generator based on simple-js-ssg called simple-jsx-ssg. It uses Bun for TypeScript and JSX support without a build step. Otherwise, it's very similar to simple-js-ssg.

The information in this post is outdated.

There was a point where I was very into dynamic systems, dynamic sites, a lot of moving parts, etc. Large amounts of dynamic elements and user-interaction on every little thing was ultimately what I wanted to achieve. At that point I hadn't really figured out how much time and effort something like that takes, and how little it ultimately matters.

It took a long time for me to figure this out, but when I did, I realized that the only way to satisfy the need for templating and dynamic elements that are present in dynamic sites is by using a static site generator. There are a few options for generating static sites, and for anyone who actually wants to do it for themselves, I suggest Hugo. I haven't used it, but it seems like a good choice for people who don't want to build their own solution since it has a lot of features and is pretty fast.

So what'd I do to solve my problem?

I built my own, of course. And not only did I build my own, but I built it in my own programming language Rtfl. Why did I do that? Because it's fun, and there's not really much of another reason. I guess because I know my own system entirely, from inside to outside. Not a great habit to get into, but it worked and ended up being a lot of fun to create. In fact, this blog itself was originally just an exercise in creating a proper "dynamic" site with a static site generator. One of the most important things in software engineering (using that word specifically for engineering, not just programming) is to have an application, implementation, etc for whatever you're building. It ties into the concept of dogfooding in how it requires you to use your own software to improve it. It gives purpose as well, so you will have more motivation to improve it and use its features thoroughly.

So what does this static site generator look like?

It looks like if you mixed EJS with Rtfl. This is what the syntax looks like:
##name my_page
##arg name
<h1>Hello world!</h1>
<?rtfl if true { ?>
    <p>Something conditional</p>
<?rtfl } ?>
<p>Your name is <?rtfl= name ?>!</p>
As I said above, it shares a lot of similarities with EJS, like IF statements having markup inside. This is because before render time, templates are translated into actual Rtfl functions. So the template above would be translated into:
func template_my_page(name) {
    local __tmp = ""

    __tmp = concat(__tmp, "<h1>Hello world!</h1>\n")

    if true { 
        __tmp = concat(__tmp, "\n    <p>Something conditional</p>\n")

    __tmp = concat(__tmp, "\n<p>Your name is ")
    __tmp = concat(__tmp,  name)
    __tmp = concat(__tmp, "!</p>\n")

    return __tmp
(Note, I added proper whitespace and indentation manually.)
As can be seen, the template was translated into an actual Rtfl function. These functions are called at render time, but can also be called by templates themselves, in order to re-use components and provide utilities. All templates share the same global functions and global variables, so they are also able to share data and utilities between eachother. For instance, all blogs enumerated on the blog homepage are available to other templates, so this page can report that there are a total of 10 posts on the site right now.

Another example of this is when I linked to Wikipedia. The code I wrote looked like this:
<?rtfl= template_wikipedia("Eating_your_own_dog_food", "dogfooding") ?>
Re-using components in a centralized fashion makes sites easier to build and especially to maintain. Imagine trying to update all headers on a site that uses no import, just consider how time-consuming that'd be.

Using a static site generator lets you have the best of both worlds: not have a dynamic backend, and not have to deal with tedious tasks that editing static HTML requires.