Adding Live Reload to a Static Site Generator Written in Go
11 points by bugsmith
11 points by bugsmith
It's funny how we all re-implement the same things in certain aspects. I have more or less the same features in my static site generator, which is specific for SourceHut wikis: staticman :D
Feel free to crib any of the features that catch your eye.
Oh I'm definitely going to comb through staticman for features to steal :D
You've also reminded me that I need to seriously update the documentation of Lumaca.
I guess it makes sense that we all implement that same features - we see them and want them, but the fun is in the building.
A much simpler way (like 30LOC) to do this is to go:embed all your source assets into the binary, make it hash itself at startup, add an endpoint that returns the hash, and poll that.
go:embed all your source assets into the binary [...] poll that [hash]
All that does is tell you that the source assets embedded in the binary don't match the disk (which is just step 1 of "live reload"!) Would seem to be wildly inefficient - if you're hashing the source assets to check against the hash returned by the binary (whilst making sure you're handing them to the hash in the exact same order[0]), you're having to read and hash all your source assets every time you want to check, right? Whereas the fsnotify method will tell you which file has changed and when - no busy-hashing involved.
Have I missed something obvious?
[0] Unless you're hashing each file individually in which case you're ok for ordering (but "the hash" implies it's a singular hash over many files.)
As per https://lobste.rs/s/qnnok5/how_make_your_own_static_site_generator#c_nwj1tk, I would encourage you to extract watching, serving & server-sent event hook into a separate binary. Go should allow you to publish a prebuilt statically linked binary, and a simple live-reload server is I think missing?
I would certainly use that, and I bet, with some marketing, a lot of other people would!