O que é PHP e por que ele ainda importa

✓ Resposta: A diferença não é de opinião, é de onde o código roda. O JavaScript da página é baixado pelo navegador para ser executado lá — o arquivo inteiro está na máquina do usuário, e basta abrir as ferramentas do desenvolvedor, ou a aba de rede, para ler qualquer valor dentro dele. Minificar não esconde nada: é só texto embaralhado. Já o PHP é executado no servidor e nunca sai de lá; o navegador recebe apenas o resultado, em geral HTML. Se a chave está numa variável PHP, o usuário não tem como alcançá-la, porque não tem como alcançar o código. O teste mental que resolve a discussão é este: o que o usuário recebe é o programa ou é a saída do programa? No navegador, ele recebe o programa. E o agravante é que uma chave exposta assim não fica só à vista de quem procura — rastreadores varrem repositórios e bundles públicos justamente atrás desse padrão, e a chave costuma ser usada antes de alguém perceber. Quando o front-end precisa mesmo falar com o serviço, a saída é o servidor intermediar a chamada, ou emitir um token de curta duração e escopo restrito, que é feito para ser público.

✓ Resposta: Espere medir quase nada — e essa é a resposta que separa quem leu a manchete de quem entendeu o mecanismo. O JIT compila trechos quentes para código de máquina, e brilha em carga limitada por CPU: laços numéricos longos, processamento de imagem, cálculo matemático. Uma aplicação web típica não é isso: ela passa a maior parte do tempo esperando — o banco responder, o disco ler, a API externa voltar. Acelerar a parte que não era o gargalo não muda o tempo total. O que de fato acelera um site em PHP é o OPcache, e ele é anterior ao JIT: sem ele, cada requisição recompila todos os arquivos .php do zero, todas as vezes; com ele, o bytecode fica em memória compartilhada e a recompilação some. Em produção, opcache.validate_timestamps=0 ainda evita que o PHP verifique a data de cada arquivo a cada requisição (ao custo de exigir recarga do FPM no deploy). Depois disso, os ganhos reais estão fora da linguagem: índice no banco, resolver o N+1 de consultas, cache de resultado, e não abrir conexão nova a cada chamada. Ligar o JIT antes de ter OPcache configurado e consulta indexada é otimizar a etapa errada.

✓ Resposta: O resultado é 179.1 — e está errado, embora nada tenha falhado. A string "199,90" usa vírgula decimal, e o PHP, ao convertê-la para número, lê os dígitos até o primeiro caractere inválido: vira 199, e os centavos desaparecem em silêncio. Esse é o custo real da tipagem dinâmica: o erro não aparece onde foi cometido, e sim várias camadas adiante, quando alguém percebe que o total do relatório não fecha. Fechar o buraco tem duas partes. A primeira é declarar os tipos na assinatura: function calcularDesconto(float $preco, float $percentual): float. A segunda, sem a qual a primeira engana, é declare(strict_types=1); no topo do arquivo — sem ele o PHP ainda coage a string para float e o defeito continua, apenas mais escondido; com ele, a chamada lança TypeError na hora. O terceiro cuidado é converter na fronteira: dado que chega de formulário é sempre string, e a conversão de "199,90" para 199.90 é trabalho de quem recebe a entrada, não da função de cálculo. E, para valor monetário, o mais seguro é nem usar float: trabalhar em centavos inteiros evita que 0.1 + 0.2 deixe de ser 0.3.

✓ Resposta: A consequência é que a maior parte das vagas de PHP é de manutenção, não de criação — e isso muda o que vale a pena estudar. Um mercado formado por milhões de instalações de WordPress, Magento e sistemas internos antigos demanda, no dia a dia, ler código que você não escreveu, entender uma base legada sem documentação, migrar versão, corrigir falha de segurança e integrar com o que já existe. É um tipo de competência diferente da de começar um projeto do zero com o framework da moda, e costuma ser mal preparada pelos cursos, que só ensinam a partir da folha em branco. Há duas leituras erradas comuns. A primeira é concluir que basta aprender WordPress: quem só sabe o plugin, e não a linguagem embaixo dele, trava no primeiro problema que não está no painel. A segunda é desprezar o legado como se fosse trabalho menor — é onde está o dinheiro, e onde se aprende mais rápido, porque sistema em produção ensina com consequência. A leitura útil é: aprender PHP de verdade dá acesso tanto ao ecossistema moderno (Laravel, APIs, filas) quanto a essa base instalada gigantesca, e quem transita nos dois lados é raro.

✓ Resposta: Para esse caso o PHP é a escolha mais fácil de defender, e o argumento decisivo é a hospedagem: o requisito "compartilhada" praticamente elimina as alternativas. Um plano compartilhado já vem com PHP, Apache ou Nginx, MySQL e envio de e-mail configurados; o deploy pode ser um git pull, e não há processo para manter vivo, nem supervisor, nem contêiner. Rodar Node, Python ou Go no mesmo plano costuma exigir VPS, o que muda o custo e adiciona administração de servidor a um projeto de um desenvolvedor só. Os demais requisitos reforçam: reserva de sala é CRUD com regra de conflito de horário, relatório mensal é consulta agregada, e-mail é tarefa resolvida — Laravel entrega autenticação, validação, agendador e envio de e-mail prontos, e o prazo curto é exatamente o cenário em que framework maduro vale mais que preferência pessoal. Eu mudaria de ideia em três situações, todas sobre o modelo de execução: se a agenda precisasse ser colaborativa em tempo real, com várias pessoas vendo a mesma tela atualizar (conexão persistente não combina com o processo-por-requisição); se houvesse processamento pesado e contínuo, como transcodificar vídeo, que ocuparia os workers do FPM; ou se a equipe que vai manter já dominasse outra stack — a linguagem que o time sabe manter costuma vencer a que é tecnicamente marginalmente melhor.