O PHP é obsoleto, em 2024

Na Vonage, viajamos bastante a trabalho. Converso com muitos desenvolvedores de todas as origens e posso afirmar com segurança que uma das perguntas mais frequentes que recebo é: “Por que você ainda usa PHP?”. Variações dessa pergunta podem ser: “O PHP não é considerado ruim?”. Em várias ocasiões, a pessoa com quem eu conversava já tinha trabalhado com PHP lá por 2012. Ou 2010. Não me lembro bem. Por motivos que não consigo entender, estamos passando por outra onda disso em fóruns online, e por isso mais comentários do tipo “PHP é péssimo” estão surgindo do nada.

O que causa esse fenômeno? Por que o PHP é “ruim”?

Tribos

Considero a maioria dos desenvolvedores como pessoas que começam como nômades e acabam “encontrando seu grupo”. Afinal, é basicamente isso que são as comunidades de tecnologia. Uma das dificuldades no início da carreira (além de conseguir seu primeiro emprego) é ser aceito ou escolher qual grupo você deseja chamar de lar. Ser aceito parece difícil para alguns, e é aí que pontos em comum ou o senso de humor podem ser úteis para recém-formados ou participantes de bootcamps.

Nesse sentido, a piada conhecida é “PHP é ruim”. Mas não há mais nenhum fundamento para isso — a explicação mais próxima que alguém provavelmente daria é um post de blog enorme e desconexo escrito há anos sobre muitas, muitas coisas com as quais você nunca vai se deparar ou que são apenas um incômodo para o próprio autor. Não importa que tenham surgido posts em resposta, como este da equipe de engenharia do Slack que explicam a nuance de que qualquer aplicação pode ser mal escrita em qualquer linguagem de programação. Acho que alguns podem se apressar em apontar que o Slack originalmente construiu sua plataforma com Hack, um fork do PHP criado pelo Facebook, ou que muitos dos novos serviços que eles adicionaram desde então estão em Go ou Node. 

Então, a situação continua a mesma: está ruim.

O mito que se perpetua

O PHP é tão ruim, na verdade, que um certo sistema operacional decidiu exibir um aviso ao tentar usar a versão que vinha junto com ele, informando:

AVISO: Não se recomenda o uso do PHP

Apesar de a versão que vinha junto com o sistema já estar desatualizada, as pessoas defenderam essa formulação explicando que a intenção era alertar os usuários sobre a versão legada do PHP que vinha com o sistema operacional. 

Verificou-se que o mesmo ocorria com o Python 2.7, mas, o que é fundamental, a mensagem de erro dizia explicitamente “O Python 2.7 não é recomendado”, sem o aviso de alerta. Não é isso que esta mensagem de erro diz.

Algumas pessoas podem achar isso engraçado, mas eu não vejo graça alguma no fato de meu sistema operacional me dizer qual linguagem de programação devo usar. Isso é a perpetuação da ideia de que o PHP é ruim, e é por isso que essa insinuação, com um piscar de olhos, é aceitável.

Então, por que ainda estamos falando sobre PHP se dizem que ele é ruim?

A necessidade é a mãe da invenção

Há outra linguagem de programação que seguiu exatamente o mesmo padrão de evolução, que é o JavaScript. Como o JavaScript era a linguagem de fato executada dentro de um navegador com um mecanismo integrado, teve a evoluir a partir de origens básicas.

Da mesma forma, devido ao surgimento de Sistemas de Gerenciamento de Conteúdo com back-ends escritos em PHP, como o WordPress e o Drupal: o PHP teve que evoluir. A evolução de uma linguagem — de um prático “hack” em C criado por Rasmus Lerdorf para seu próprio uso em scripts até se tornar uma linguagem de programação geral e completa, projetada para a web — não acontece por acaso. Entra em cena a Zend, que criou o Zend Engine e, fundamentalmente, conseguiu o apoio de grandes fornecedores da época, como a Oracle e a IBM.

Essas coisas acontecem porque as pessoas usam isso, da mesma forma que a relação entre JavaScript e ECMAScript e as ferramentas do ecossistema evoluem constantemente.

Essa evolução ocorreu precisamente porque o PHP ainda é amplamente utilizado — sem esse uso generalizado, nunca teríamos visto coisas como a migração para um sistema de classes totalmente orientado a objetos na versão 5.0, traits na 5.4, a introdução de geradores na versão 5.6, um mecanismo reformulado no PHP 7 que proporcionou um aumento de desempenho de 100% em alguns casos, um compilador JIT na versão 8.0 e enums nativas na versão 8.1. O ciclo de vida do Perl, por exemplo, não passou por uma evolução tão rápida porque as pessoas pararam de usá-lo. Então, quais são os resultados reais dessa evolução que estamos vendo hoje?

Mito nº 1: O PHP não é escalável.

Tente dizer isso à Fathom Analytics, que reescreveu seu aplicativo em Laravel e lida com milhões de solicitações por segundo.

Vamos deixar isso bem claro: nenhum microsserviço ou sistema distribuído terá escalabilidade eficaz se for mal projetado. 

O caso da Fathom mostra que é possível fazer isso — no caso deles, no ecossistema do Laravel — de forma muito eficaz, com um conjunto de ferramentas fornecidas pelo próprio Laravel. Como Jack menciona na postagem do blog acima, a crítica feita por programadores que usam outras linguagens é que o PHP não consegue escalar, pois os testes de desempenho indicam isso. 

Mas, quando você estiver desenvolvendo uma aplicação em grande escala, será que vai precisar que ela processe 1 milhão de solicitações por minuto? Provavelmente não. Mas certamente seria bom e rápido no Node, já que ele é assíncrono, certo? Provavelmente. Isso importa para você? Dificilmente, nesta fase.

Mito nº 2: O PHP é lento

Uma crítica comum é que, como o PHP é monotread, é preciso gerar novos processos para criar tarefas simultâneas ou cargas de trabalho escalonadas horizontalmente. O PHP-JIT foi introduzido já no PHP 8.0, mas isso foi, na verdade, apenas o início das mudanças que tornaram a velocidade a principal prioridade na evolução do PHP. Conheci o OpenSwoole (na época, Swoole) já em 2014e vi uma solução alternativa por meio de extensão para o problema do único thread. O advento das Fibers nativas no PHP 8.1 significou, então, que era possível implementar corrotinas e PHP assíncrono. Um bom exemplo de alguns testes de desempenho pode ser encontrado aqui, mas o resumo dessa evolução em direção à velocidade significa que agora existem várias opções para que os desenvolvedores de PHP escrevam Applications na velocidade da luz.

Corrotinas de fibra

ReactPHP e amphp são dois exemplos do uso de fibras para PHP assíncrono e sem bloqueio, e nem sequer são novidades. Eles funcionam efetivamente como o loop de eventos do Node. Se você quiser conferir que tipo de velocidade é possível obter com eles, aqui está um exemplo de um dos membros da equipe principal do ReactPHP, Cees-Jan Kiewiet. Spoiler: é rápido.

Novo Runtime

Então, não estamos contando o Roadrunner e OpenSwoole , já que eles não são novidades. Mas lembra quando eu disse que a necessidade é a mãe da invenção? Pois bem, este ano testemunhamos algo bastante surpreendente: o lançamento de um novo servidor de aplicativos PHP, o FrankenPHP. 

Por que se chama FrankenPHP? Porque a necessidade de evolução do PHP levou a que o novo ambiente de execução fosse programado em Go, da mesma forma que o Roadrunner, só que este foi desenvolvido com base no servidor web Caddy. Isso faz sentido? Talvez pareça estranho, então não. É rápido? Sim. Você se importa que seja em Go? Espero que não. Aqui está um exemplo do FrankenPHP sendo usado pelo Laravel Octane. Spoiler: é rápido.

De onde surgiu o FrankenPHP?

Crédito da imagem: FrankenPHP https://frankenphp.dev/

O criador do FrankenPHP é Kévin Dunglas. O que é interessante notar é que Kévin é um membro do núcleo do Symfony Framework; portanto, pode-se argumentar que o Symfony tenha, de fato, patrocinado a criação de um novo e mais rápido ambiente de execução do PHP ao apoiar o trabalho dele. 

No entanto, há outro motivo para conferir o trabalho de Kévin: ele também é o criador da API Platform.

Espere aí, o que é a API Platform?

Crédito da imagem: API Platform https://api-platform.com/

Ah, certo, que bom que você perguntou. Bem, o PHP é tão ultrapassado que agora você pode usar uma estrutura de back-end personalizada, projetada exclusivamente para o desenvolvimento rápido de APIs web REST/GraphQL. Ela pode ser usada tanto com o Symfony ou Laravel, e contém recursos como a seleção dos padrões de resposta da sua API, gerenciamento automático de documentação com OpenAPI ou SwaggerUI, ferramentas de testes automatizados e gerenciamento de desempenho/cache. API web, da prototipagem à produção? 

Alerta de spoiler: é rápido.

Notas da comunidade: Cada vez maior

Crédito da foto: Participantes da DrupalCon Barcelona 2023

https://events.drupal.org/barcelona2024

Uma afirmação comum que os desenvolvedores me dizem todos os anos é que o uso do PHP (e, portanto, o desenvolvimento em PHP) vem diminuindo a cada ano. Isso coincide, ano após ano, com o lançamento da pesquisa com desenvolvedores do StackOverflow. Acho importante saber que o número tão repetido de 70% (ou algo próximo disso) da web sendo em PHP se deve ao WordPress. Sim, é PHP, mas é o sucesso do WordPress como produto que faz com que esse número seja assim. Com um número tão inflado, é inevitável que ele diminua com o tempo, à medida que mais e mais frameworks de CMS e até mesmo produtos de CMS SaaS na nuvem, como o Contentful ou o Strapi, aumentem seu uso.

Então, o uso do PHP está em declínio? Em termos numéricos, sim, à medida que os usuários abandonam o WordPress, mas as comunidades do PHP continuam incrivelmente fortes. O uso de três de suas principais estruturas está aumentando, o que significa que novos projetos estão sendo desenvolvidos. A DrupalCon tem uma média de cerca de 3.000 participantes por conferência, sendo que várias são realizadas por ano em todo o mundo. A SymfonyCon e Laracon também são realizadas em todo o mundo, várias vezes por ano, e registram uma média de 1.000 a 3.000 participantes. Para mim, isso não indica uma linguagem em declínio. Pelo contrário, mostra que ela está em crescimento.

Será que as pessoas estão começando a perceber?

Dizem que a imitação é a forma mais elevada de elogio. Com essa filosofia em mente, vale a pena observar que a abordagem do Laravel ao desenvolvimento full-stack (que, por sua vez, se baseia originalmente no Rails) deu origem a frameworks com recursos completos fora do âmbito do PHP. Conheça o AdonisJS, um framework Node.js baseado no Laravel. Não é o suficiente? Então, veja o o Wasp, também um framework Node.js baseado no Laravel. Que tal o Goravel, um framework em Go baseado em... bem, acho que já sabemos o que vem por aí.

A abordagem específica do Laravel em relação à Experiência do Desenvolvedor é o que lhe rendeu um público fiel de desenvolvedores. Tanto é assim que o influenciador de tecnologia ThePrimeagen ficou surpreso com o Video de Aaron Francis “PHP Doesn’t Suck Anymore” e resolveu conferir. O resultado foi um apoio inesperado. Uma palestra dele na LaraconUS deste ano coroou tudo isso até o momento em que o Laravel anunciou que havia levantado US$ 58 milhões em capital de risco. Você talvez tenha começado a ler este artigo pensando que o PHP está morrendo, mas, com esses altos e baixos, eu diria que talvez não.

A questão é que toda essa conversa sobre frameworks é legal e tudo mais, mas… quem desenvolve a linguagem PHP?

A Fundação PHP

Espero que, mesmo que você não seja um desenvolvedor de PHP, eu tenha conseguido chamar sua atenção com este artigo. Então, para contextualizar um pouco: durante anos, o PHP foi mantido por apenas duas pessoas, Nikita Popov e Dmitry Stogov, graças ao patrocínio da JetBrains e Zend , respectivamente. Sim, houve um apoio considerável de gerentes de lançamento, numerosos demais para serem mencionados, mas ainda assim é muito trabalho para dois desenvolvedores lidarem com esses recursos. Em 2022, a PHP Foundation foi criada, cujo conselho atual é composto por veteranos do PHP e representantes da Automattic, Zend, Private Packagist, JetBrains, Tideways, Perforce e Symfony.

A Fundação mantém 10 engenheiros — alguns em tempo integral, outros em meio período. É bastante raro encontrar esse tipo de governança aberta, já que as estruturas mais comuns são as do “o ditador benevolente vitalício” ou com apoio comercial. Essa jornada não pode continuar sem eles; portanto, se você quiser saber para onde essa jornada de 30 anos seguirá, confira https://thephp.foundation/sponsor/ para ajudar a linguagem em sua próxima iteração.

Conclusão

Não sei por que estamos vendo um ressurgimento do “lolphp” por aí na internet, mas, francamente, não estou exatamente preocupado. Acho, no entanto, que repetir como um papagaio que algo é ruim — o que provavelmente vem de alguém que escreveu a linguagem há 15 anos — acaba limitando um pouco as habilidades dos desenvolvedores. O PHP é moderno, está totalmente diferente do que era há 15 anos e conta com uma comunidade e um conjunto de ferramentas prósperos. Coisas como PsalmPHP e PHPStan análise estática graças à Árvore de Sintaxe Abstrata são ferramentas absolutamente de primeira linha. Se alguns dos maiores influenciadores de tecnologia por aí estão dispostos a dar uma chance, por que você não? Você pode começar a experimentar as comunicações da Vonage baixando o SDK do PHP da Vonage, do qual sou o mantenedor principal. Precisa de ajuda? Você pode participar da nossa comunidade no Slack ou nos contate no X. Precisa de orientação? Você pode agendar uma breve sessão comigo.