Make it static

Damn omnivore

Last week Green Ruby was sent with a delay. For some obscure reason my publication was blocked by Omnivore the automated fraud detection system from Mailchimp. My account was instantly blocked and it was pending a human review. Of course the human review made it clear that the publication was clean but it took 2 days and I still don’t know why this omnivore beast went mad at me.

They declare it’s getting smarter everyday, but really, we are still safe. The reign of the intelligent computer over the human species is not close yet.

Make it static

Dynamic websites are great. But that’s a long time I wonder about the trade-off. If you update your blog every day, and have 500 visits, your dynamic setup is useful when you edit, and it’s a cost for each visitor. There are so many web applications that could be more clever about it. Especially that now the computation is going more and more client side.

Static pages have a really unbeatable response time, their security is really reliable, they are low dependencies and easy to deploy with a rsync.

When I get to think about making a new website, I always ask myself if it’s an application or a website. For sure some kind of applications are computation intensive. Making it all dynamic could make sense. But frankly, if it’s a website, it can have some fancy dynamic features without a huge dynamic setup.

I have seen so many websites made with php, mysql, 5 tables and 20 entries in each. Such site should have pre-generated content, data available as static json files, as a bit of js to make the magic happen. If there is a lot of data, fine, an API server makes sense.

So next time you gotta prepare a website, ask yourself how easy it could be to generate it and use tools like Jekyll or Middleman. Or you can even handle things with custom rake tasks (like I do for Green Ruby website), that’s not that hard. It’s a matter of cyberspace ecology.