My head is spinning. I appreciate it’s neat to enable dynamic-like workflows on top of a blog that’s actually just static files, but I would take a makefile+rsync on my laptop over this any day.
I guess this enables webmentions which my setup doesn’t, but … wow, what a cost of entry. Is there some other advantage I’m missing?
I guess this enables webmentions which my setup doesn’t, but … wow, what a cost of entry. Is there some other advantage I’m missing?
I feel exactly the same!
I’m very fond of the static website approach. My website has always been static. This approach is really simple and has very few moving parts. For instance:
My website is hosted on a raspberry-pi sitting in a associative datacenter. Some of my posts reached the top section of some link aggregators (here, hn, reddit, …); my webserver just took the hit pretty easy, the load never exceeded 0.4. When I see some websites sitting on fat ass server being ddosed in the same condition, I feel like serving static files makes your website clearly easy to maintain/scale.
Yesterday, my HDD failed. Shit happens [1]. I was just a make publish and a DNS zone modification away of being online again. I could never done that with a dynamic website.
However, I’m also very fond of the ideas pushed by the indie web community. The amount of tooling they built to make POSSE [2] easier is pretty impressive. The whole micropub/microsub workflow and associated UX is amazing. I can’t make this fit with my current workflow; it drives me crazy.
I built a whole micropub/sub prototype based on @myfreeweb’s sweetroll using a hugo backend and generating webpages on the fly. It does not work reliably, it is crazily complex. It feels like I’m re-inventing a whole cache system. I feel like the two approach simply does not fit together. (I’ll probably write an article on this experiment in a near future).
So, in the meantime, I try to advertise the indieweb values by posting stuff they write to a broader community (here for instance :)) and pushing their standards where it is possible without adding too much complexity. I do that in the secret hope somebody smarter than I am will manage to make the two approach fit together :D
[1] Have to admit I have been lucky on this one. My backups are fired at 12:00, the hard-drive failed at 2PM. I almost did not lose anything at all.
[2] Publish (on your) Own Site, Syndicate Elsewhere”.
My head is spinning. I appreciate it’s neat to enable dynamic-like workflows on top of a blog that’s actually just static files, but I would take a makefile+rsync on my laptop over this any day.
I guess this enables webmentions which my setup doesn’t, but … wow, what a cost of entry. Is there some other advantage I’m missing?
I feel exactly the same!
I’m very fond of the static website approach. My website has always been static. This approach is really simple and has very few moving parts. For instance:
However, I’m also very fond of the ideas pushed by the indie web community. The amount of tooling they built to make POSSE [2] easier is pretty impressive. The whole micropub/microsub workflow and associated UX is amazing. I can’t make this fit with my current workflow; it drives me crazy.
I built a whole micropub/sub prototype based on @myfreeweb’s sweetroll using a hugo backend and generating webpages on the fly. It does not work reliably, it is crazily complex. It feels like I’m re-inventing a whole cache system. I feel like the two approach simply does not fit together. (I’ll probably write an article on this experiment in a near future).
So, in the meantime, I try to advertise the indieweb values by posting stuff they write to a broader community (here for instance :)) and pushing their standards where it is possible without adding too much complexity. I do that in the secret hope somebody smarter than I am will manage to make the two approach fit together :D
[1] Have to admit I have been lucky on this one. My backups are fired at 12:00, the hard-drive failed at 2PM. I almost did not lose anything at all.
[2] Publish (on your) Own Site, Syndicate Elsewhere”.