Hacker News Reader

Something similar happened to me when I was using static site generators. In fact one that I was really enjoying even switched programming languages between 1.x and 2.0.

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...

Just want to chime in that one can use a static site generator without upgrading it. Or upgrading it infrequently.

I’m currently on Hugo 0.80.0 and who knows, it might take years before I upgrade it.

That makes sense to me. No dis on static site generators, it just so happens that those were the lessons I learned while trying them out.

> I'd rather use my LibreOffice HTML template and simple PHP controller

Could you tell me more about this? I've had a similar idea but the HTML that LibreOffice generates is very gross

It's a simple injection controller for adding links and markup. Very rough. It doesn't do much about the existing HTML, which I felt was mostly workable, or workaround-able. :-) You can see some output here:

https://www.friendlyskies.net/fmk/

If you use "bundle exec jekyll serve" you shouldn't have too much problems locally as it just rebuilds the pages that change on every save. A minute to deploy the finished version is not terrible by any stretch for a blog IMO.

I used to think the same until I tried Hugo and it generates my site in milliseconds. Deploying from there also takes less than a second.

It is really astonishing what power our devices have and how little that power is utilised by many tool chains.

You are spot on. I had the same experience. I wrote about it here: https://gavinhoward.com/2019/12/performance-matters-jekyll-v...

I wrote my own blogging software, and went through a similar journey. Initially I wrote a simple Perl script which would read all the posts I'd written (as markdown), insert them into a temporary SQLite database, and then using the database I'd generate output.

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!

Don’t know about Jekyll but with Hugo you just run hugo server in the Git repo and it will give a a live preview that you can view in the browser, served locally.

It’s very fast.

I have a mockup blog with ~90 pages and it takes 190 ms to generate the whole site.

Jekyll would probably handle that in a few seconds.

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.

There was a company on here the other day talking about their product, built on top of Docker. I wish I'd bookmarked it.

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.

Can't good old make do partial recompilation with ease?

Correct me if I'm wrong, but don't you have to formally map out all of your inputs and outputs for partial recompilation to work?

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.

> Correct me if I'm wrong, but don't you have to formally map out all of your inputs and outputs for partial recompilation to work?

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...

Are you referring to LayerCI, possibly?

Must be, since algolia shows me questions from 8 days ago that sound familiar.

Is it slow to regenerate a single post even with Jekyll’s ‘—incremental’ mode?

yes because of a bad design decision I made to create a custom "related posts", which is a code that searches all my markdowns to pick the best pages and add to the current page. so even with `--incremental` it take quite some time to regenerate

Not really fair to blame the performance on Jekyll, then. Presumably you could build yourself to the same issue with any other generator.

that's a good point and I agree with you

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)

I wonder if you could save some time with some caching?

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.)

I wouldn't call that a bad design decision if all it needs is a `if Jekyll.env == "production"` :)

20 years ago that was my first useful custom CGI script, it took the metadata of the current page and ran a grep for pages with similar tags. Running that was really fast and flexible until I published it and got my first ten simultaneous visitors.

Then I learned about how hard it is to use a cache.

I feel your pain.

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 just wanted to say how much I've enjoyed using simpleisbetterthancomplex over the years.

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.

Side note - big fan of your blog. You're killing it at SEO.

hey, thanks! :D

I made goode experiences with Lektor (a static site generator). If you run it locally using "lektor server" you see your page plus admin backend. Once you click (or type) deploy the page gets statically built and copied somewhere via rsync.

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

Some static generators like eleventy and Gatsby offer partial builds, only building the new posts etc. which should be considerably faster. Another thing would be to run an empty version of your site with only the text you're working on and when it's done, moving it to the proper site and building it then

Thanks for your Blog! It's a great resource - I love the generic form template and signal blog post. It is really great and I recommend it to anyone who uses django

Have you thought about hosting it on https://writefreely.org/?

you do realize you can hot reload and preview in a local browser before deploying? pretty inefficient to deploy just to check your changes