Sim, eles são populares; sim, existem centenas de implementações; sim, todos elas são uma droga; sim, isso é um tipo de discurso retórico; sim, eu também escrevi alguns geradores de sites estáticos antes; sim, eu tenho essa opinião já faz algum tempo; sim, um monte de gente vai discordar…
Já que o meu objetivo com este artigo é questionar a tendência atual para geradores de sites estáticos, vamos começar com uma afirmação ousada: o PHP é o melhor gerador de site estático que existe.

Por que eu estou dizendo que o PHP é um gerador de site estático? Porque tudo o que está fora das tags <? php?> é tratado como texto bruto, tal como qualquer outra linguagem de template. Muitos sites simples utilizam o PHP só por causa de includes, vars e loops simples, assim como a maioria dos geradores de sites estáticos.
Alguns podem argumentar que um gerador de site estático gera arquivos HTML simples durante algum passo de compilação e não precisa de um servidor/intérprete durante o runtime. E daí?
curl http://localhost/ > index.html curl http://localhost/foo.php > foo.html ...
Boom! Agora você tem arquivos HTML estáticos gerados a partir de seus scripts PHP básicos… Sem restrições na sua estrutura de código, sem necessidade de ensinar à sua equipe como usar uma nova ferramenta, nem de aprender uma nova linguagem de template, sem becos sem saída…
Existe uma grande chance de que em mais de cinco anos o PHP ainda será amplamente utilizado. Boa sorte com o seu gerador de site estático daqui a 2 anos! Quando ninguém mais der manutenção nele, os reports de bugs estiverem acumulados, updates forem incompatíveis, documentação pobre… – Isso é o que eu chamo de uma dívida técnica, estar preso a uma ferramenta que não atende às suas necessidades futuras (e que você não pode ajustar facilmente).

Eu não estou dizendo que o PHP é perfeito, ele está longe disso, mas é a ferramenta certa para o trabalho – ainda que por todas as razões erradas.

Reduzir o boilerplate é bom, o problema é quando as ferramentas não se encaixam às suas necessidades. Frameworks como Laravel, Django, e Sinatra parecem um investimento melhor do que ferramentas orientadas à configuração, se sua equipe já sabe como usá-las e/ou se beneficiar muito com isso. Estou usando muito o PHP puro para projetos simples – só um monte de includes para evitar a duplicação e alguns vars/helpers globais para alternar o comportamento – e tem sido ótimo.
Não introduza complexidade, a menos que o ganho seja maior do que o custo, o que em muitos casos não acontece.
PS: você pode substituir o PHP por qualquer outra linguagem que suporte includes, loops e strings multilinha, com as quais sua equipe esteja familiarizada. Utilize o PHP como um exemplo porque ele é popular, bem documentado e não precisa de bibliotecas/frameworks externos para ser produtivo (ele já é um superconjunto da maioria das linguagens de tamplate).
***
Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://blog.millermedeiros.com/static-site-generators/