Django LiveView vs Phoenix LiveView: auténtico rendimiento

Tenía curiosidad: ¿cómo se comporta Django LiveView frente a la implementación original de Elixir cuando los comparas en condiciones idénticas? No con argumentos teóricos, sino con números reales.

Monté un dashboard de alertas idéntico en ambos frameworks: añadir, borrar y buscar alertas en tiempo real. El benchmark lo automaticé con Playwright headless Chromium para medir el tiempo entre la acción del usuario y el cambio en el DOM, más los bytes enviados por WebSocket en cada interacción.

El código fuente está en el repositorio y es completamente reproducible con Docker Compose.

Veamos los resultados.

El stack

Escenarios comunes

Medí 10 iteraciones (2 de warmup) para add, delete y search sobre una lista con pocos elementos.

Empate total. Ambos se mueven en el mismo rango de ~22 ms para mutaciones y ~7 ms para búsqueda. La diferencia es estadísticamente irrelevante.

Casos extremos

Aquí empieza a aparecer algo interesante.

Con 500 alertas cargadas, Phoenix es ligeramente más rápido. El rapid fire es prácticamente idéntico.

Sin embargo... el dato más llamativo es el payload:

En la lista grande, Django LiveView transfiere 327 KB por acción frente a los 67 KB de Phoenix. Cada vez que añades una alerta con 500 ya cargadas, Django LiveView vuelve a enviarte la tabla entera. Phoenix solo te manda la fila nueva.

Es una diferencia de diseño, no de implementación. En Django LiveView defines explícitamente qué selector actualizar y con qué HTML:

@liveview_handler("add_alert")
def add_alert(consumer, content):
    alerts = list(Alert.objects.all())
    html = render_to_string("components/_alerts_table.html", {"alerts": alerts})
    send(consumer, {"target": "#alerts-container", "html": html})

En Phoenix LiveView actualizas los assigns y el framework calcula el diff:

def handle_event("add_alert", _params, socket) do
  alert = Alerts.create_random_alert()
  {:noreply, assign(socket, alerts: [alert | socket.assigns.alerts])}
end

Phoenix sabe qué parte del template cambió y solo manda eso. Django LiveView no tiene ese mecanismo, así que la granularidad depende de ti: si apuntas a un selector pequeño, envías menos. Si apuntas a un contenedor grande, envías todo. ¿Esto tiene consecuencias? En conexiones lentas o con muchos clientes simultáneos, sí. En una app con pocos usuarios o con listas pequeñas, será indistinguible.

Concurrencia

¿Qué pasa cuando varios usuarios actúan al mismo tiempo? Lancé entre 1 y 50 clientes simultáneos disparando la misma acción a la vez con una barrera de sincronización.

Con pocos clientes (1-5) ambos se comportan igual, incluso Django es ligeramente más rápido en p50. A partir de 25 clientes simultáneos la diferencia es clara: Phoenix escala mejor, especialmente en add_alert donde con 50 clientes Django dobla la latencia de Phoenix.

Conclusión

Los datos resuelven mi pregunta inicial: "¿Django LiveView aguanta la comparación con Phoenix LiveView?", la respuesta es sí, en operaciones del día a día son prácticamente iguales. La ventaja de Phoenix aparece cuando el payload crece o cuando la concurrencia es alta, aunque son problemas que puedes mitigar con un diseño cuidadoso en Django LiveView, apuntando a selectores más específicos y distribuyendo la carga.

La ventaja de Django LiveView es quedarte en Python y en el ecosistema Django, sin salir de lo que ya conoces, y que Django LiveView es más explícito y predecible: tú decides qué HTML enviar y dónde colocarlo.

Estoy gratamente sorprendido.

PD: Estás ante un sitio realizado 100% con Django LiveView, te invito a probar sus límites.