LiveView: Interfaces Reativas em Tempo Real

Comparativo entre Frameworks

Slide 1 — Django LiveView

Django LiveView

Interfaces Reativas em Tempo Real

Python / Django Channels / WebSocket

SPAs sem JavaScript, sem API REST

Slide 2 — O que é o padrão LiveView?

HTML over the Wire — interfaces reativas sem JavaScript no frontend

Server-Side Rendering

O HTML é renderizado no servidor e enviado ao cliente. Toda a lógica fica no backend.

Conexão Persistente

Usa WebSockets ou AJAX para manter comunicação em tempo real entre cliente e servidor.

Sem JavaScript

O desenvolvedor escreve apenas na linguagem do backend. O framework cuida do JS automaticamente.

Slide 3 — Phoenix LiveView

Elixir / Erlang VM (BEAM)

O Pioneiro — criado por Chris McCord em 2019

• Conexão via WebSockets com fallback para LongPolling
• Change Tracking: envia apenas os diffs ao cliente
• Renderização declarativa com templates HEEx
• LiveComponents reutilizáveis e stateful
• Upload de arquivos com preview em tempo real
• Live Navigation (sem reload de página)
• Escalabilidade massiva (BEAM/OTP)
• Framework mais admirado (Stack Overflow 2025)

Destaques:

Métrica	Valor
~25k	LiveViews simultâneos por 1GB de RAM
v1.1	Versão atual com Colocated Hooks
40kb	Consumo base por conexão WebSocket

Slide 4 — Laravel Livewire

PHP / Laravel

Criado por Caleb Porzio — integração profunda com o ecossistema Laravel

• Comunicação via requisições AJAX (HTTP)
• Data Binding reativo com wire:model
• Componentes PHP + templates Blade
• Validação de formulários em tempo real
• Upload de arquivos integrado
• Alpine.js como companion para interações JS
• Slots e composição de componentes (v4)
• Islands para atualizações isoladas (v4)

Destaques:

Métrica	Valor
v4	Versão mais recente com single-file components
AJAX	Comunicação via HTTP (não WebSocket)
40k+	Desenvolvedores na comunidade

Slide 5 — Django LiveView

Python / Django Channels

Criado por Andros Fenollosa — SPAs em tempo real com Python puro, sem JavaScript

• Conexão persistente via WebSockets (Django Channels)
• ~43% mais rápido que HTMX, ~80% mais rápido que SSR tradicional
• Renderização com sistema de templates do Django
• Comunicação bidirecional em tempo real
• Reconexão automática com exponential backoff
• Stateful: mantém estado no servidor durante a sessão
• Arquitetura orientada a eventos
• Curva de aprendizado zero para quem conhece Django

Sobre o Criador:

• Andros Fenollosa — Full-Stack Developer (Python)
• Autor: "Building SPAs with Django and HTML Over the Wire" (Packt)
• Também criou: Maza (ad blocking)
• Licença MIT · v2.1.9 (PyPI)
• github.com/Django-LiveView

Slide 6 — Quick Start — Instalação

Passo 1: Instalar os pacotes necessários

Pré-requisitos:

• Python 3.10+
• Django 4.2+
• Projeto Django criado

Opção A: Sem Redis (testes)

pip install django-liveview channels daphne
#          ^^^^^^^^^^^^^^^^
#          (destaque vermelho)

Opção B: Com Redis (recomendado para produção)

pip install django-liveview channels channels-redis daphne redis
#          ^^^^^^^^^^^^^^^^          ^^^^^^^^^^^^^^        ^^^^^
#          (destaque vermelho)       (destaque amarelo)    (destaque amarelo)

Iniciar o Redis:

redis-server

ou via Docker:

docker run -d -p 6379:6379 redis:alpine

Slide 7 — Quick Start — settings.py

Passo 2: Configurar o Django para usar ASGI e WebSockets

# settings.py

INSTALLED_APPS = [
    "daphne",      # Servidor ASGI
    "channels",    # Django Channels
    "liveview",    # Django LiveView
    "app",         # Sua app Django
]

ASGI_APPLICATION = "myproject.asgi.application"

Configuração	Descrição
"daphne"	Servidor ASGI — deve ser o primeiro app. Substitui o WSGI e habilita WebSockets.
"channels"	Django Channels — estende o Django para suportar protocolos além de HTTP.
"liveview"	Django LiveView — o framework que fornece handlers, routing e assets JS.
ASGI_APPLICATION	Aponta para o arquivo asgi.py do projeto. Define o ponto de entrada assíncrono.
CHANNEL_LAYERS	Configura a camada de comunicação: InMemoryChannelLayer (testes) ou RedisChannelLayer (produção).

Slide 8 — Quick Start — asgi.py

Passo 3: Configurar o roteamento ASGI (HTTP + WebSocket)

# myproject/asgi.py

import os
from django.core.asgi import get_asgi_application
from channels.routing import ProtocolTypeRouter, URLRouter
from channels.auth import AuthMiddlewareStack
from channels.security.websocket import \  # <-- destaque: websocket
    AllowedHostsOriginValidator
from liveview.routing import get_liveview_urlpatterns

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

application = ProtocolTypeRouter({
    "http": get_asgi_application(),
    "websocket": AllowedHostsOriginValidator(  # <-- destaque: websocket
        AuthMiddlewareStack(
            URLRouter(
                get_liveview_urlpatterns()
            )
        )
    ),
})

Componente	Descrição
ProtocolTypeRouter	Roteador principal: direciona HTTP para Django e WebSocket para Channels.
AllowedHostsOriginValidator	Segurança: verifica se a origem do WS está em ALLOWED_HOSTS.
AuthMiddlewareStack	Autenticação: o consumer terá acesso ao user autenticado.
URLRouter	Roteamento de URLs para WebSocket, similar ao urlpatterns.
get_liveview_urlpatterns()	Configura automaticamente o endpoint /ws/liveview/.

Slide 9 — Quick Start — Template + Handler

Passo 4 e 5: Criar o template base e o handler Python

base.html

{% load static %}
{% load liveview %}                                    <!-- destaque: load liveview -->
<!DOCTYPE html>
<html lang="en" data-room="{% liveview_room_uuid %}"> <!-- destaque: data-room -->
<head>
    <meta charset="UTF-8">
    <title>{% block title %}My Site{% endblock %}</title>
</head>
<body data-controller="page">
    {% block content %}{% endblock %}
    <script src="{% static 'liveview/liveview.min.js' %}"
        defer></script>
</body></html>

liveview_components/hello.py

from liveview import liveview_handler, send        # destaque: liveview_handler, send
from django.template.loader import render_to_string


@liveview_handler("say_hello")                     # destaque: liveview_handler
def say_hello(consumer, content):                  # destaque: consumer
    name = content.get("form", {}).get("name", "World")

    html = render_to_string(
        "hello_message.html",
        {"message": f"Hello, {name}!"},
    )

    send(consumer, {                               # destaque: send, consumer
        "target": "#greeting",
        "html": html,
    })

Legenda:

• load liveview — template tags do LiveView
• data-room — UUID único por página (sala WS)
• liveview_handler / consumer / send — API principal

Slide 10 — Quick Start — Frontend e Execução

Passo 6 e 7: Template da página, URLs e rodar o servidor

hello_page.html

{% extends "base.html" %}
{% block content %}
<form>
    <input type="text" name="name"
        placeholder="Enter your name">

    <button
        data-liveview-function="say_hello"
        data-action="click->page#run">
        Say Hello
    </button>
    <div id="greeting">
        <h1>Hello, World!</h1>
    </div>
</form>
{% endblock %}

Como funciona

Atributo	Descrição
data-liveview-function="say_hello"	Qual handler Python chamar
data-action="click->page#run"	Evento click -> controller page -> método run
id="greeting"	Alvo do target: "#greeting" no handler

Rodar o servidor

python manage.py migrate          # Criar tabelas
python manage.py collectstatic    # Copiar JS do LiveView
python manage.py runserver        # Iniciar com Daphne (ASGI)

Slide 11 — Comparativo Geral

Característica	Phoenix LiveView (Elixir)	Laravel Livewire (PHP)	Django LiveView (Python)
Criador	Chris McCord	Caleb Porzio	Andros Fenollosa
Protocolo	WebSocket + LongPolling	AJAX (HTTP)	WebSocket
Renderização	Server (HEEx)	Server (Blade)	Server (Django Templates)
Stateful	Sim	Sim	Sim
Change Tracking / Diffs	Avançado	Parcial	Não
SPA sem API	Sim	Não é SPA	Sim
Upload de Arquivos	Nativo	Nativo	Não documentado
Componentes Reutiliz.	LiveComponent	Livewire Comp.	~ Via templates
Validação de Forms	Tempo real	Tempo real	~ Via eventos
Reconexão Automática	Sim	N/A (HTTP)	Exp. Backoff
Maturidade	Alta (2019, v1.1)	Alta (2020, v4)	Emergente (v2.1)

Slide 12 — O que têm em Comum

HTML renderizado no servidor

Todos os três renderizam HTML no backend e enviam ao cliente, eliminando a necessidade de frameworks JavaScript como React ou Vue.

Lógica 100% no backend

O desenvolvedor escreve apenas na linguagem do servidor (Elixir, PHP ou Python). O JavaScript é gerado automaticamente pelo framework.

Interfaces reativas sem JavaScript

Atualizações em tempo real na interface sem o desenvolvedor precisar escrever código JavaScript manualmente.

Stateful no servidor

Mantêm o estado da conexão no lado do servidor, permitindo interações complexas e persistentes durante a sessão.

Inspirados pelo mesmo conceito

Todos seguem o padrão 'HTML over the Wire', que traz a lógica de UI para o servidor e reduz a complexidade do frontend.

Slide 13 — Diferenças Chave

Phoenix LiveView

• WebSocket + LongPolling fallback
• Change tracking com diffs mínimos
• Escalabilidade massiva (BEAM)
• Ecossistema mais maduro
• Suporte nativo a PubSub
• Code generators integrados

Laravel Livewire

• Comunicação via AJAX/HTTP
• Ecossistema Laravel enorme
• Alpine.js como companion
• Islands (v4) para updates isolados
• Single-file components (v4)
• Não requer WebSocket server

Django LiveView

• WebSocket persistente apenas
• Mais rápido que HTMX (~43%)
• Arquitetura orientada a eventos
• SPA completo sem APIs
• Reconexão com exp. backoff
• Projeto mais novo/emergente

Slide 14 — Quando usar cada um?

Phoenix LiveView

Aplicações de alta concorrência, real-time intensivo, chat, dashboards ao vivo, sistemas distribuídos. Ideal quando escalabilidade é prioridade.

Laravel Livewire

Aplicações Laravel existentes que precisam de interatividade. CRUDs dinâmicos, formulários complexos, painéis admin. Ideal para quem já está no ecossistema Laravel.

Django LiveView

Projetos Django que precisam de real-time sem adotar frontend separado. SPAs simples, protótipos rápidos, equipes que dominam Python. Ideal para quem quer simplicidade.

Slide 15 — O que ainda falta no Django LiveView?

Oportunidades de melhoria comparado ao Phoenix LiveView e Laravel Livewire

Change Tracking / Diffs

Envia o HTML completo do fragmento. Phoenix envia apenas os bytes que mudaram, reduzindo o tráfego drasticamente.

Upload de Arquivos

Não há documentação oficial sobre upload via WebSocket. Phoenix e Livewire têm upload nativo com preview em tempo real.

Code Generators

Sem equivalente ao mix phx.gen.live do Phoenix que gera CRUD completo com LiveView automaticamente.

Fallback para LongPolling

Apenas WebSocket. Se a conexão WS não for possível, não há fallback. Phoenix oferece LongPolling como alternativa.

Componentes Dedicados

Sem LiveComponents com estado próprio como no Phoenix. Reutilização de UI é feita via templates Django tradicionais.

Comunidade e Ecossistema

Projeto mantido por um único desenvolvedor. Comunidade menor comparada a Phoenix (25k GitHub stars) e Livewire (40k devs).

Referência: django-liveview.andros.dev