Expressões Nativas de Marcação: A Sintaxe JSX Chegando ao PHP

Apresentadora: Juliana Santos Convidado: Rodrigo Cardozo (Desenvolvedor Sênior e entusiasta do ecossistema PHP/Laravel) Assunto: Native Markup Expressions: A Sintaxe JSX chegando ao PHP Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e estou muito feliz de ter vocês aqui com a gente hoje. Se você desenvolve em PHP, especialmente se você é do ecossistema Laravel, respira fundo porque o papo hoje é daqueles que mexe com as estruturas — literalmente. Sabe aquela sensação de estar alternando entre o PHP e o HTML no Blade e sentir que falta uma "cola" mais natural? Pois é, a comunidade está em polvorosa com uma proposta chamada *Native Markup Expressions*, ou NME. A ideia é basicamente trazer uma sintaxe inspirada no JSX, do React, direto para o núcleo do PHP. É o HTML deixando de ser apenas uma string ou um template externo para virar um cidadão de primeira classe na linguagem. No episódio de hoje, vamos entender se isso é o futuro brilhante da produtividade ou se vai virar uma bagunça de sintaxe. Vamos mergulhar nessa revolução de UI no PHP. Apresentadora: E para me ajudar a desbravar esse novo horizonte, eu trouxe um cara que manja tudo de arquitetura PHP e que está acompanhando essa discussão desde o primeiro "commit" de ideia. Rodrigo Cardozo, seja muito bem-vindo ao Allur, Rodrigo! Convidado: Valeu, Juliana! É um prazer enorme estar aqui no Allur. Esse assunto é, tipo assim, o "papo do momento" nos grupos de discussão e nos bastidores do core do PHP e do Laravel. É uma mudança de paradigma bem grande, então tem muita coisa massa pra gente dissecar hoje. Apresentadora: Com certeza! Rodrigo, pra gente começar do começo: explica pra quem está ouvindo o que são, de fato, essas *Native Markup Expressions*. A gente está mesmo falando de escrever "HTML dentro do PHP" sem as aspas, tipo o que o pessoal faz no React? Convidado: Cara, é exatamente isso. Hoje, se você quer renderizar algo no PHP puro, ou você usa um `echo` com uma string gigante — o que é um pesadelo de manter — ou você pula pra fora da tag PHP pra escrever HTML. No Laravel, a gente tem o Blade, que é incrível, né? Mas ele ainda é um "motor de templates" que roda por cima. A proposta das NME é que o próprio interpretador do PHP entenda as tags `<` e `>` como expressões válidas. Ou seja, você poderia atribuir um componente de UI a uma variável de forma nativa. O PHP passaria a enxergar o markup não como texto, mas como uma estrutura de dados de UI. É o PHP olhando pro JSX e falando: "Gostei, vou querer!". Apresentadora: Massa! E assim, a gente sabe que o Blade é o queridinho da galera do Laravel. Eu mesma adoro a simplicidade das diretivas `@if`, `@foreach`. Mas você sente que existe hoje uma "fricção" nesse modelo atual? Onde que o sapato aperta que justifica essa mudança tão drástica? Convidado: Então, Juliana, o Blade é fantástico, mas ele cria uma separação de contexto que às vezes incomoda em componentes muito complexos. Pensa no Livewire, por exemplo. No Livewire, a lógica tá na classe PHP, mas o visual tá no arquivo `.blade.php`. Você fica o tempo todo naquele "Alt+Tab" mental de: "Como eu chamei essa variável na classe? Deixa eu ver na view". Com as Native Markup Expressions, a gente começa a falar de "Single File Components" de verdade no PHP. A lógica e o markup viveriam no mesmo lugar, com o PHP validando a sintaxe de tudo de uma vez só. Isso elimina aquela quebra de raciocínio, sabe? Você escreve a lógica e já define o retorno visual logo abaixo, tudo com a mesma cara. Apresentadora: Nossa, isso de evitar o "Alt+Tab mental" é um gancho excelente. Mas eu fico pensando, Rodrigo... o PHP sempre foi criticado antigamente por "misturar lógica com apresentação", lembra? Aquela bagunça de códigos PHP no meio do HTML dos anos 2000. Isso não corre o risco de ser um "retorno ao passado", só que com uma roupagem moderna? Convidado: (Risos) Pô, essa é a pergunta de um milhão de dólares! Muita gente da velha guarda olha e fala: "Ih, lá vem o PHP 4 de novo". Mas a diferença aqui é a *estrutura*. No passado, a gente jogava lógica de banco de dados no meio do HTML. Agora, a gente tá falando de composição de componentes. É o que o React provou que funciona. Quando você tem markup como expressão nativa, você tem segurança de tipos, você tem autocompletar do IDE muito mais potente e você tem uma árvore de componentes previsível. Não é "sujar" o código, é unificar a linguagem da UI. É bem diferente de dar um `include` num arquivo que faz query no banco, né? Apresentadora: Entendi. É uma evolução da forma como a gente organiza, não um retrocesso. E pro ecossistema Laravel especificamente? O Taylor Otwell e a galera do core já estão de olho nisso? Como você vê o impacto no Livewire, por exemplo? Convidado: Cara, o impacto seria gigante. O Livewire hoje já faz mágica, mas ele ainda depende do motor de templates. Se o PHP aceitar essa RFC, o Livewire poderia se tornar muito mais performático e coeso. Imagine definir um componente Livewire onde o método `render()` retorna um markup nativo, onde você pode usar variáveis PHP diretamente dentro das tags sem precisar de `@{{ }}` ou diretivas complexas. A produtividade ia disparar. E pro iniciante, tipo assim, a barreira de entrada diminui. Ele aprende PHP e já aprende a fazer a UI ali dentro, sem precisar decorar uma "segunda linguagem" de template no início. Apresentadora: Isso é muito interessante. Mas nem tudo são flores, né? Quais são os maiores desafios que você vê pra isso ser implementado de fato? Eu imagino que mexer no core do PHP pra aceitar essa sintaxe não deva ser nada simples. Convidado: Com certeza, Juliana. O maior desafio é o *parser*. O PHP é uma linguagem muito madura, e mudar a forma como ele interpreta os símbolos de "menor que" e "maior que" pode causar conflitos com operadores de comparação, por exemplo. Tem toda uma discussão técnica sobre como o interpretador vai saber se `<` é o início de uma tag ou um "menor que". Além disso, tem a questão da retrocompatibilidade e, claro, o convencimento da comunidade. Nem todo mundo quer que o PHP mude tanto. Tem gente que prefere o PHP como uma linguagem "limpa" de backend e deixa o markup pros templates. É uma briga filosófica, além de técnica. Apresentadora: Realmente, é uma mudança de cultura pesada. E falando em técnica, você mencionou os IDEs. Hoje a gente sofre um pouco quando o Blade fica muito complexo e o VS Code ou o PhpStorm se perdem. Com NME, isso teoricamente melhoraria, né? Convidado: Exato! Como passaria a ser sintaxe nativa da linguagem, os criadores de IDEs não precisariam criar "hacks" pra entender o Blade. O suporte seria de primeira classe. Refatoração de nomes de variáveis, encontrar referências de componentes... tudo isso ficaria muito mais sólido. É o tipo de coisa que você só valoriza quando começa a usar e vê que o erro de digitação é pego na hora pelo editor, antes mesmo de você dar o refresh na página. Apresentadora: Nossa, isso ia salvar tanto tempo de debug... "Será que eu escrevi o nome da variável certo no Blade?". Quem nunca, né? (Risos). Rodrigo, pra gente ir fechando: se você tivesse que apostar, você acha que as Native Markup Expressions viram padrão no PHP em breve ou ainda é um sonho distante? Convidado: Olha, Juliana, o PHP tem se modernizado num ritmo impressionante. Vimos as *Enums*, as *Readonly Classes*, as *Fiber*... a linguagem tá on fire! Eu acho que a proposta ainda vai amadurecer bastante este ano. Talvez não entre no PHP 8.4, mas a discussão está muito séria. Eu apostaria que a gente vai ver algo nesse sentido, talvez como uma extensão ou um subset, muito em breve. O movimento pra unificar o desenvolvimento front-backend no PHP é imparável, e o NME é a peça que falta nesse quebra-cabeça. Apresentadora: É, o pessoal do PHP não está de brincadeira. Bom, as conclusões que eu tiro desse papo são: primeiro, a produtividade pode ir pra outro nível; segundo, a gente vai ter que desaprender alguns preconceitos sobre "misturar código"; e terceiro, o ecossistema Laravel vai ser o primeiro a voar baixo com isso. Apresentadora: Rodrigo, muito obrigada por esse papo, cara! Foi muito esclarecedor. Onde o pessoal pode te encontrar pra acompanhar suas análises sobre PHP? Convidado: Eu que agradeço, Juliana! O papo foi massa. Quem quiser trocar uma ideia, me acha no Twitter (ou X, né?) como @rodrigocardozo_dev ou lá no GitHub. Valeu mesmo pelo convite! Apresentadora: Valeu, Rodrigo! E pra você que ouviu a gente até aqui, o que você acha? JSX no PHP é o futuro ou é demais pro seu coração de dev? Se quiser ler mais sobre a proposta das Native Markup Expressions, a gente vai deixar os links oficiais aqui na descrição do episódio. Apresentadora: Valeu por sintonizar o Allur! Não esquece de seguir a gente no seu player de podcast favorito e compartilhar esse episódio com aquele seu amigo que ainda acha que PHP é só o que ele viu na faculdade em 2010. Um beijo e até a próxima!