Parte 2 de 3 desta série sobre camada de view no Laravel. Na parte 1 defendi o Blade. Aqui: Livewire. Na próxima: Inertia.
Escrever SPA sem escrever JavaScript. Mágica ou pacto com o capeta?
Você monta uma tabela que filtra em tempo real, com paginação e busca, um formulário reativo, tudo atualizando sem recarregar a página. E não escreveu uma linha de JavaScript. Só PHP e Blade.
Na primeira vez que isso funciona, dá vontade de rir. Parece trapaça. É o Livewire.
Mas aí vem o dev mais velho, cruza os braços e solta a frase que sempre aparece nos comentários: "isso faz um request pro servidor a cada clique, né? Boa sorte em escala".
E os dois estão certos. Deixa eu explicar.
Como o Livewire funciona (e por que isso importa)
O Livewire é um componente PHP com estado no servidor. Quando você interage — digita, clica, filtra — ele dispara um request AJAX pro backend. O servidor pega o estado atual do componente, roda seu método PHP, re-renderiza a view inteira do componente e devolve o HTML. O Livewire compara com o que já está na tela e atualiza só o que mudou.
class TabelaProdutos extends Component
{
public string $busca = '';
public function render()
{
return view('livewire.tabela-produtos', [
'produtos' => Produto::where('nome', 'like', "%{$this->busca}%")->paginate(10),
]);
}
}
<input type="text" wire:model.live="busca" placeholder="Buscar...">
Simples, elegante, produtivo. E é justamente esse wire:model.live que pode virar a bomba.
Onde o Livewire é genial
- CRUDs e painéis internos: onde a interatividade é média e o número de usuários é controlado. É o ponto doce absoluto do Livewire.
- Formulários complexos: validação reativa, campos dependentes, wizard de múltiplos passos — tudo em PHP, sem duplicar regra no front.
- Times backend-heavy: aquele time que manja de Laravel mas não quer manter uma stack JS separada com build, rota e estado próprios. O Livewire elimina essa camada inteira.
- Prototipagem: você valida uma ideia interativa numa velocidade absurda.
Pra esses casos, quem chama o Livewire de gambiarra está deixando produtividade na mesa por preconceito.
Onde o Livewire te morde
Agora o outro lado, sem passar pano:
- Latência: cada interação é uma ida e volta ao servidor. Numa rede boa, imperceptível. Num 4G capenga, aquele filtro que atualiza "na hora" ganha meio segundo de delay a cada tecla.
- Payload: o componente re-renderiza no servidor a cada ação. Se ele é grande, você está gerando (e trafegando) HTML a cada clique.
- Listas gigantes e altíssima interatividade: dashboards em tempo real, editores, canvas, drag-and-drop pesado. Aqui o modelo "request a cada ação" trabalha contra você, e JS de verdade (ou Inertia) faz mais sentido.
Livewire não é lento. Mas ele troca um pouco de performance por muita produtividade — e você precisa saber que essa troca existe pra não usá-lo no cenário errado.
Pegadinha: wire:model.live num input é um pé na jaca silencioso
Esse é o erro que derruba gente. Você coloca wire:model.live num campo de texto e, sem perceber, dispara um request ao servidor a cada tecla digitada. Um campo de busca vira uma metralhadora de AJAX.
A correção é boba quando você sabe:
{{-- ❌ um request por tecla --}}
<input wire:model.live="busca">
{{-- ✅ espera 300ms de silêncio antes de disparar --}}
<input wire:model.live.debounce.300ms="busca">
{{-- ✅ ou só dispara quando o campo perde o foco --}}
<input wire:model.blur="busca">
Uma palavrinha (debounce, blur, lazy) e você corta 90% dos requests desnecessários. A maioria dos "Livewire é lento" que você lê por aí é, na verdade, wire:model.live sem debounce.
Antes de você fechar a aba
A pergunta não é "Livewire é bom ou ruim?". É: o seu caso está no ponto doce dele ou fora?
CRUD interno com 200 usuários? Ponto doce, vai fundo. Dashboard em tempo real pra 50 mil pessoas? Repensa.
Você é time "Livewire salvou minha vida" ou time "não confio nessa mágica"? Cai nos comentários — e segue pra parte 3, onde eu fecho a série provocando o Inertia: ele matou a API REST do seu projeto? 🔥
Top comments (0)