Peer Pressure and Static Site Generation

So I had heard many stories about static site generation, about the possible gains in consistency, rapidity of development, of not needing to codge together some hideous mnemonic device to truly understand your sitemap as you frantically tab from html to html in your text editor of choice.
Editing naked html feels perfectly fine, but messing with styling is inconvenient, someone else already made all of these themes, and your favorite chat app has been subtly converting you to use markdown syntax instead of fields of blooming <angle brackies> as far as the eye can </see>.
I dig the keystroke economy implied here, I really do.

I assumed there must also be five or six or seventeen subtle benefits underlying the proliferation of the static-site-generation meme, and that there would be very good reasons why someone would reccommend deploying rails+railsdev+jekyll+ten-million-dependencies.
After all, rails is Mythically Good, so things that use ruby must too be, at least, pretty good?
I had never heard a clear why for the need for big fat monolithic frameworks-building-frameworks-building-frameworks to take some markdown and composite out a bunch of html and css, this only made me more confident I was just missing some universal modern-web-dev-doxa.

Anyways jekyll is a radioactive garbage fire, never ever ever try it.
Installation will fail and spit out nonrepresentative error messages about path environment variables,
other people’s installations on clean images will ‘just work’ (and yours will not),
developer-blessed docker images and guides will spit out errors instead of pushing hello world.
I personally burnt 3 hours to no clear end.

So then I tried Go-land’s popular site generator.

%packagemanager% install hugo
hugo new site bloggy
hugo new posts/title.md
hugo server -d

Magnifique. The monolothic compiled binary updates faster than my peripheral vision.
Single digit build times.
The documentation assumes you can use git.
Only took around 3 minutes to hello world and around 15 minutes to purging trial theme’s favicon from cache and getting it to render right.

What was I saying?
Anyways, Jekyll exposes an interesting approach to development and software tooling where it’s seen as normal, blessed, perhaps even the free-software-way to blithely copy 20-30 lines build steps into mister teletyper (including multiple detours to stackoverflow) just to build up the same development environment as your peers.
I wonder if the Go developers expect blazing-fast just-works, and the team that put together jekyll expect a week long hike through the mud before all the magic bits are in order and you can begin working.
I now feel much less confident that complex, slow, or delicate software packages represent refinement of technique and doctrine.
Ugly software may very well just be ugly software.