It's not as bad when you keep it as simple as possible. The first version of the 'generator' for my blog (shameless plug: rubenvannieuwpoort.nl) was written in one or two days. It's just a couple of bash scripts (and one Python script), really (see https://github.com/rubenvannieuwpoort/static-site-generator). Now I haven't wrote a lot since, but that has to do more with perfectionism and being busy).
I was addressing the perfectionism - which paul graham's article talks about in a counter intuitive way (sort of "we will not serve a wine before it's time")
As to "paying" I was trying to think of venues where you can publish without compromising.
I think the answer might be something like a $5/mo droplet or something on a cloud service.
There are nice venues to publish free, like here on hn, but you lose control of your work - for example, it could be taken down, it could be heckled, etc...
Wait, something's slightly off with kramdown - this isn't right - 12 hours later you're recompiling to update dependencies, and your version of ruby is out of date.
This is Jekyll specific, so YMMV - but if you're like me, probably not by much.
The argument about tolerable complexity definitely resonated with me.
However, I think the author may have failed to consider that the people using Gatsby/Next/etc. for their personal blog aren't necessarily doing so because they believe it is the best tool for the job. It's might be a good excuse to explore some new technology. Other times it could be the tool someone is most familiar with.
As for the solution, I believe existing tools like make could have solved the "rework" problem.
For reloading, I'm not sure I understand the leap from "I need to inject some JavaScript" to "I need to be able to parse a HTML document". If you're already replacing placeholders in the template with your content, why not another with some JavaScript?
There's also an interesting trend happening with development tooling like Snowpack and Vite. Instead of recompiling your assets when things change, why not let the HTTP server compile them on the fly? You don't need to worry about dependency graphs because the browser will request the assets it needs. Your development server can send events when a requested asset is touched and some injected JavaScript can handle the reloading.
And then the whole solution dies because it's slow and not scalable due to the hot reloader plus number of users.
A CDN is pulled in holding a list of changes or something, adding yet more complexity that could have been avoided using a performant caching web server in the first place, and a properly implemented hot reloader.
(Well into millions of requests.)
How did you arrive to the conclusion that our Machinist (the protagonist in this case) would use this go live? Very interested to know if something about the conclusion pointed you in that direction.
Side note: It's a pretty website, but the text is quite hard to read.
Note necessarily a problem if you want to filter out people that favor content over form, just something to be aware of.
Step 1 - Set up your own custom blog
Many steps later..
What happened? Who am I? What did I even want to write about?