top | item 26069229

(no title)

vitorfs | 5 years ago

I started my blog about python/django (https://simpleisbetterthancomplex.com) using Jekyll and hosting on Github Pages and it was pretty good to get started because back then I wasn't sure if I would keep it up or not.

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.

discuss

order

themodelplumber|5 years ago

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

cpach|5 years ago

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.

tn1|5 years ago

> 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

wazanator|5 years ago

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.

spockz|5 years ago

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.

stevekemp|5 years ago

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!

cpach|5 years ago

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.

input_sh|5 years ago

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.

hinkley|5 years ago

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.

CameronNemo|5 years ago

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

jdotjdot|5 years ago

Are you referring to LayerCI, possibly?

Lammy|5 years ago

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

vitorfs|5 years ago

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

NetOpWibby|5 years ago

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

JonAtkinson|5 years ago

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.

dopeboy|5 years ago

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

vitorfs|5 years ago

hey, thanks! :D

atoav|5 years ago

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

httpsterio|5 years ago

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

number6|5 years ago

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

z3ncyberpunk|5 years ago

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