(no title)
vitorfs | 5 years ago
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.
themodelplumber|5 years ago
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...
cpach|5 years ago
I’m currently on Hugo 0.80.0 and who knows, it might take years before I upgrade it.
tn1|5 years ago
Could you tell me more about this? I've had a similar idea but the HTML that LibreOffice generates is very gross
wazanator|5 years ago
spockz|5 years ago
It is really astonishing what power our devices have and how little that power is utilised by many tool chains.
stevekemp|5 years ago
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!
cpach|5 years ago
It’s very fast.
I have a mockup blog with ~90 pages and it takes 190 ms to generate the whole site.
input_sh|5 years ago
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.
hinkley|5 years ago
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.
CameronNemo|5 years ago
jdotjdot|5 years ago
Lammy|5 years ago
vitorfs|5 years ago
NetOpWibby|5 years ago
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
JonAtkinson|5 years ago
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.
dopeboy|5 years ago
vitorfs|5 years ago
atoav|5 years ago
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
httpsterio|5 years ago
number6|5 years ago
rewir|5 years ago
z3ncyberpunk|5 years ago