Since that time I look for the people and community behind the project, and try to find signs of stability and long-term care. After that I look at open formats rather than open and flexible architecture-chains. For example, I'd rather use my LibreOffice HTML template and simple PHP controller on a more monolithic (but open) platform than connect a bunch of technologies together to create a build process with a bunch of moving, quickly developing, interdependent parts.
Not sure it's the best answer, but it has worked better to use more monolithic software, even blogging software that's been in steady, if slow development since the early 2000s...
I’m currently on Hugo 0.80.0 and who knows, it might take years before I upgrade it.
Could you tell me more about this? I've had a similar idea but the HTML that LibreOffice generates is very gross
It is really astonishing what power our devices have and how little that power is utilised by many tool chains.
Having the SQLite database made cooking up views really trivial (so I wrote a plugin to generate /archive, another to write /tags, along with /tags/foo, /tags/bar, etc). But the process was very inefficient.
Towards the end of its life it was taking me 30+ seconds to rebuild from an empty starting point. I dropped the database, rewrote the generator in golang, and made it process as many things in parallel as possible. Now I get my blog rebuilt in a second, or less.
I guess these days most blogs have a standard set of pages, a date-based archive, a tag-cloud, and per-tag indexes, along with RSS feeds for them all. I was over-engineering making it possible to use SQL to make random views across all the posts, but it was still a fun learning experience!
It’s very fast.
I have a mockup blog with ~90 pages and it takes 190 ms to generate the whole site.
But, once you approach two to four or five hundreds, it can quickly add up to a minute or two, making it impractical to say the least.
One solution is to run `jekyll build`, which will just build HTML to a directory, and then just removing old Markdowns and serving those generated HTMLs directly via nginx or something.
I've honestly given up and switched to Ghost, where I don't have to worry about that sort of stuff.
Their secret sauce is, effectively, partial evaluation in Docker images. They run the code to detect if any of the changes in a layer have side effects that require that layer to be rebuilt (which invariably causes every layer after to be rebuilt)
I mention this because if I'm editing a single page, I would like to be able to test that edit in log(n) time worst case. I can justify that desire. If I'm editing a cross-cutting concern, I'm altering the very fabric of the site and now nlogn seems unavoidable. Also less problematic because hopefully I've learned what works and what doesn't before the cost of failure gets too large. It would be good if these publishing tools had a cause-and-effect map of my code that can avoid boiling the ocean every time.
I believe the last time I touched make was to fix an exceedingly badly mapped out chain of cause and effect that would consistently compile too much and yet occasionally miss the one thing you actually needed.
Partial evaluation works out the dependencies by evaluating all of the conditional logic and seeing which inputs interact with which outputs.
Make needs that information, but that doesn't mean you need to be the one to catalog it. I found this article pretty useful [1]; in a nutshell, many compilation tools (including gcc, clang, and erlc) are happy to write a file that lists the compile time resources they used, and you can use that file to tell Make what the dependencies are. It's a bit meta, so it made my brain hurt a bit, but it can work pretty well, and you can use it with templated rules to really slim down your Makefile.
(I've tested this with GNU Make; don't know if it's workable with BSD Make)
[1] http://make.mad-scientist.net/papers/advanced-auto-dependenc...
to be honest jekyll still serves the purpose really well (especially for the reader)
the site is still sitting on an inexpensive entry-level cloud server, it's relatively fast, serves 300k+ page views every month and it give me some passive income
i'm pretty sure that if one uses the framework properly it can still hold on very well
i think what left me with a mixed feeling about static site generators is that it is constantly holding you back whenever you think about growing your website. i ended up building a django api that runs on the same vpc as the blog itself, and i used it to expand some features, like reading from google analytics the total page views for a given blog post, or consuming the disqus api to list the latest comments on the home page. this kind of thing.
managing the posts in static files is quite challenging as the number of posts grows. at some point you will want to change some info, or add a certain metadata and you will need to write a script to walk the _posts dir and edit the files (maybe there's a better way of doing that :P)
Find all posts related to "django", select the top 3, pin them as the related posts for all django entries? You'd trade out some uniqueness and slightly increased memory usage to gain speed.
(I just got started blogging and found https://github.com/sunainapai/makesite python static site generator worked well for me. Obviously you're probably a bit far in to switch horses by now.)
Then I learned about how hard it is to use a cache.
I’d make a simple static blog generator but then grow tired of some shortcomings, which then led to abandonment.
My current blog has an HTML rendered homepage but all the posts are text files. https://blog.webb.page
I run a Django development agency, and I've passed around links to your tutorials more times than I can reliably estimate; hundreds of times :)
It's a great resource, thank you for it.
You can still have the sources in a git for quick rollbacks.
What I like about lektor over most CMS solutions is that it is more easily adjustable. Basically Jinja2 and python held together with glue
After a year or so I migrated to a 5 USD droplet on Digital Ocean (back then GH Pages didn't offer https for custom domains) and integrated with Github webhooks to automate the deployment when pushing new markdown to the main branch.
Over the time it indeed started to degrade. The build time takes almost a minute, but after building the website is just a bunch of static html pages.
Nowadays it is annoying to write new posts because I like to write locally and refresh to browser to check if it's looking good or not. So I would say it degraded for me but for the reader it's still as fast as it was when there was just a couple of posts.
I thought about migrating the blog to something else, but because I used some custom markdown extensions for code highlight and other things, it would be painful to migrate all the blog posts. So I've been postponing it since 2019.