Re:Goodbye Medium, hello Ghost
by jschulenklopper on Monday July 04, 2022 @01:45AM
(#31973823)
It’s not clear what you don’t like about static site generators. Obviously it’s more fun to build one yourself, but using Hugo, Jekyll, Nanoc yields your website faster (measured in developer-time).
Re:Goodbye Medium, hello Ghost
by jschulenklopper on Monday July 04, 2022 @01:49AM
(#31973842)
You can’t sort on code length directly, but https://jamstack.org/generators/ has a long list of possible alternatives to a DIY SSG.
There are couple great solutions that fit points you describe. One of them is Statamic (https://statamic.dev/blade) which is IMO the best flat-file CMS currently available with a lot of flexibility if you're dev and want to extend to it (it's free for solo writers). Another one that I know is GravCMS (https://getgrav.org/). I didn't have much experience with Grav, but it looks OK.
These projects are gigantic:
git clone https://github.com/statamic/cms.git
cd cms
git ls-files | wc
3133
find . -name '*.php' | xargs wc -l
...
225023 total
3133 files. 225023 lines of PHP code. Plus dependencies, which are not counted here.I am going for 1 file with 50 lines of code and no dependencies.
Good luck with that.
Personally I don't see a point in avoiding dependencies. I'll always trust more software that is built on collective wisdom with carefully picked dependencies, rather than a single (or couple) geeks that put everything in single file, avoiding dependency hell. To me that's a red flag.
With a single script with 50 lines of code, I will forever be able to pick it up again, understand it, use it, improve it. Handling will be quick. No installation, just copy the script, run it, done.
Using a project made of thousands of files and dependencies, there is way more maintenance ahead. Handling is slower and more cumbersome. If the project moves in a direction I don't like, maintaining a fork would be too much work.
I have to work on a legacy site using statamic v2 regularly and I absolutely hate it; it's slow as all hell and littered with template rendering and parsing bugs.
I'm sure v3 is nicer though from the amount of times I've searched the docs with an issue and seen "fixed in v3".
You shuld check out Server Side Includes (SSI) which enables you to do inludes, run scripts etc via the webserver (Apache, Nginx). Caddy has its own version that also handles Mardown and Frontmatter. Caddys own documentation is using this feature in fact, and the source is available for those who want to see how it works. It's called "Templating" in Caddy, not SSI.
The SSI syntax is not as lean and convenient as the syntax I am going for. It would lead to less readable and more bloated content files.
I did not find a solution that I like. I came to the conclusion that a solution should be file based and the tool that turns it into a website should be a single script:
# File based
The content, templates and assets should be stored as files on disk. No database should be involved.
# Single script
I don't think turning templates, content and assets into a website is a complex thing. Basically it just means some templating of the content according to the templates. A small script that I can easily read should be sufficient.
So I will probably write that script myself. Currently, I expect the templates to be what I call "simplified Twig style":
The content will be plain HTML. With metadata in YAML similar to how Jekyll does it: Say the script that is creating the website from the templates, content and assets is called create.py. Then create.py is supposed to be something like 50 lines of Python for the first version. And to stay under 500 lines forever. Additional functionality can be achieved via plugins: