Texto
original em inglês, de Juozas “Joe”
Kaziuk?nas, disponível em http://blog.webspecies.co.uk/2011-05-23/the-new-era-of-php-frameworks.html

?

Eu já trabalhei em muitos sistemas e
projetos diferentes, e a maioria deles foi em PHP. No entanto, somente
recentemente eu notei um grande momento – uma nova era de frameworks PHP.
Parece que tudo está mudando nos dias de hoje. Eu gostaria de discutir o que
penso sobre o estado atual, o que há de errado com ele e como a nova gangue de
frameworks irá mudá-lo.

No dia 21 de maio, eu palestrei na
conferência alemã de PHP (DPC) sobre esse tópico e eu tinha várias discussões
interessantes sobre ele. Para começo de conversa, aqui estão os slides da palestra,e, claro, mantenha em mente
que eles não funcionam muito bem sem eu falando. Este artigo é uma breve versão
do que eu pontuei.

Nascem os frameworks

Seis anos atrás, o CakePHP, um dos primeiros
 frameworks PHP, foi lançado e a partir de então vimos uma pletora de
 frameworks PHP. Atualmente temos… milhões deles, todos com seus MVC,
DBAL e implementações de templates diferentes. Eu gosto deles, mesmo sendo
um pouco estranhos, mas sua adoção ainda não é massiva.

Se você olhar para vários projetos open-souce de PHP baseados em frameworks,
verá que existem poucos deles. O que é triste. A razão parcial para isso é
que muitos desses projetos foram lançados antes de qualquer framework PHP
sequer existir, mas também devido ao fato de que fazer qualquer trabalho com um
 framework PHP dependia de um bom aprendizado. Assim, se um projeto fosse
baseado em um framework, ele iria aumentar a curva de aprendizado, pelo menos
na maioria dos casos.

No entanto, eles mudaram a maneira com que fazemos
PHP. Muitos dos desenvolvedores afirmavam que sabiam OOP, mas, quando vieram
os frameworks, eles foram forçados a provar que realmente sabiam (antes
que você pudesse hackear da maneira que você quisesse). E os frameworks
ensinaram a milhões de desenvolvedores o que realmente é o OOP e como ele
funciona. Peça a alguém para usar o mysql_query hoje em dia e você pode levar
um soco na cara. Duas vezes. Porque eles também precisariam usar
mysql_real_escape_string.

Como era feito?

Ninguém sabia de fato como os frameworks PHP
deveriam ser. Nem que recursos eles deveriam ter. Então como as pessoas
conseguiram fazê-los  acontecer? Bem, ou elas seguiram os frameworks
existentes em outras linguagens (como Ror), ou tiveram suas próprias ideias.
Como elas não tinham experiência, a maioria dos frameworks até hoje tem designs
que todo mundo sabe que são ruins, mas impossíveis de serem
“consertados”.

A abordagem programática dos desenvolvedores PHP
aqui ajudou muito – da mesma maneira que a linguagem PHP evoluiu, os frameworks PHP também mudaram e cresceram a partir de feedbacks e
de pedidos. Em dois anos, a maioria das pessoas estava feliz com o que tínhamos.
Mas se você olhasse mais de perto, em 2007 tínhamos o Zend Framework 1.0, que
tinha, comparado com o 1.11, um conjunto de recursos muito limitado. Então,
mesmo hoje, os frameworks estão evoluindo rapidamente para encontrar as
necessidades dos recursos.

O PHP 4 foi (e surpreendentemente ainda é, segundo
alguns deles) suportado por todos os  frameworks. Isso levou a um monte de
código que hoje é ultrapassado, especialmente os paradigmas OOP. Tentar
suportar isso gerou processos complicados de implementações de novos recursos e de 
correção de bugs. Além disso, menos e menos desenvolvedores querem trabalhar em
códigos antigos.

O que está quebrado?

Antes de tudo, antigamente era bastante popular usar
as funções mágicas do PHP (__get, __call etc.). Não há nada de errado com elas,
em um primeiro instante, mas elas são realmente perigosas. Elas deixam as APIs
obscuras, o auto-completar é impossível e, mais
importante ainda, elas são lentas. O uso delas seria para hackear o PHP para
fazer coisas que ele não queria fazer. Mas fazia com que coisas ruins
acontecessem.

SCOP, Static class oriented programming (programação orientada a classes estáticas, em tradução livre), é um termo
que eu inventei para descrever a maioria dos códigos PHP. Métodos estáticos são
ruins por vários motivos sobre os quais não vou discorrer hoje, mas o mais
importante é que se uma classe representar a coleção de métodos estáticos, ela não
chega nem perto do OOP. Está apenas utilizando uma classe como um container
para funções. Existem frameworks completos apenas fazendo isso.

Zend Framework, por muito tempo, foi meu framework
PHP favorito (e ainda é, para o PHP 5.2), mas meu maior problema com ele é que
ele tenta forçadamente ser o componente de uma biblioteca. Outros frameworks
seguiram o mesmo caminho – em vez de utilizarem bibliotecas existentes, eles
escreveram a sua própria. Isso criou tantas bibliotecas dentro do PHP que são
do tipo autônomas, mas ainda precisam que você faça o download do
 framework completo. Frameworks gordos são realmente irritantes.

A nova era em 2011

Para melhorar essa situação, as pessoas escolheram
fazer algumas coisas. Mas, principalmente, resolveram reescrever os frameworks
do zero no topo do PHP 5.3. Isso permite que novos padrões sejam estabelecidos,
interfaces que se comunicam entre todos os frameworks e que os problemas de herança
(a maioria deles) sejam jogados fora. Parece fácil, mas somente fazendo
isso conseguiremos entrar na nova era de frameworks.

Eu não usei nenhum framework antes de o CakePHP
nascer, então vou utilizá-lo como ponto de partida. Na verdade, eu até duvido
que existiu alguma coisa antes do CakePHP, e é claro que você não chama o
Drupal de  framework. Dos anos do CakePHP até hoje, seis anos se passaram,
que marcam a primeira era. 2011 marca a segunda, e coisas completamente novas
irão finalmente acontecer, principalmente em forma de lançamentos e anúncios.

Interessantemente, em 2011, o PHP não é mais PHP. Ou
não mais apenas PHP. O conjunto LAMP é chato e cada vez menos utilizado, tendo
novas ferramentas como Nginx e CouchDB disponíveis. A integração e
interoperabilidade de hoje são elementos cruciais. O mesmo vale para linguagem
– o PHP 5.3 é um monstro completamente novo que possibilita uma funcionalidade
incrível e, se você utilizar o PHP 5.3, não existe nenhum problema de
compatibilidade real com versões anteriores.

Vamos consertá-los?

Migrar para o GIT permitiu
que muitos frameworks facilitassem a contribuição. Fico mais impressionado
com os resultados do Symfony, porque eles conseguiram atrair um imenso número
de contribuidores (veja o gráfico aqui).
O passo atual é muito mais rápido, comparado com alguns anos atrás: os
frameworks estão evoluindo muito mais rapidamente.

Muitos
cortes foram feitos. Primeiramente, toda aquela mágica que mencionei antes
agora já era, e definições explícitas estão sendo utilizadas em todo lugar.
Além disso, existe mais pensamento no sentido de se ter um núcleo pequeno e recursos
adicionais vindos através de extensões e de bibliotecas. Essa é uma ótima maneira
de trabalhar com frameworks e de reduzir a quantidade de memória necessária.

Performance
foi o maior problema para os frameworks PHP, e a maioria deles tinha
planos para novos lançamentos. O front-end recebeu muita atenção também, com
frameworks como Symfony ajudando com o gerenciamento de ativos
(JavaScript e CSS) e headers corretos para conteúdo estático. O PHP lucrou com
a redução da mágica e a limpeza do código, e o PHP 5.3 teve uma grande melhoria
em performance.

Novos recursos

É
óbvio que todos os novos recursos da linguagem estão incorporados. Como
namespaces, por exemplo. Namespaces respondem à necessidade de pesquisa e
concordam em uma abordagem de autoloading que iria funcionar para a maioria dos
frameworks. O PSR-0
nasceu mais cedo, mas agora é bem integrado dentro dos frameworks. E as funções
anônimas estão encontrando sem caminho também.

Dependency injection containers e
Annotations
são duas das que gostaria de citar aqui. Gosto de usá-las, e o Symfony faz
um ótimo uso delas, mas outros frameworks estão chegando perto e vão começar a
incorporá-las logo. A combinação delas com novos recursos do PHP permite a
criação de micro-frameworks bastante limpos, veja o Silex.

Não
estou completamente convencido de que gosto da crescente lista de recursos
diretamente portados do ambiente Java. O Java trabalha diferente (e necessita
de 1GB de RAM), então até o DiC é complicado no PHP. Veremos aonde ele nos leva,
mas até agora eu estou um pouco preocupado, pois sei que o PHP gosta de
sistemas leves ao invés de gráficos complexos de objetos. Por mais legal que
esses modelos possam parecer, eles podem criar mais do que resolver problemas.

Então quando?

Zend Framework 2.0
está a caminho, mas irá demorar um pouco. Como o SF tem um código base massivo,
a primeira coisa que eles fizeram foi converter tudo para um código namespaced.
Uma vez que isso foi feito, era hora de começar a reconstruir a funcionalidade
e a implementá-la. Atualmente, o trabalho está sendo feito na parte MVC, mas eu
espero que no final do ano um lançamento definitivo seja feito.

Lithium
está quase lá, está no modo dev, mas parece bem perto de ser terminado. É um
framework completamente diferente dos regulares, então vale a pena dar uma olhada
nele. Estou mais impressionado com sua implementação AOP e
gostaria de vê-lo adotado em mais frameworks. Obviamente eles são somente para
PHP 5.3, mas ele suportam o CouchDB e o MongoDB muito bem.

Symfony2, na minha opinião é o
líder do grupo. Eles já estão em beta2 e o lançamento final é uma questão de
meses. A lista de recursos é difícil de compreender, então vale a pena dar uma
olhada no site deles, mas para falar de uma delas – Bundless. Bundless é uma
maneira de ter uma estrutura extensível da aplicação com uma coleção de
componentes de fora. Pense em plugins.

Conclusão

Estou
super animado com as coisas que estão acontecendo na indústria PHP e acredito
que elas irão gerar grandes conquistas. Finalmente, temos uma era em que podemos
jogar fora todo o nosso legado (a maioria) e implementar novas ideias. Vá para
frente 5 anos a partir de hoje, e iremos estar tão animados como estamos hoje.

?

artigo original publicado em LINK,
sob a licença CC-BY-3.0 http://creativecommons.org/licenses/by/3.0/