• WHY THERE WAS NEED FOR ONE MORE SSG



We all know that there are as many SSGs ("Static Site Generator") out there as
there are javascript frameworks. So why did I feel the need to create one more?

The very short answer would be: I didn't really have to, but it was convenient.

The slightly longer answer would be this;

I have written a fair number of SSGs through out my, almost 30, years of
programming. Saying it that way makes it sound like SSGs are all that I'm
doing, but that's not the case. I have written a lot of other things as well.

But I have written a fair number of SSGs. And I have written them in a fair
number of languages. I have written them in C, Python, Ruby, Go, V, PHP, and
probably a few more that I can't remember right now.

Almost everytime I have written an SSG, I have written it because I wanted to
try out a new language, and an SSG is a good way to do that. It let's you try
CLI arguments, arrays/slices/maps (whatever the language calls them), file I/O,
and a few other things that are common in most languages.

When writing these SSGs, I've always done it in a very "generic" way. Putting
focus on other people being able to use it for their everyday websites. This
means putting a lot of effort into proper logging, error handling, making it
configurable and customizable, and so on.

I do not believe this is the glorious and divine purpose of an SSG. Lately I
found the joy of approaching an SSG with the UNIX mindset, and that is; do one
thing, and do it well.

Now, obviously, an SSG has to do more than one thing. And it could be argued
that a generic SSG is doing one thing; generating static sites.

Setting up this website I wrote yet another SSG. I wielded my favorite, go-to,
language V and wrote it in a very "un-generic", and specific, way.

Every function spews out logs, on every run, about what it's trying to do and
if something went wrong. Config-values are set directly in the source code, and
requires a recompile to change. The actual website content is checked into the
same repository as the SSG source code itself.

Resulting in this tool really only being useful for me, and this website.

And I love it.

Still, I wanted to just quite go through the structure I've chosen, and why I
chose it.

--

FILE STRUCTURE


.
├── output
│   ├── assets
│   │   └── tmux.conf
│   ├── base.css
│   ├── bhyve.html
│   ├── blog
│   │   └── 1739916145-finally-got-my-new-retro,-old-school,-90s-site-up-and-running.html
│   ├── blog.html
│   ├── confd
│   │   ├── tmux.html
│   │   └── vim.html
│   ├── confd.html
│   ├── contact.html
│   ├── index.html
│   ├── main.css
│   ├── vmm.html
│   └── web_ibm_model3x_alt2.woff
├── site
│   ├── assets
│   │   └── tmux.conf
│   ├── blog
│   │   ├── 1739916145-finally-got-my-new-retro,-old-school,-90s-site-up-and-running.txt
│   │   └── 1740238810-why-there-was-need-for-one-more-ssg.txt
│   ├── confd
│   │   ├── tmux.txt
│   │   └── vim.txt
│   ├── pages
│   │   ├── bhyve.txt
│   │   ├── blog.txt
│   │   ├── confd.txt
│   │   ├── contact.txt
│   │   ├── index.txt
│   │   └── vmm.txt
│   └── tmpl
│       ├── base.css
│       ├── index.html
│       ├── main.css
│       └── web_ibm_model3x_alt2.woff
├── tree.txt
├── tsg
└── tsg.v

11 directories, 31 files


The `site` directory is where the actual content of the website is stored. Once
I run `tsg -g` the `output` directory is created, and the generated website is
stored there.

The `output`directory is being deleted and recreated on every run of `tsg -g`.

`site/tmpl/index.html` is the template for the index page. It contains three
placeholders; `____TITLE____`, `____MENU____`, and `____CONTENT____`. When
running `tsg -g` these placeholders are replaced with the actual content.

--

THE CODE

The code is very straight forward. It isn't heavily documented, but rather
variables, constants and functions are named very in a very verbose way.

The only HTML in the repositories lives in the `site/tmpl/index.html` file. The
rest of the content is pure text files. These text files are embedded in a
`
` tag in the generated HTML.

--

CONCLUSION

I'm very happy with this SSG. It's very specific, and it's very simple. It's
doing one thing, and it's doing it well.

I am quite sure that I will never use it for anything else than this website,
and thus it will not be released to anyone else. Not because I don't want to,
or that I'm shy of releasing it, but because it's so specific to this website
that it would be of no use to anyone else.

With all of that said; I have had a lot of fun creating this website, and the
SSG to back it. It has been a very small and simple project, but since I've
had a hard time motivating myself to do anything (code wise) at all lately, it
has been a very rewarding project.