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

Made with Slides.com