A fun experiment I’m sure but it’s not a very convincing argument for writing your own generator. In the same way the author claims frameworks will change, so will the tools that power their custom solution and using a framework will take a fraction of the time to get going.
This isn't really all that true and is highly dependent on the stack you want.
You can run Java from 1.1 on modern JREs. PHP from the early 2000s can still work.
It all depends on what your stack looks like. If you're using the highly unstable "everything moves fast and constantly breaks" newer stuff, then sure. It's hard to see Python 3 breaking within the next 5-10 years, after how well the 2->3 changes were received.
I'd wager though even with newer languages, if you wrote something in Go, Rust, Kotlin, etc. today, it will still function in a decade.
> If the current version is doing its job, why update? It's a SSG not a browser that connects to the internet.
Because it's a hassle and you'll be left behind when you need a new dependency or there's a feature you like. By then, you have years of updates behind including depreciations, conflicts, etc. It might turn to a full-blown migration. All that is much easier if you update along.
The deal is that a lot of static site generators are very complicated (perhaps needlessly so), despite the fact that static sites are technically very simple. Perhaps some people really leverage the power of Next.js, but when I tried it, I felt that it was super heavyweight when I just needed to template html files.
Of course, that doesn't mean I need to write my own. I just used a simpler SSG. In my case Jekyll.
Being able to deploy a bunch of HTML files to static hosting services, no runtime like PHP etc. required.
If you use a CMS, it has to run somewhere. If you don’t want it on a server, you probably don’t have the same config on your dev machine. Most CMS require you to configure root domain paths etc. and they are different on your local machine. It’s all a lot more complicated than using an SSG to transpile a bunch of markdown files to HTML on a dev machine and upload them.
I prefer using markdown files in a repo and generating my website using a SSG, because I find managing plain text files and a simple CI/CD pipeline to deploy easier to manage. The tooling for writing is my editor of choice, deploy is a git push and I don’t have to run a server or long running process. I can also easily migrate to any type of hosting more easily.
I can see someone who is more used to Wordpress for example finding your workflow easier. It really mostly comes down to personal preference and what tools you are used to.
I wrote my own one also. It's ~100 lines of Go, generates the raw html that I commit to Git and which CloudFlare Pages automatically then deploys from a sub-folder for me.
I don't need to set up S3, Varnish, a server, a database, making sure my server + cms is up to date. It costs me $0, it's on a cdn and it's lightning fast + no headache. What's not to like?
Hosting a static site is simple and can even be done for free.
Even though you can make a CMS fast, with a static site you can forget about performance altogether.
Finally, it meshes very nicely with editing files in eg markdown locally, which for some people (like me who live in Neovim) is a much nicer experience than editing things in a webpage.
Cheap/free static hosting is plentiful, static sites don’t have packages I need to keep up to date to avoid vulnerabilities, and writing posts/pages in a format like Markdown makes them dead simple to migrate between systems. Additionally, using a service like Netlify or GitHub Pages affords flexibility — all I need is a git client, a text editor, and an internet connection that can manage to transmit a couple of kilobytes. Don’t even need a browser.
Aside from that, a CMS is overkill for something like a simple blog. I might consider one for a more complex site but for a blog there’s no need.
When I had a dynamic blog (DB backend, etc), I got hacked because I wasn't updating the SW often. Not having to worry about things like that is a significant quality of life difference. I want to run my life, not have my tools run them.
But frankly, let's invert the question. What exactly is the benefit of using a CMS vs an SSG like Pelican? After having used the latter for over a decade, it's dead simple. Open a file. Write your content. Run make. And publish. It's trivial to back up. I don't have to know what a cache is. I don't have to keep updating SW. What is the actual benefit of a CMS for a single user like me?
I had used pelican before; but I wanted to get a better handle on using Markdown and Jinja libraries "from the other side" as well. I would have needed to adapt my file structure or write some code to let pelican scan my idiosyncratic hierarchy to generate the posts.
Turns out Markdown is easier to use on your own scripts, than it is to tweak its configuration in pelican; and Jinja is quite simple too. Getting to use the "debug" feature to dump everything available to a template is nice.
I haven't bothered with RSS or sitemap yet, but i did do a nice calendar view render of my archive indexes; which i don't think could've been easily wedged into pelican's notion of how sites work. https://snafuhall.com/news.html
I know people write SSGs because of frustration with their existing one, but did you consider writing a tool that "publishes" to Pelican? That's kind of what I do: I write all my posts in a single org file, and have Emacs process them and output rst files for Pelican's consumption.
I did consider that; but I had other nebulous project ideas that benefit from getting better hold of Jinja, especially. Those ideas have grown considerably now, I'm glad I did my SSG, its given me more confidence in those notions.
I have used pelican for my website for a decade now.
I also host my book-draft on my site. I initially tried to get Pelican to do it, or to write something that publishes to Pelican, but it just didn't work. I ended up writing a hundred lines of fairly simply python to do the same job.
I used various SSGs for a while but the SSGs kept having arbitrary breaking changes that took a while to debug. I switched to my own little Python script 6 years ago and have slowly evolved it since then. Hasn't broken yet.
> Plus, you get to choose your own stack. Want to write your content in AsciiDoc? No-one can stop you!
I wrote a static site generator once. I used a Makefile and m4 macros!
Yes, it's true: nobody could stop me. It's much more debatable whether the "you should" part applies. I was just trying to get some common header and footer HTML into all pages of a site and do it with tools that were already installed on the hosting provider's machine.
It worked. For some reason, the person who took over the site after me did not follow in my footsteps and keep using m4.
This is presently how my website works. I'm no webdev so I'm probably committing all sorts of heresies, though. I use m4 macros to build the header/footer structure with links and coloring and whatnot. Then the content pages are emacs Org files I publish to HTML and include with the m4 macros. You can do a surprisingly large amount with Org Export.
It's a fun project to try out new tech, but you have to acknowledge that you're doing it for fun rather than any sort of necessary reason. It's like when you build a game engine and never get around to doing the hard part: building the game.
It's a procrastination time hole that mostly just distracts us from the harder, less concrete, less fun thing we supposedly set out to do in the first place. It keeps us from shipping real shit.
e.g. Quit dicking around with your SSG and write the damn blog post already. The hard part of writing something worth reading is not your tech stack.
Fun, learning something new, unlocking additional productivity in authoring posts from a customizable templating engine... I can easily convince myself of necessary reasons ;D
> e.g. Quit dicking around with your SSG and write the damn blog post already. The hard part of writing something worth reading is not your tech stack.
Alternately, for many, there's more value to themself and everyone else if they grind on those technical skills rather than distract themselves with a hobby they seem inclined to put off.
If you really want to write, you'll write. If you really want to hack, you'll hack.
A lot of people think they should write, but actually just want to hack. And that's not a problem! The image of writing provides some orientation to the hacking, but it's the hacking itself that can be most fun and enriching for them.
Do the hacking, and if you never get around to the writing, don't sweat it. If you're honest with yourself: it was never really about that, was it?
> The hard part of writing something worth reading is not your tech stack.
This project isn't about blogging, you need to look at it from a side project pov.
I think this is a common misconception, that these people want to write a blog post but are failing or procrastinating when they don't have to. When in reality, these people are developers and makers who look at their personal website from tech community's "little corner on the internet" pov.
They feel frustrated with the solution and feel they can develop better-tailored one for themselves. Putting out blog posts isn't a priority or a concern for most of these developers. They're passionate about their tools. They make tons of side projects. They're not wasting time. They don't necessarily have a more important post to write about.
If you're looking at it from a blogger/writer's perspective, sure that's wasteful, but, again, that's not what this is about.
Yep. You also see this often in small companies/statups that would write their own ticket systems and internal administrative intranets before they even had a product.
Thanks. As someone who's prone to getting hopelessly sidetracked in projects, I needed to read this. I ended up forking and customizing pug into my own templating language!
I'm not sure I'd advocate for writing a static site generator, although I'm certainly guilty of writing a few myself.
Instead I always encourage people who are trying to start blogging to do the writing first. Figure out a workflow that works for you - what time of day you prefer writing, what editor, do diagrams naturally come up in your thought stream, etc. It's way easier to get this workflow dialed in when you're doing things locally since the switching cost between solutions is that much lower.
Only when you know that you A) enjoy writing and B) have something worth sharing should you invest the time in translating your workflow to something that can deployed. That might mean writing your own SSG - that might mean just spinning up a wordpress blog.
So am I. My first one was written in C in 1995, and the resultant site run under NCSA Httpd. DIY-ing becomes tedious after several cycles, though.
On the other hand, my experience with generally available SSGs has been miserable. They keep breaking my site after a few upgrades. At this point, I am very close to just spinning up wordpress for a new site.
Well, that gives you more opportunities to have to update plug-ins and dodge vulnerabilities. Maybe a ton of people are a good fit for core WP these days, but I can't imagine the overhead of knowing what to update beyond the auto-updating core if there are a bunch of extensions.
I admin a local org's WP site, because someone has to, and thoroughly appreciate the SSG that I use personally.
Exactly. So writing your own generator doesn't differ from using a simple tool. At some point also this solution might not be robust enough.
Surely you can learn a lot in the process, but how much time does it need?
It was probably the author's fault to select NextJs for it. Maybe something simpler like gohugo might have been better: the tool is just a binary file, that doesn't require extra dependencies.
In all seriousness does everyone and their mom write a static site generator? I did because its fun and easy. Off the shelf ones can be cumbersome and not work quite how I want them to.
I've thought about it only because I hate having to figure out someone's frameworks and way of doing things.
I'm not a professional programmer and it feels like most of these are for people who already work with various frameworks professionally and know their way around these things. I am too old to spend time trying to figure out all the frameworks so I'd rather just whip up something with my half-assed skills and DIY.
I made one for a single page that I wanted to template nicely without introducing dynamic pages (wasteful since it's always the same file anyway) or JavaScript (wasteful since the layout is always the same anyway)
I'll probably do another one again soon, just so I don't have to rewrite my HTML / RSS by hand to publish another post.
Lua is a nice data language, so I just put the data and the code and the HTML fragments into one Lua file, no more than 200 lines. No worries about injection since it's all my data with no backend code at runtime.
> Off the shelf ones can be cumbersome and not work quite how I want them to.
Yeah, that's exactly why I reinvent wheels!
I ended up forking an existing templating language and customizing it into a static site generator. I'm not sure what's more difficult: changing other people's code or doing it from scratch.
You forgot 3rd option maybe hardest - just using other people code and understanding it instead of misusing it, calling it crap and going to write ones own broken thing. ;)
I don't think I ever called anyone else's work "crap" though. The software I forked is the pug templating language. It's unmaintained, looks like the author has moved on. Most of my work involved deleting the features I didn't need so that it would be easier to understand and work with. It had a Javascript parser inside it.
But yeah, I get what you mean. It's definitely the hardest thing to do.
I agree. I also wrote two static site generators, two dynamic ones, and used a few prefabricated solutions.
Then I discovered that for my writing style, org-mode with embedded scripts and plotting code really just works. I don't have to think much and I can focus on just writing. That particular authoring/publishing tool never gets in the way of what I want to express.
So I ended up patching over parts of org-mode to make it my static site generator. Sometimes the best is somewhere in between the extremes.
Writing should certainly go first. But once you have passed the first iteration of your own self-built static site generator or website the "initial" content may already be there from the previous iteration.
I certainly learned to keep the featureset of such a program to a minimum in order to have a chance to "complete" and publish it.
Btw. the article lists five points that really come close to how such a generator may work. I think mine only leaves out the CSS compilation stuff and offloads the Markdown processing to pandoc...
I'd back you up there, and maybe go one step further: Blogs are the worst use case for a ssg and you should focus on writing first. It's the articles that make or break a blog, and you might actually want the comforts of a dynamic blog engine. Plus comments, trackbacks and pingbacks, so it is a real blog.
Where static site generators shine are websites that are not blogs. Especially when generated from a data source. Then you can tailor your ssg to the data source, update the data and run the generator to update the site.
I created md2blog[1] specifically for this reason: it prevents you from making design decisions, so you’re forced to focus on writing posts instead.
I’m well aware of the irony of building yet another SSG to help people avoid doing the same. But I’m addicted to building SSGs—this one was my fifth, and I’m considering making another one (insert facepalm here).
I've written two static site generators... well one of them has a full blown UI (drag and drop, side panels etc), the other is a command line tool.
For the WYSIWYG tool I used craftjs and lexical, and ran into issues with both - bugs, difficulty doing things like having different alignment for mobile vs desktop. It was very brittle and it would be troublesome migrating data structures down the track. I've put 1.5 years into this (added my own k8s hosting on GCP too - also with its issues)!
The second command line builder took me a couple weeks to make a simple version of. I describe my pages, sections in JSON and render predefined erb templates. I scripted up deployment to Amazon S3, Cloudfront, and invalidate the cache after deployments.
It's crazy I spent so long on the Saas version and didn't get to a working website, and with the command line version now have a couple sites up!
It's a cool experience to make your own site builder, definitely learn something each time you do.
I don't mean to say you should not share it. You constructed something good, you feel pride in your device, by all means share it with the world.
However static site generation is one of those simple fun rewarding types of program to make. The programing is straight forward, the results are linear with the input, that is, there is not a huge amount of boiler plate you have to wade through to see anything. Basic batch data transformation like this is the perfect environment to metaphorically "putter around in the workshop"
Nothing wrong with using someone else's, but really, you should write your own.
These are all good arguments why somebody can write their own (unlike e.g. rolling your own crypto), but aren't convincing me at all as to why I should.
I've used a static site generator myself to host a blog, and I've been pretty happy with it, yet I've never felt the need to write one myself even for a single second.
I recently had to nuke the Linux environment where I had my Jekyll environment finely tuned (Ran it on Debian WSL). Then I realised I had to reinstall Ruby, but the current Jekyll version (or the gems I use) uses a version that needs to lock OpenSSL at a certain version because of some breaking changes. Tried to lock the version in Debian and I was having a really hard time.
Then I realised I just could grab the latest Jekyll image from Docker hub and build my website with it. And just like that I was able to build my website without dealing with any ridiculous dependency.
So yes, you should write your own static site generator because it might be a tad easier than trying to install from scratch the dependencies of whatever generator you have chosen.
It's good to have a binary that you can run, but you'd still have to deal with Go dependencies at build-time, and Go dependencies sometimes can go sideways as well (probably not as bad as Ruby, though)
I have experienced both sides. First, I've written my own generator in Python (about 300 lines) but the code was not exactly maintainable and adding features like tagging was hard. So, I looked around and picked up Hugo. While I don't like the template engine it was not too much work, to set it up and offered everything I wanted. But Hugo comes with braking changes all the times! Plus the Hugo developers don't know what semantic versioning is, so you have to figure out whether a new release works with your configuration or not.
Now I'm on the verge to write my own generator again (probably in Kotlin or in Rust), because I'm tired of Hugo's breaking changes and because I still don't like the ugly Go templates.
Hadn't heard of Eleventy, I thought Zola was where you went for speed, which they don't even bother comparing too.
Found this post comparing them & more, Eleventy (man that's annoying to type on mobile with autocorrect though!) for speed it says. https://mtm.dev/static
I'm really attracted to the Eleventy approach on the whole - there's no bloat, they don't inject any of their own js, I can move fast and only add complexity where I actually need it.
If I ever were to start blogging, that's what I would do. Or at least that's how I would start out. I can't really imagine how a site for my own blog would need more than that. Learning HTML well enough to write a blog is not any more difficult than learning the ins and outs of another markup format, plus how to use the site generator and template system.
I do the same, but after a while I got fed up with the tedium of hand-managing the metadata and all the duplication that happens if you add OpenGraph, Twitter and Dublin Core.
So I wound up storing the basic metadata in a JSON file, then I assemble the header and footer of the page with PHP, which is then rendered out to a complete HTML page.
It's not quite a SSG, but just a little help automating the boring stuff.
I too had build my own static site generator. A buddy asked if he could use it to build some sites, so I invested in it being more polished. Put a REST API in front of the engine and file management, and then an AJAX SPA on top of the API. Over the years, it's been used by a bunch of web sites - large and small. The largest was Longwood Gardens - which had hundreds of pages.
This was about 20 years ago now. Once it a while I consider refactoring/resurrecting it. But I've not found the time.
The short version: text files let you use powerful tools, not just the WYSIWYG editor supplied with your CMS. Navigating markdown files in Sublime Text is incredibly fast compared to clicking around in a PHP admin area. I can even write blog posts with Obsidian on my phone.
It also means a very simple, very fast server that runs forever without maintenance. You don't need much to serve static files.
Above all, it means source-controlled content and content branches. This is great for big changes that span multiple pages.
Nah. I'll stick with Pelican. It does what I want in a pretty straightforward way, and there are tons of themes and plugins available for it that I don't have to write.
I feel there's something to be said about a static site with a simple PHP-based search function thrown in there. Perhaps it could have even the full site content pre-generated as a data structure in PHP, for keeping in memory. Could be just word->pageId mappings, if you want to keep it simple.
135 comments
[ 4.3 ms ] story [ 208 ms ] threadYou can run Java from 1.1 on modern JREs. PHP from the early 2000s can still work. It all depends on what your stack looks like. If you're using the highly unstable "everything moves fast and constantly breaks" newer stuff, then sure. It's hard to see Python 3 breaking within the next 5-10 years, after how well the 2->3 changes were received.
I'd wager though even with newer languages, if you wrote something in Go, Rust, Kotlin, etc. today, it will still function in a decade.
I guess that's what a framework is about. You get some abstractions that make your life easier and you pay by buying into the concepts.
> [...] some friends I've talked to where still on Next.js 12 and really felt the pressure to upgrade to not fall behind even more.
If the current version is doing its job, why update? It's a SSG not a browser that connects to the internet.
So I disagree. I'll not write my own and keep the existing one as long it's not too much hassle.
Because it's a hassle and you'll be left behind when you need a new dependency or there's a feature you like. By then, you have years of updates behind including depreciations, conflicts, etc. It might turn to a full-blown migration. All that is much easier if you update along.
Of course, that doesn't mean I need to write my own. I just used a simpler SSG. In my case Jekyll.
If you use a CMS, it has to run somewhere. If you don’t want it on a server, you probably don’t have the same config on your dev machine. Most CMS require you to configure root domain paths etc. and they are different on your local machine. It’s all a lot more complicated than using an SSG to transpile a bunch of markdown files to HTML on a dev machine and upload them.
It uses Git and Markdown for easy deployments to your serverless CI/CD pipeline just as you described.
I'd love your feedback :)
https://github.com/elegantframework/elegant-cli
I don't need to set up S3, Varnish, a server, a database, making sure my server + cms is up to date. It costs me $0, it's on a cdn and it's lightning fast + no headache. What's not to like?
Even though you can make a CMS fast, with a static site you can forget about performance altogether.
Finally, it meshes very nicely with editing files in eg markdown locally, which for some people (like me who live in Neovim) is a much nicer experience than editing things in a webpage.
Aside from that, a CMS is overkill for something like a simple blog. I might consider one for a more complex site but for a blog there’s no need.
When I had a dynamic blog (DB backend, etc), I got hacked because I wasn't updating the SW often. Not having to worry about things like that is a significant quality of life difference. I want to run my life, not have my tools run them.
But frankly, let's invert the question. What exactly is the benefit of using a CMS vs an SSG like Pelican? After having used the latter for over a decade, it's dead simple. Open a file. Write your content. Run make. And publish. It's trivial to back up. I don't have to know what a cache is. I don't have to keep updating SW. What is the actual benefit of a CMS for a single user like me?
I had used pelican before; but I wanted to get a better handle on using Markdown and Jinja libraries "from the other side" as well. I would have needed to adapt my file structure or write some code to let pelican scan my idiosyncratic hierarchy to generate the posts.
Turns out Markdown is easier to use on your own scripts, than it is to tweak its configuration in pelican; and Jinja is quite simple too. Getting to use the "debug" feature to dump everything available to a template is nice.
I haven't bothered with RSS or sitemap yet, but i did do a nice calendar view render of my archive indexes; which i don't think could've been easily wedged into pelican's notion of how sites work. https://snafuhall.com/news.html
I also host my book-draft on my site. I initially tried to get Pelican to do it, or to write something that publishes to Pelican, but it just didn't work. I ended up writing a hundred lines of fairly simply python to do the same job.
I wrote a static site generator once. I used a Makefile and m4 macros!
Yes, it's true: nobody could stop me. It's much more debatable whether the "you should" part applies. I was just trying to get some common header and footer HTML into all pages of a site and do it with tools that were already installed on the hosting provider's machine.
It worked. For some reason, the person who took over the site after me did not follow in my footsteps and keep using m4.
Shame...
Anyway, my first and only SSG was based on Atom for storage, PHP for backend and XSL for client side rendering.
We called this flat file CMS which was the style at the time and...
It's a procrastination time hole that mostly just distracts us from the harder, less concrete, less fun thing we supposedly set out to do in the first place. It keeps us from shipping real shit.
e.g. Quit dicking around with your SSG and write the damn blog post already. The hard part of writing something worth reading is not your tech stack.
Alternately, for many, there's more value to themself and everyone else if they grind on those technical skills rather than distract themselves with a hobby they seem inclined to put off.
If you really want to write, you'll write. If you really want to hack, you'll hack.
A lot of people think they should write, but actually just want to hack. And that's not a problem! The image of writing provides some orientation to the hacking, but it's the hacking itself that can be most fun and enriching for them.
Do the hacking, and if you never get around to the writing, don't sweat it. If you're honest with yourself: it was never really about that, was it?
This project isn't about blogging, you need to look at it from a side project pov.
I think this is a common misconception, that these people want to write a blog post but are failing or procrastinating when they don't have to. When in reality, these people are developers and makers who look at their personal website from tech community's "little corner on the internet" pov.
They feel frustrated with the solution and feel they can develop better-tailored one for themselves. Putting out blog posts isn't a priority or a concern for most of these developers. They're passionate about their tools. They make tons of side projects. They're not wasting time. They don't necessarily have a more important post to write about.
If you're looking at it from a blogger/writer's perspective, sure that's wasteful, but, again, that's not what this is about.
Yep. You also see this often in small companies/statups that would write their own ticket systems and internal administrative intranets before they even had a product.
If you write about tech and your site doesn’t load instantly why should anyone read your words since you obviously don’t care
Instead I always encourage people who are trying to start blogging to do the writing first. Figure out a workflow that works for you - what time of day you prefer writing, what editor, do diagrams naturally come up in your thought stream, etc. It's way easier to get this workflow dialed in when you're doing things locally since the switching cost between solutions is that much lower.
Only when you know that you A) enjoy writing and B) have something worth sharing should you invest the time in translating your workflow to something that can deployed. That might mean writing your own SSG - that might mean just spinning up a wordpress blog.
So am I. My first one was written in C in 1995, and the resultant site run under NCSA Httpd. DIY-ing becomes tedious after several cycles, though.
On the other hand, my experience with generally available SSGs has been miserable. They keep breaking my site after a few upgrades. At this point, I am very close to just spinning up wordpress for a new site.
I admin a local org's WP site, because someone has to, and thoroughly appreciate the SSG that I use personally.
Surely you can learn a lot in the process, but how much time does it need?
It was probably the author's fault to select NextJs for it. Maybe something simpler like gohugo might have been better: the tool is just a binary file, that doesn't require extra dependencies.
If you don't write one, the chance is good, your blog would stay empty.
In all seriousness does everyone and their mom write a static site generator? I did because its fun and easy. Off the shelf ones can be cumbersome and not work quite how I want them to.
I'm not a professional programmer and it feels like most of these are for people who already work with various frameworks professionally and know their way around these things. I am too old to spend time trying to figure out all the frameworks so I'd rather just whip up something with my half-assed skills and DIY.
I'll probably do another one again soon, just so I don't have to rewrite my HTML / RSS by hand to publish another post.
Lua is a nice data language, so I just put the data and the code and the HTML fragments into one Lua file, no more than 200 lines. No worries about injection since it's all my data with no backend code at runtime.
This is why I wrote mine! You just put all your markdown in one folder, run it, then collect your HTML in another folder.
https://github.com/donuts-are-good/bearclaw
Yeah, that's exactly why I reinvent wheels!
I ended up forking an existing templating language and customizing it into a static site generator. I'm not sure what's more difficult: changing other people's code or doing it from scratch.
But yeah, I get what you mean. It's definitely the hardest thing to do.
Then I discovered that for my writing style, org-mode with embedded scripts and plotting code really just works. I don't have to think much and I can focus on just writing. That particular authoring/publishing tool never gets in the way of what I want to express.
So I ended up patching over parts of org-mode to make it my static site generator. Sometimes the best is somewhere in between the extremes.
I certainly learned to keep the featureset of such a program to a minimum in order to have a chance to "complete" and publish it.
Btw. the article lists five points that really come close to how such a generator may work. I think mine only leaves out the CSS compilation stuff and offloads the Markdown processing to pandoc...
Where static site generators shine are websites that are not blogs. Especially when generated from a data source. Then you can tailor your ssg to the data source, update the data and run the generator to update the site.
I’m well aware of the irony of building yet another SSG to help people avoid doing the same. But I’m addicted to building SSGs—this one was my fifth, and I’m considering making another one (insert facepalm here).
[1] https://jaredkrinke.github.io/md2blog/
I'd say this person "gets it". We spend waaay too much time bickering about what people "should" do, in my opinion.
For the WYSIWYG tool I used craftjs and lexical, and ran into issues with both - bugs, difficulty doing things like having different alignment for mobile vs desktop. It was very brittle and it would be troublesome migrating data structures down the track. I've put 1.5 years into this (added my own k8s hosting on GCP too - also with its issues)!
The second command line builder took me a couple weeks to make a simple version of. I describe my pages, sections in JSON and render predefined erb templates. I scripted up deployment to Amazon S3, Cloudfront, and invalidate the cache after deployments.
It's crazy I spent so long on the Saas version and didn't get to a working website, and with the command line version now have a couple sites up!
It's a cool experience to make your own site builder, definitely learn something each time you do.
Here are the sites I made:
https://www.madebyhelena.com https://LouisSayers.com
(Helena is my partner, I remade her site which she had created on a different platform)
I don't mean to say you should not share it. You constructed something good, you feel pride in your device, by all means share it with the world.
However static site generation is one of those simple fun rewarding types of program to make. The programing is straight forward, the results are linear with the input, that is, there is not a huge amount of boiler plate you have to wade through to see anything. Basic batch data transformation like this is the perfect environment to metaphorically "putter around in the workshop"
Nothing wrong with using someone else's, but really, you should write your own.
I've used a static site generator myself to host a blog, and I've been pretty happy with it, yet I've never felt the need to write one myself even for a single second.
Then I realised I just could grab the latest Jekyll image from Docker hub and build my website with it. And just like that I was able to build my website without dealing with any ridiculous dependency.
So yes, you should write your own static site generator because it might be a tad easier than trying to install from scratch the dependencies of whatever generator you have chosen.
Now I'm on the verge to write my own generator again (probably in Kotlin or in Rust), because I'm tired of Hugo's breaking changes and because I still don't like the ugly Go templates.
https://www.11ty.dev/
I find my lingering desire to roll out an SSG slowly fading.
Found this post comparing them & more, Eleventy (man that's annoying to type on mobile with autocorrect though!) for speed it says. https://mtm.dev/static
I'm really attracted to the Eleventy approach on the whole - there's no bloat, they don't inject any of their own js, I can move fast and only add complexity where I actually need it.
So I wound up storing the basic metadata in a JSON file, then I assemble the header and footer of the page with PHP, which is then rendered out to a complete HTML page.
It's not quite a SSG, but just a little help automating the boring stuff.
This was about 20 years ago now. Once it a while I consider refactoring/resurrecting it. But I've not found the time.
It’s much easier to write raw HTML and HTML-to-Markdown than the other way.
The short version: text files let you use powerful tools, not just the WYSIWYG editor supplied with your CMS. Navigating markdown files in Sublime Text is incredibly fast compared to clicking around in a PHP admin area. I can even write blog posts with Obsidian on my phone.
It also means a very simple, very fast server that runs forever without maintenance. You don't need much to serve static files.
Above all, it means source-controlled content and content branches. This is great for big changes that span multiple pages.