Executando verificação de segurança...
21
Jeffs
1 min de leitura ·

Ué, dá pra usar PHP no mobile e desktop?

Dá. E com Laravel, Livewire, Eloquent, SQLite, Schedule, hot reload e 4 comandos pra rodar.

Eu sei, parece mentira. Mas é isso.

Como assim?

O NativeBlade empacota seu app Laravel inteiro dentro de um PHP WebAssembly, envolve num shell Tauri e entrega como app nativo pra Windows, macOS, Linux, Android e iOS.

Sem servidor. Sem internet obrigatória. Sem React Native. Sem Flutter. Sem Swift. Sem Kotlin. Sem aprender nada novo.

composer create-project laravel/laravel meu-app
cd meu-app
composer require nativeblade/nativeblade
php artisan nativeblade:install
npm run build
php artisan nativeblade:dev

Seu app tá rodando no desktop. Sério.

O que funciona

  • Rotas, Blade, Livewire, Eloquent — tudo normal
  • SQLite persistido entre sessões
  • Http::get() pra APIs externas via bridge transparente
  • Schedule rodando via timers Rust nativos
  • Filesystem nativo — leitura e escrita de arquivos reais no dispositivo
  • MySQL e Postgres via bridge se precisar conectar num banco externo
  • Header, bottom nav, drawer, 1.512 ícones e 90+ animações prontos
  • Hot reload — salva o .blade.php, já atualizou
  • ~15MB de binário final

"Mas não é nativo de verdade"

Verdade. É WebView por dentro.

Mas cá entre nós — você já escolheu PHP e Blade. Você já fez essa troca faz tempo.

Nasceu num fim de semana

"E se PHP rodasse em WASM dentro do Tauri?"

Funcionou. Aí virou framework. 🤷

GitHub: https://github.com/NativeBlade/NativeBlade

Contribuições, dúvidas, ou só xingar nos comentários — tudo é bem-vindo. 😄

Fonte: https://github.com/NativeBlade/NativeBlade

Carregando publicação patrocinada...
2
kirafe

Tem alguma diferença técnica do Native php com a sua solução pra esse problema? começei a estudar um pouco com o laravel e queria tenta montar algo com o desktop

2
Jeffs
  • Autor
    Autor

Boa pergunta! As duas resolvem o mesmo problema mas de formas diferentes.

O NativePHP empacota um binário PHP compilado nativamente pra cada plataforma, e usa Electron como shell o que resulta em apps mais pesados (~150MB) mas com acesso total ao PHP nativo, incluindo extensões.

O NativeBlade roda o PHP dentro de WebAssembly, empacotado num shell Tauri em Rust o binário fica bem menor (~15MB), funciona em Windows, macOS, Linux, Android e iOS com o mesmo código, e não precisa compilar binário por plataforma. A troca é que algumas features do PHP não estão disponíveis no WASM.

Pra quem está começando com Laravel e quer fazer algo desktop, o NativeBlade é bem direto 4 comandos e já tem um app rodando. Qualquer dúvida pode abrir uma issue no repositório! 😄

1
joaovjo

Quão pesado seria se o NativeBlade fizesse o mesmo processo do NativePHP de usar um PHP compilado nativamente pra cada plataforma? Mas ao invés de usar o Electron, usar o Tauri? Chegou a testar isso?

1
Jeffs
  • Autor
    Autor

Bom, praticamente ficaria bem mais leve em termo de espaço em disco, mas do meu lado como mantenedor do código, eu perderia muito tendo que compilar o binário toda vez que sair e vocês teriam todo acesso ao que laravel oferece, mas como single thread, eu estaria indo no mesmo caminho que o nativephp e não faria muito sentido, o fato da proposta ser diferente é que faz a comunidade tentar pra sentir qual das duas faz mais sentido, lembrando que esse projeto é algo feito por uma pessoa e a comunidade, enquanto nativephp tem todo eco sistema laravel e o time por trás

1
joaovjo

Em relação a dificuldade da compilação eu entendi, mas não entendi sobre o single thread, para solucionar isso não seria só usar o PHP Thread Safe?

1
Jeffs
  • Autor
    Autor

O PHP Thread Safe (ZTS) permite múltiplas threads rodando PHP simultaneamente, mas cada thread ainda executa PHP de forma síncrona por dentro, você ganha paralelismo entre requests, não dentro de uma request.

No contexto de um app desktop/mobile isso não muda muito na prática, porque geralmente é um único usuário usando o app. O gargalo real não é concorrência entre usuários, é operações bloqueantes como I/O, chamadas a APIs externas e queries pesadas.

E aí é onde a abordagem WASM + bridge assíncrona do NativeBlade resolve diferente, o PHP sinaliza a operação, o Rust/JS executa de forma assíncrona, e o PHP re-executa com o resultado em cache. Não é threading, é cooperativo. 😄

2
maniero

Respondi sobre isso em: https://pt.stackoverflow.com/a/133375/101.

Sim, é possível, não é difícil fazer isso acontecer e sempre terá quem faça por vários interesses até legítimos. A questão é se deve fazer.

Dando spoiler, eu não me surpreenderia se o Rasmus tivesse mudado de ideia em algum momento nos últimos anos (alguém pode já saber disso se aconteceu) para que PHP seja usado em outros cenários, afinal "todos" os pais querem que seus filhos tenham o maior sucesso possível, mesmo que crie problemas no filho e na prática o filho entregue resultados piores.

PHP foi criado para backend web (leia no link). Toda tentativa de fazer mais que isso vai contra a filosofia inicial.

E é verdade que PHP já se transformou e abandonou a filosofia inicial de simplicidade, e pior ainda quando usa frameworks ou técnicas que fogem da simplicidade. Por exemplo, enquanto vários frameworks novos ou adaptados estão abandonando ou tornando cidadãos de segunda classe ferramentas complexas para backend web, PHP vai criando mais complexidade para atender cenários que o simples atenderia muito bem e a linguagem, ou podemos chamar de framework, porque PHP é um framework com uma linguagem embutida (por isso uso "PHP" no masculino, esteve na vanguarda entregando formas simples de criar websites, e até os mais complexos poderiam ser realizados com essa simplicidade.

Então, assim como PHP resolveu que tipagem dinâmica não era algo bom e que se não fizesse tudo com classes estava errado, e um pouco fora dele, mas dentro do que a comunidade adotou, adotar MVC para tudo, não seria estranho ver PHP adotando outros cenários que ele não foi idealizado. E é preciso dizer que hoje é mais fácil fazer PHP funcionar em outros cenários, porque PHP resolveu competir com Java, C# ou outras tecnologias que foram criadas para entregarem algo mais robusto, algo que PHP nunca poderá entregar sem quebra total de compatibilidade.

Claro que tudo funciona e claro que hoje grande parte das pessoas só querem isso mesmo. Então pode ter sucesso, ainda que tenha um histórico de coisas feitas para PHP que sucumbiram.

Eu entendo porque tudo isso acontece, mas não vou entrar em detalhes sem um psicólogo me apoiando.

Que venham as pedras.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

1
Jeffs
  • Autor
    Autor

Concordo com boa parte do que você disse, e o link é excelente leitura.

Mas o NativeBlade não tenta mudar o PHP, ele apenas coloca o PHP onde o dev já está confortável. O PHP continua fazendo o que sempre fez: processar uma request e devolver HTML. Quem mudou foi o ambiente ao redor "WASM e Tauri" que tornaram isso possível fora do servidor.

Se vai ter sucesso ou sucumbir como outros projetos similares, só o tempo dirá. Por enquanto está sendo divertido de construir. 😄

1
klawdyo

Flutter é nativo de verdade. Ele é compilado para o sistema operacional que será usado. Não confunda "ser nativo" com "usar os elementos fornecidos pelo sistema nativo".
Quem não é nativo é o react native, que usa gambiarra pra acessar coisa nativa, e o ionic que usa webview

1
Jeffs
  • Autor
    Autor

Você está certo em viés técnico, erro meu na publicação, eu coloquei a informação em detrimento de você não estar programando na linguagem nativa de fato, mas sim, usando outra linguagem pra fazer o meio de campo, mas no final vira código nativo sim!

1
1
Jeffs
  • Autor
    Autor

e de fato é, ele usa a mesma ideia do react native pra trazer os componentes nativos para tela! Nessa minha lib é diferente, de fato é uma webview, mas ele tem comportamento muito similar ao nativo e com apenas 1 base de código você entrega desktop e mobile

1
1
Jeffs
  • Autor
    Autor

Era uma ótima opção também antes do electron!!! No meu caso, como utilizo laravel com livewire é bem mais abstraido, sendo assim, você é bem produtivo no desenvolvimento, não precisa recriar a roda, senta, faz o composer install, instala node, rust e php artisan nativeblade:install, pronto, você já tem um aplicativo desktop funcional com animações, que vão te ensinar a base de uso dos componentes fundamentais, isso é bastante produtivo.

1
Oletros

Meus 2 cents,

Obrigado por compartilhar !

Tem muitos DEVs que torcem o nariz para o uso do PHP (nao totalmente destituidos de razao), mas eh um ambiente onde me sinto "confortavel".

Existem um certo embate aqui, afinal com Agentes de Codificacao (como ClawCode, ClaudeCode, Codex, etc) é muito facil criar app do zero "nativamente" e em poucas horas, mas no final das contas a gente ainda precisa auditar o codigo e a aplicacao gerados - e fazer isso em um ambiente como o PHP para mim eh muito natural devido a familiaridade com sua estrutura.

Parabens pela iniciativa !

Devidamente favoritado, starreado e forkeado - na fila de testes.

Saude e Sucesso !

1
Jeffs
  • Autor
    Autor

Você tocou num ponto que eu nem tinha pensado em destacar, IA + NativeBlade é uma combinação muito natural. Você descreve o que quer, a IA gera em Laravel, você audita num ambiente familiar, e o app já está rodando no celular/desktop. A familiaridade com o ambiente é exatamente o que permite auditar com confiança e esse é o ponto mais importante quando se fala em código gerado por IA.

Saúde e sucesso também!

1
TechNoirDev

O PHP é muito versátil, e se você souber exatamente o que está fazendo, não vejo problema nenhum em implementações como essa. Não entendo por que ainda existe tanto ranço com a linguagem entre Devs...

Parabéns pela iniciativa, deixei mais uma estrela lá.

2
Jeffs
  • Autor
    Autor

Obrigado pelo comentário, além do mais, é algo feito pra comunidade, pra aprender com o desenvolvimento, é totalmente open source, então ninguém tem nada a perder, pois o que você pode aprender nesse projeto, pode usar em outros diferentes até mesmo com outra linguagem, um sábio dizia: Não é a falta de saber que te faz burro, mas a ignorância.

-6