2013.10.20

Static Site Generators

Yes, they are popular; Yes, there are hundreds of implementations; Yes, they all suck; Yes, this is sort of a rant; Yes, I also wrote a few static site generators before; Yes, I have this opinion for a while; Yes, a lot of people will disagree…

Since my goal with this post is to question the current trend towards static site generators, lets start with a bold a statement: PHP is the best static site generator that you can get.

Why I’m saying that PHP is a static site generator? Because everything that is outside of <?php ?> tags is treated as raw text, just like any other template language. Many simple sites uses PHP just because of includes, vars and simple loops; in the same way as most static site generators.

Someone might argue that a static site generator outputs plain HTML files during some build step and don’t require a server/interpreter during runtime. So what?

curl http://localhost/ > index.html
curl http://localhost/foo.php > foo.html
...

Boom! now you have static HTML files generated from you basic PHP scripts.. no restrictions on your code structure, no need to teach your team how to use a new tool, no need to learn a new template language, no dead ends…

There is a very big chance that in 5+ years PHP will still be widely used, good luck with your static site generator 2 years down the road; when nobody is maintaining it anymore, bug reports pile up, incompatible updates, poor documentation… – That’s what I call a technical debt, being locked to a tool that doesn’t fit your future needs (and that you can’t easily tweak).

I’m not saying that PHP is perfect, it is far from that, but PHP is the right tool for the job – even if for all the wrong reasons.

Reducing boilerplate is good, problem is when the tools don’t fit your needs. Frameworks like Laravel, Django, and Sinatra; seems a better investment than configuration driven tools if your team already know how to use them and/or would benefit greatly from it. I’ve been using plain PHP a lot for simple projects - just a bunch of includes to avoid duplication and some global vars/helpers to toggle the behaviour - and it’s been great.

Don’t introduce complexity unless the gain is greater than the cost, in many cases it doesn’t payoff.

PS: you could replace PHP with any other language that supports includes, loops and multi-line strings; and that your team is familiar with. Using PHP as an example because it is popular, well documented and don’t need external libraries/frameworks to be productive (it’s already a superset of most template languages).

Tags: , ,

Comments

Anderson Arboleya

You have a good point and I bet you got frustrated with some generator at some point(?), but I don't think there's one tool to fit all needs though. Syntaxes is like flavors, some you like, some you do not. YMMV. Some people may prefer working with pure html, other using pre-processed languages. How to please all?

As you said, obviously many languages serves the purpose of building websites and doing a little script to take snapshots of every page down to raw html files is also easily achievable, be it using some language of choice to build your own script, or also using some other tool for web scrapping -- a good point you have not mentioned.

However, to say that relying on some project that fits the task of static site generator is completely bad because of maintainability matters sounds is a little extreme, and could pushes extreme readers to a deprivation from using many nice tools out there that could fit them better.

Freedom of choice is beautiful, but it's important to be able to evaluate each option in order to assure you're taking the right path regarding your needs. :)

Great rant. I found this post while hunting for some "perfect" ultra-simple static site generator system to use for prototyping. Turns out that it's PHP.

[…] amam, outros odeiam. A verdade é que (uma vez a sua ferramenta devidamente configurada) eles tornam a publicação de […]

Leave a Comment

Please post only comments that will add value to the content of this page. Please read the about page to understand the objective of this blog and the way I think about it. Thanks.

Comments are parsed as Markdown and you can use basic HTML tags (a, blockquote, cite, code, del, em, strong) but some code may be striped if not escaped (specially PHP and HTML tags that aren't on the list). Line and paragraph breaks automatic. Code blocks should be indented with 4 spaces.