- A maior parte das críticas de que "PHP é ruim (PHP Sucks)" vem de quem não viu o PHP depois de 2012
- Houve muitas mudanças desde o PHP 5.4, e vale a pena olhar para a evolução da linguagem desde então
Principais mudanças desde o PHP 5.4
- Traits (PHP 5.4)
- Permitem usar composição em vez de herança
- É possível ter traits que podem ser incluídos em qualquer classe
- Sintaxe curta de array
- É possível usar colchetes sem precisar escrever
array()
- Desestruturação de arrays
- Dá para atribuir valores diretamente a variáveis sem precisar passar por uma variável temporária
- Funções variádicas de primeira classe
- A sintaxe
... permite passar quantos argumentos quiser para uma função
- Generators
- Permitem executar tarefas intensivas em memória de forma mais eficiente
- Classes anônimas
- Permitem criar uma nova classe sem precisar criar um novo arquivo
- Também podem implementar interfaces como qualquer outra classe
Principais mudanças desde o PHP 7
- Vírgula à direita
- Não é mais preciso se preocupar em evitar uma vírgula à direita em chamadas de função ou método
- Arrow functions
- São um pouco diferentes do JavaScript, mas foram uma ótima adição à linguagem
- Operador de coalescência nula
- Não é mais necessário fazer checagem de null antes de atribuir um valor
- Operador de atribuição por coalescência nula (PHP 7.4)
- Também existe uma forma abreviada de atribuição para o operador de coalescência nula
- Weak maps (PHP 7.4)
- São muito melhores em termos de memória do que arrays
- Objetos podem ser usados como chave
Mudanças desde o PHP 8
- Operador null-safe
- Não é mais necessário checar null antes de chamar um método
- Argumentos nomeados
- Não é mais preciso usar null para pular argumentos opcionais
- Atributos (annotations)
- Podem ser usados para adicionar annotations a classes, métodos, argumentos ou propriedades
- Tratamento de erros aprimorado
- Não é mais preciso depender de uma variável de exceção para retornar false
- Expressão
match
- Uma forma mais curta e legível no lugar de
switch longos
- Enums (PHP 8.1)
- É possível criar classes enum com valores e métodos
- Também podem ser usados como type hint
- Segurança de tipos
- Inclui argumentos tipados, tipos de retorno, union types, intersection types e mais
- Type hints para enums também podem ser usados
- Promoção de propriedades no construtor (PHP 8.0)
- Chega de construtores verbosos
- Ajuda a reduzir boilerplate
- Propriedades somente leitura (PHP 8.1)
- É possível declarar uma palavra-chave para marcar propriedades como somente leitura
Desempenho
- Salto de 400% de desempenho ao passar do PHP 5.6 para o 7
- Ganho de 20% de desempenho ao passar do PHP 7 para o 8
- Entrega desempenho suficiente para a maioria dos usos em desenvolvimento web; para casos mais especializados, recomenda-se usar uma linguagem específica para isso
Conclusão
- O PHP não morreu e não é mais o pior. A linguagem mudou bastante desde 2012, e já passou da hora de atualizar essa opinião.
- Com a introdução de recursos como traits, sintaxe curta de array e desestruturação de arrays, o PHP se tornou uma linguagem mais eficiente, legível e fácil de manter.
- Somando a isso melhorias no tratamento de erros, a introdução de atributos e a tão aguardada chegada dos enums, fica claro que o PHP evoluiu para uma opção sólida e confiável para desenvolvimento web.
- Portanto, se alguém disser que PHP é o pior, dá para afirmar com confiança que essa pessoa só está presa ao passado.
Opinião do GN⁺
- Pelas mudanças na linguagem, dá para ver que PHP já não é mais o PHP do passado. Ainda assim, muitos desenvolvedores parecem continuar presos à percepção antiga.
- Foram adicionados muitos recursos que tornam o código mais conciso e legível, como traits, sintaxe curta de array e atribuição por desestruturação. Isso também deve contribuir para melhorar a manutenibilidade.
- Recursos como generators e weak maps, que ajudam na eficiência de memória, também chamam atenção. Devem ser úteis no processamento de grandes volumes de dados.
- Houve também mudanças que aumentam a maturidade da linguagem, como enums e melhorias na segurança de tipos. A expectativa é que escrever código limpo fique mais fácil.
- Acima de tudo, o ganho de desempenho no PHP 8 é impressionante. Segundo benchmarks reais, ele chega a mostrar desempenho comparável a NodeJS e Go.
- Ainda assim, modernizar projetos legados em PHP não é uma tarefa simples. A migração de código pode exigir muitos recursos.
- PHP continua sendo a base de muitos ecossistemas open source, como o WordPress. Por isso, é difícil desmerecer o valor do PHP olhando apenas para as características da linguagem.
40 comentários
São comentários que deixam bem claro por que o PHP ainda continua sendo uma porcaria.
Parabéns por ter virado uma merda sem cheiro.
Se tiverem a chance, espero que experimentem comer outra coisa em vez de merda : )
Há muitos comentários surgindo. Eu não sou desenvolvedor de PHP. Parece que, vendo esse ódio ao PHP alimentado pela comunidade, os profissionais juniores acabam desenvolvendo esse sentimento e o ciclo vicioso se repete. Um mestre jamais culpa suas ferramentas. Desenvolvedores de PHP, força sempre.
Como desenvolvedor PHP... a arrogância de quem usa outras linguagens realmente dá vontade de xingar.
Não consigo entender por que fazem tanta questão de detonar a linguagem que os outros usam.
Eu também já desenvolvi em PHP, depois migrei para Java, também mexi com Python e Node.js...
Cada linguagem tem sua própria filosofia difícil de engolir ou suas inconveniências, então não entendo por que ficam tão obcecados em falar mal só de PHP...
Porra, por que fazem isso...
Essas situações que chamam de bugs do PHP, na prática, quando você realmente desenvolve,
são sintaxes ou estruturas que quase não se usam mesmo que você nem conheça,
e esse tipo de legado todas as outras linguagens também têm até certo ponto.
Já estou de saco cheio.
Peço desculpas por ter falado sobre a tecnologia com a qual você trabalha. Independentemente da minha intenção, no fim acabei magoando o koxel, e isso é responsabilidade minha.
Dito isso, eu apenas escrevi o que senti ao trabalhar como júnior entre desenvolvedores PHP que achavam que programação na raça era tudo. Alguns desenvolvedores PHP nem sequer admitem que as melhores práticas mudam, e rejeitam isso. Foi isso que me frustrou. Atualmente, pelas circunstâncias, trabalho principalmente na área de front-end, mas também acho que há muitos pontos a criticar na forma como se desenvolve em JavaScript. Não acho que qualquer linguagem tenha uma superioridade absoluta; penso que critérios diferentes devem ser aplicados dependendo da situação.
Pelo que entendi, o problema é a estrutura permitir que desenvolvedores iniciantes escrevam programas ruins.
Mas isso não vale para todas as outras linguagens também?
É justamente por isso que existem as chamadas melhores práticas em cada linguagem..
No ecossistema do WordPress, a taxa de uso do PHP 5.6 ou inferior é de menos de 5%.
https://wordpress.org/about/stats/
Mesmo assim, em 2023 o WordPress elevou o requisito mínimo de instalação do PHP para 7.0.
Pessoalmente, o quanto eu não gosto de PHP é quase o mesmo tanto que eu não gosto de Javascript.
Comparados a esses dois, Python até parece bem mais aceitável.
Comecei minha carreira com PHP e acho que também atingi o auge da minha carreira por meio do PHP.
Hoje ganho a vida com outras linguagens, mas
Ainda tiro o PHP da gaveta de vez em quando para projetos paralelos ou hobbies.
Do mesmo jeito, acho que ele ainda é um cara cheio de charme.
Claro que hoje em dia surgiram várias alternativas, então dá até uma certa pena, mas
Laravel Vaporé bacana.No momento não estou trabalhando com desenvolvimento web... mas isso me trouxe lembranças antigas.
Muita gente não gosta de PHP. Eu também usei PHP por uns 3 anos e durante todo esse tempo achei que, como linguagem, ele realmente deixava muito a desejar; e, ao conhecer RoR, acho que dá até para dizer que foi o PHP que me levou a me apaixonar pela elegância da linguagem Ruby.
Mas, quando o PHP surgiu, foi algo impressionante! Naquela época, era o tempo em que se programavam fóruns em CGI. A agilidade que o PHP oferecia então foi sensacional. Parece fato que o PHP abriu um grande horizonte para o desenvolvimento web. :)
Mas vinho novo em odres novos...
Como linguagem, o PHP ainda é péssimo,
mas, como plataforma (é difícil encontrar a expressão certa), acho que o PHP é melhor do que parece.
Especialmente em projetos de MVP até o início da fase de crescimento, se você já define de antemão que depois vai migrar para outra linguagem/plataforma/framework (geralmente Spring),
a partir daí os defeitos da linguagem deixam de ser importantes, e só as vantagens do PHP passam a chamar atenção.
Como dá para fazer deploy sem interrupção só alterando arquivos, é possível refletir o feedback dos usuários mais rapidamente,
e o processamento econômico de fila de requisições, algo em que o PHP(-FPM) se destaca em relação a outras opções, ajuda a aguentar bem picos inesperados de tráfego (crescimento de curto prazo).
Além disso, mesmo com bugs, o aplicativo inteiro não cai, e como também fica relativamente livre de vazamentos de memória, dá para focar na lógica de negócio + a mais;
até desenvolvedores cuja linguagem principal é outra e que nunca usaram PHP conseguem se virar razoavelmente bem depois de uma semana olhando o código...
Tudo isso vai acabar virando desvantagem quando a escala crescer (talvez até uma desvantagem séria)...
Mas, pelo menos na escala de um MVP, quando a situação exige receber feedback dos usuários, aplicar mudanças correndo e crescer rápido, existe opção mais adequada que PHP?
Além disso, ao decidir adotar PHP, você já está partindo da ideia de que "quando crescer, vamos migrar para outra linguagem", então, sinceramente... Why not?
Tenho uma opinião um pouco diferente: para criar sozinho um MVP, acho que é preciso uma ferramenta que permita implementar, com o mínimo de código, pelo menos três coisas: esquema de banco de dados, WAS e UI. E acredito que, como alternativas ao PHP, existem duas excelentes opções: Ruby on Rails e Django.
No caso do Django, se você definir apenas as classes de modelo com o padrão Active Record (um termo bem antigo, por sinal), já consegue o esquema do banco de dados e uma UI CRUD de backoffice razoavelmente utilizável. Ele também oferece ferramentas mínimas para desenvolver um serviço web, como autenticação, controle de acesso, validação de formulários, ferramentas de migração de banco de dados e testes. Pessoalmente, desde que comecei a programar para web no fim dos anos 2000, nunca experimentei uma produtividade igual à do Django. Depois que a abordagem SPA virou moda e as funções de frontend e backend se separaram, às vezes até sinto que a produtividade diminuiu. Isso porque, no mínimo, duas pessoas precisam entender o fluxo do usuário e trabalhar com o protocolo já alinhado para que seja possível executar o trabalho em paralelo.
Se o PHP queria se apresentar como uma linguagem de templates para aplicações web, acho que deveria ter oferecido, no nível da linguagem, meios de se defender contra vulnerabilidades web. O fato de o estilo moderno de PHP ter adotado uma forma de desenvolvimento baseada em frameworks talvez possa ser visto como prova disso.
E o PHP já faz muito tempo que se apresenta como uma linguagem de script de propósito geral.
Não entendo por que você está comparando uma linguagem com um framework.
Existe o Laravel, que segue os conceitos de Ruby on Rails e Django.
Quando o PHP moderno deixar de ser apenas “moderno” e se estabelecer como a forma padrão de desenvolvimento em PHP, e quando os CMSs, incluindo o WordPress, adotarem o PHP moderno, acho que as pessoas passarão a reconhecer o PHP como uma linguagem de uso geral segura. Reconstruir a confiança geralmente exige mais esforço do que quebrá-la.
Isso acontece porque, em nome da manutenção da retrocompatibilidade, permite-se que iniciantes criem serviços web inseguros usando apenas as funcionalidades básicas do PHP. Entre os 5 primeiros sites que aparecem ao pesquisar por tutoriais de PHP, além do site oficial do PHP, não há nenhum caso que inclua a informação de que é preciso aplicar escape de HTML ao exibir o conteúdo de superglobais para se defender de XSS. Como o guia que eles fornecem oficialmente contém conteúdo de desenvolvimento web, não seria o caso de o PHP estar exercendo dois papéis, o de linguagem e o de framework?
O que vocês acham do fato de vários elementos do HTTP serem fornecidos por padrão sob a forma de nomes de superglobais? Eu acho que o escopo de generalidade e os casos de uso são definidos pelo que a linguagem expressa.
Por exemplo, variáveis superglobais como
$_GETe$_POSTexpõem valores quando o PHP é usado nos modos CGI e SAPI. Quando o PHP é usado via CLI, esses valores não ficam expostos.Essas variáveis superglobais são um tipo de API exposta pelos runtimes que executam PHP, como PHP-CGI e PHP-FPM, e não fazem parte da especificação da linguagem PHP em si.
O mesmo vale para o já mencionado "PHP que se apresenta como linguagem de template": falando com rigor, isso não é o PHP em si, mas sim o CGI, que é um dos runtimes do PHP, querendo ser usado dessa forma.
Da mesma forma, as inúmeras funções internas do PHP que eram apontadas como vulnerabilidades também são funções expostas por extensões do PHP, e não recursos da "linguagem" PHP em si.
Seguindo a sua lógica,
o JavaScript seria uma linguagem e também um framework, já que usa APIs expostas pelo navegador para se comunicar com o navegador e, desde o início, foi projetado para isso;
o Java seria uma linguagem, mas na prática um framework usado para aproveitar as inúmeras APIs do JDK;
e todas as outras linguagens também teriam de ser vistas como frameworks sempre que, independentemente da especificação da linguagem em si, fornecessem bibliotecas padrão e APIs.
Claro, é verdade que a relação entre essas partes é inseparável, mas usar isso para afirmar que PHP é um framework torna o argumento bem pouco convincente.
E mesmo até maio de 2024, vendo que o projeto WordPress Core ainda está corrigindo XSS, parece que melhorias apenas no nível da sintaxe do PHP não conseguem impedir XSS por completo.
Frameworks de frontend, engines de template server-side e afins aplicam escape de HTML de forma uniforme a todo conteúdo que pode ser renderizado a partir de dados, e só geram saída de modo inseguro quando o escape é desativado explicitamente. No PHP, não existe um método consensual para aplicar esse tratamento de forma uniforme. Se
echoouprintoferecessem suporte a escape por padrão, provavelmente haveria uma enxurrada de código que deixaria de funcionar de imediato, mas, no longo prazo, isso teria ajudado muita gente a reduzir erros de omissão de escape.Sim, eu não concordo com a visão de separar a linguagem do ambiente de execução e acho que, de uma forma ou de outra, o ambiente de execução influencia a linguagem. No caso do JavaScript, existem dois ambientes de execução, o Node.js e o navegador, e o Python tem muitas implementações, mas basta entender que o CPython é a dominante.
O tema do texto original está limitado a melhorias sintáticas, mas eu queria falar de algo um pouco mais amplo do que esse enquadramento.
> Além disso, acho que o Laravel é algo que deveria ter surgido como recurso oficial da linguagem, por volta de 2007, por empresas como a do Rasmus ou a Zend, e não como um projeto separado em 2011 por contribuidores open source. Assim como a adoção do Python 3 teve atritos porque abriu mão de parte da compatibilidade com versões anteriores, também acho que o PHP deveria ter feito uma grande limpeza de compatibilidade retroativa ali pela época da versão 5. Às vezes parece que as mudanças no PHP sempre chegam com certo atraso em relação ao fluxo da época.
Isso também serve como resposta ao comentário acima.
Olhando por essa perspectiva, dá para pensar no PHP como uma espécie de framework web.
Mesmo assim, não acho que o PHP precise fornecer por padrão vários dos recursos citados no exemplo, como filtro de XSS, escape etc.
O PHP-FPM, que é o mais comum, não ocupa a mesma posição que Django ou RoR. Ele está mais próximo de Flask, Sinatra e Express.
O PHP-FPM não faz mais do que roteamento (baseado em diretórios), interpretação da requisição (
$_GET,$_POST,$_FILE,$_COOKIE), envio da resposta (echo,print) e gerenciamento de sessão ($_SESSION).E o Flask, é diferente?
No Flask, para retornar uma resposta com HTML escapado, não dá para resolver simplesmente com
return.https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
E o Sinatra, é diferente?
Da mesma forma, é preciso usar uma biblioteca de escape separada.
https://sinatrarb.com/faq.html#escape_html
E o Express, é diferente?
Também é a mesma coisa: é preciso usar uma biblioteca de escape separada.
https://expressjs.com/en/resources/middleware.html
Todas as bibliotecas citadas como exemplo não são bibliotecas oficialmente fornecidas por esses frameworks.
Então por que o PHP precisaria necessariamente oferecer esse tipo de recurso oficialmente no próprio PHP?
Se a ideia é dizer que PHP é lixo por motivos que muita gente já menciona, tipo
"que tipo de framework maluco expõe os dados da requisição em variáveis superglobais? Mesmo que isso não seja um problema de segurança, isso já é uma falta de respeito com o usuário!",
aí tudo bem, eu até entendo esse argumento.
Mas o motivo que você citou, de que "os recursos básicos do PHP não são suficientes no nível do que um framework full-stack oferece"... pelo menos eu acho bem difícil concordar.
Assim como surgiu o Nestjs para usar o Express de forma mais moderna e estruturada, dá para pensar que o Laravel surgiu para usar o PHP de forma mais moderna e estruturada...
Nesse caso, em vez de focar nas desvantagens quando ele é comparado com outros frameworks (ou linguagens), não faz mais sentido enxergar melhor as vantagens próprias do PHP(-FPM), como eu argumentei no meu comentário original?
Pensando nas minhas lembranças, acho que pelo menos se a combinação slim + twig já tivesse se popularizado, teria sido possível reduzir os erros em PHP que cometi nos projetos. Claro, naquela época não dava para adotar isso porque outros desenvolvedores PHP estavam acostumados a codar PHP de forma crua. Felizmente, como o PDO fazia parte da biblioteca padrão, deu para se proteger contra SQL injection
Sobre a limitação do impacto de bugs e o desempenho de processamento mencionados no comentário original, não tenho uma opinião nem negativa nem positiva. Acho que são recursos bons de se ter, mas problemas como explosão de throughput ou uso de memória são coisas com as quais é preciso se preocupar pelo menos uma vez durante a fase de crescimento, então acho bom que esses problemas apareçam de forma explícita o mais cedo possível.
> Claro, na época isso não podia ser adotado porque outros desenvolvedores PHP estavam acostumados a codar PHP de forma porca.
> Porque o que mais leva tempo e é mais difícil é mudar as pessoas que sabem desenvolver em PHP.
Pessoalmente, acho que o próprio PHP não é o problema, ou que há meios suficientes de lidar com isso, ou então que existem apenas diferenças que surgiram por razões compreensíveis, como em outras linguagens; mas esse problema de mão de obra que você mencionou... acho que esse é, na prática, o maior problema.
Os desenvolvedores capazes de usar PHP de forma séria já se cansaram do PHP de antigamente há muito tempo e saíram do ecossistema PHP faz tempo,
E a maior parte dos usuários que ficou são pessoas que, por mais que o PHP evolua, não olham para ele com a devida atenção, ou nem têm condições de avaliá-lo direito...
Em projetos de MVP+a para os quais eu acho que o PHP é adequado, não há motivo para aqueles profissionais mais experientes participarem,
E, mesmo que participem, ou não escolherão PHP, ou, mesmo que escolham PHP, no momento em que uma ou duas pessoas do segundo grupo entrarem, aquilo vai virar uma bagunça... kk
Pelo menos aqui no país, conseguir profissionais capazes de desenvolver em PHP de forma satisfatória não é fácil.
Aí o PHP acaba sendo excluído das opções de novo, o nível médio da mão de obra cai ainda mais, e isso se repete infinitamente, criando um ciclo vicioso.
~~Nem que seja assim, continuando a fazer propaganda, pelo menos em projetos pequenos de 1 a 3 pessoas~~ Acho que só vamos quebrar esse ciclo vicioso quando aumentarem os casos de tentativas de fazer projetos PHP de verdade.
Até eu, no fim das contas, também não tenho um retorno tão grande gerado por PHP. Como é difícil demais conseguir gente de forma satisfatória, a realidade é que não dá para levar PHP como stack principal mesmo querendo...
Isso acontece por causa da diferença na forma de gerar páginas HTML entre linguagens de propósito geral e o PHP. O Flask, pelo menos desde o lançamento da versão 1.0, passou a incentivar o uso de engines de template e foi projetado para depender delas. Ele separa deliberadamente as páginas HTML dos dados do lado do servidor e vem oferecendo suporte a trabalho em nível de template. Acho que isso leva em conta as características do problema que se quer resolver e os hábitos de uso das pessoas.
Já no PHP, a saída padrão já se torna parte da página, e a fronteira entre os dados do lado do servidor e a página HTML é nebulosa. Aquilo que se faz com
printentra diretamente na página resultante, e o escape precisa ser feito explicitamente pelo desenvolvedor. Um design em que é preciso aplicar a funçãohtmlcharacterescapesa todos os dados externos não foi bem aceito pelas pessoas. As pessoas queriam templates de forma inconsciente, mas no PHP parece não ter sido considerado o objetivo do usuário de gerar páginas HTML.O motivo de essa funcionalidade precisar entrar na biblioteca padrão ou até na própria linguagem é que, considerando a configuração de ambiente e a forma de deploy de código no PHP, esse é o método mais eficaz. Como o ambiente de desenvolvimento está padronizado no stack LAMP e o ambiente de produção no modelo de hospedagem web, e como as pessoas se acostumaram a simplesmente enviar arquivos por FTP, a possibilidade de fornecer pacotes adicionais é menor do que em linguagens de propósito geral. Também não dá para exigir de iniciantes a instalação de módulos. A única opção que sobra é a biblioteca padrão e a documentação padrão.
> As pessoas queriam um template inconscientemente, mas no PHP parece que o objetivo do usuário — gerar páginas HTML — não foi levado em consideração.
Não me parece um ponto com o qual eu concorde tanto assim.
Dá para dizer que, na época do PHP3, quando ele era basicamente um meio de expor facilmente APIs em C via CGI, ele era usado com essa finalidade de template, como você mencionou, mas...
Desde o PHP 4.2, o ambiente já estava em um nível em que usos de propósito geral eram plenamente viáveis.
Passou a ser um ambiente em que se podia esperar que o código fosse executado via CLI e, como você mencionou no comentário anterior, a ideia de que “o Laravel deveria ter surgido por volta de 2007 não como projeto separado, mas como recurso oficial da linguagem” não combina em nada com a direção que o PHP tinha naquela época.
A existência do Smarty, um engine de templates para PHP lançado em 2004, e do CodeIgniter, um framework MVC para PHP lançado em 2006, contradiz a ideia de que o PHP em si seria uma linguagem de template; além disso, também dá para considerar que já havia se formado um consenso social dentro da comunidade PHP de que ele não seria usado dessa forma.
> Frameworks de frontend, engines de template server-side etc. aplicam escape de HTML de forma uniforme a todo conteúdo que pode ser renderizado a partir de dados, e só geram saída de forma insegura quando o escape é desativado explicitamente.
Também acho que esse ponto do comentário anterior não é exatamente correto quando comparado à linha do tempo do PHP.
Desde o lançamento inicial do django em 2005, e por alguns anos depois disso, o escape de HTML não era a configuração padrão. O desenvolvedor precisava aplicar intencionalmente um filtro de escape. Mesmo no caso do jinja, que ainda é usado em Python até hoje, o escape de HTML ainda não é tratado automaticamente.
Quando o escape automático passou a ser tratado como algo comum, o PHP já tinha deixado para trás havia muito tempo essa identidade de linguagem de template. (Na época, talvez os usuários que usavam PHP de forma irrefletida não quisessem isso, mas, por outro lado, também dá para dizer que o PHP já havia decidido excluir esse tipo de usuário aos poucos.)
Como o PHP já não é mais uma linguagem para esse tipo de finalidade, não há razão alguma para aplicar esse tipo de recurso como valor padrão na biblioteca padrão e na linguagem; do ponto de vista do PHP, que quer funcionar como linguagem de propósito geral, a função
htmlcharacterescapesjá cumpria suficientemente bem esse papel.> Como o ambiente operacional é padronizado no modelo de web hosting e as pessoas estão acostumadas a simplesmente subir arquivos por FTP, a possibilidade de fornecer pacotes adicionais é menor do que em linguagens de propósito geral.
Também acho difícil concordar muito com esse ponto. Desde bem mais de dez anos atrás, já se fazia ótimo uso de git e afins. Inclusive, logo depois do lançamento do Docker, já houve bastante tentativa de fazer deploy usando Docker, e isso continua sendo feito até hoje.
A maior parte do que você mencionou me parece fazer sentido não tanto para o PHP em si, mas quando se está brincando em cima de um CMS desenvolvido em PHP.
Não gosto muito desse tipo de expressão, mas seriam aqueles casos em que nem os próprios desenvolvedores PHP tratam como desenvolvedor...
O recurso de escape automático do jinja mostra que minha afirmação estava errada e que o que você mencionou está correto.
> Também é difícil concordar muito com o conteúdo acima. Desde bem mais de dez anos atrás, já fazíamos um ótimo uso de git e afins. Inclusive, logo depois que o Docker foi lançado, já houve muitas tentativas de implantação usando Docker, e ainda hoje ele é usado dessa forma.
Minha experiência com PHP parou em 2014, e naquela época não havia Docker. Também não foi possível adotar git, porque isso exigiria mudar a forma de trabalhar. Na prática, para introduzir esse tipo de coisa no ambiente de trabalho, é preciso haver consenso, e na minha situação isso era impossível.
> Não gosto desse tipo de expressão, mas há casos em que nem tratam os desenvolvedores PHP como desenvolvedores...
Olhando para trás, acho que eu estava trabalhando entre pessoas que nem eram tratadas como desenvolvedores.
Os exemplos que você deu de autenticação, controle de acesso, validação de formulários, ferramentas de migração de banco de dados e ferramentas de teste do Django também são todos oferecidos pelo Laravel no PHP.
Autenticação: https://laravel.com/docs/11.x/authentication
Controle de acesso: https://laravel.com/docs/11.x/authorization
Validação de formulários: https://laravel.com/docs/11.x/validation
Migração de banco de dados: https://laravel.com/docs/11.x/migrations
Testes: https://laravel.com/docs/11.x/testing
Além disso, embora sejam bibliotecas externas ou pagas,
existem ferramentas que exportam o schema existente do banco de dados para modelos e código de migração, ou fazem o caminho inverso,
assim como existe o https://nova.laravel.com/, que oferece um backoffice elegante com UI de CRUD incluída.
Quase todas as funcionalidades que o Django tem também existem no Laravel.
(Afinal, como ambos herdaram o conceito do RoR, acho natural que os recursos oferecidos sejam parecidos.)
Mesmo assim, diferentemente de Django-Python, Laravel-PHP ainda tem adicionalmente as vantagens que mencionei no meu comentário original.
É um fato inegável que o PHP foi projetado como uma linguagem voltada a templates para aplicações web,
mas, neste momento em que o estilo moderno de PHP já está consolidado há quase dez anos, acho pesado demais enxergá-lo apenas como uma linguagem de templates.
Vi que você linkou o Nova, mas isso também tem licença paga. Mesmo que as funções sejam parecidas com o Django Admin, que já vem explicitado nos tutoriais do projeto e pode ser usado de imediato, parece haver uma diferença em termos de acessibilidade.
Além disso, acho que o Laravel é algo que deveria ter surgido não por contribuidores open source, mas como funcionalidade oficial da linguagem por volta de 2007, por empresas como a do Rasmus ou a Zend, e não em 2011 como um projeto separado. O Python 3 teve dificuldades de adoção porque abriu mão de parte da retrocompatibilidade, mas acho que o PHP também deveria ter feito uma grande limpeza de retrocompatibilidade ali pela versão 5. Às vezes parece que as mudanças do PHP vêm sempre com um certo atraso em relação ao rumo dos tempos.
Hoje em dia, pessoalmente, como já não estou mais numa posição de quem está entrando em desenvolvimento web, não teria motivo para escolher PHP.
Você está confundindo linguagem e framework o tempo todo.
Acho que não é necessário postar o mesmo comentário em vários lugares. Você quer chamar atenção?
Claro que melhorou em relação ao passado, mas a esta altura, em vez de usar PHP, parece que faz mais sentido usar Node.js ou Python, já que parecem ter mais utilidade para diversos tipos de uso.
A onda do PHP vai chegar.
Não há menção de quanto o ecossistema do PHP, a forma de deploy, o modelo de execução e a maneira de depuração melhoraram ao longo de 10 anos. Como o que leva mais tempo e é mais difícil é mudar as pessoas que sabem desenvolver em PHP, também não tenho muita expectativa de que vá melhorar. Em especial, como o post linkado é um blog de marketing de um freelancer de PHP, parece que deve ser encarado de forma especialmente seletiva.
Nos últimos 10 anos, pelas estatísticas de uso de PHP com base nos pacotes do Composer (uma distribuição semelhante ao npm do Node), o uso de PHP 5 ou inferior praticamente desapareceu, e já faz muito tempo que o ecossistema PHP migrou para um modelo centrado no Composer.
Alguns CMS, como WordPress e GnuBoard, estão completamente à parte disso.
Excetuando os CMS, o ecossistema está na situação descrita acima.
Do ponto de vista de quem usa PHP, ele ainda é a pior linguagem.
É que as outras linguagens melhoraram mais.
Comentários do Hacker News
Resumo:
fopen()PHP: um fractal de design ruim (em coreano)
Documento de 12 anos atrás kkk
Ainda usando um texto escrito em 2012....
Você acha mesmo que o php teria continuado exatamente como era naquela época de 2012, sem nenhuma evolução..?
Ah, claro, não dá para negar que é uma linguagem que começou meio sem fundamento mesmo. rs
Aqui está o link para a tradução do documento em inglês mencionado..
Por pior que o PHP fosse, seria impossível que ainda mantivessem até hoje os problemas daquela época.
Mesmo que você mantenha, já é um problema. A arquitetura já está errada nesse nível, e aí dizem que a qualidade melhorou com upgrade de versão? Isso é problema porque quebra gravemente a compatibilidade com versões anteriores. Até os operadores de comparação são estranhos, então o que dá para fazer?
Parece que foi simplesmente fornecida a tradução para o coreano do 4º link do resumo do Hacker News, haha.