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.
All static site generators are known to increase in complexity over time until they match PHP features w/ uglier syntax & poor documentation
— Miller Medeiros (@millermedeiros) June 27, 2013
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).
"It just works" is fantastic, when it really does just work. But it's brutal when it doesn't actually work. Then I prefer transparency.
— John D. Cook (@JohnDCook) February 2, 2013
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.
PHP is a very powerful *template* language, the problem starts when you decide to treat it as a real programming language.
— Miller Medeiros (@millermedeiros) January 23, 2013
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).
