Datastar - framework de hipermedia ligero para crear apps web interactivas

 (data-star.dev)
16 puntos por GN⁺ 2025-10-12 | 1 comentarios | Compartir por WhatsApp
  • Datastar es un framework ligero con el que se puede crear desde sitios web estáticos simples hasta apps web colaborativas en tiempo real, y se puede empezar solo agregando una etiqueta de script a HTML
  • Adopta un enfoque hypermedia-first que extiende HTML para permitir crear una UI interactiva centrada en el backend
  • Ofrece reactividad del backend como htmx, pero también soporta reactividad en el frontend como Alpine.js, y funciona sin paquetes npm ni dependencias
  • En el frontend implementa comportamiento reactivo mediante atributos estándar data-*, y en el backend realiza modificaciones del DOM y cambios de estado mediante eventos
  • Con actualizaciones en tiempo real basadas en SSE (Server-Sent Events) y SDK para varios lenguajes, busca simplificar el desarrollo de apps web reactivas dirigidas por el backend

Resumen de Datastar

  • Datastar es un framework basado en hipermedia que extiende HTML, con una arquitectura que permite implementar apps web interactivas en tiempo real manipulando el DOM directamente desde el backend
  • Del lado del navegador, todas las funciones se activan cargando un script de solo 10.7KB, sin necesidad de instalar herramientas de build ni frameworks
  • Hereda los principios de Hypermedia Systems, donde el servidor lidera el estado de la UI y el cliente lo refleja de forma reactiva
  • Al procesar actualización de datos, cambios de estado y patching del DOM mediante eventos del backend, minimiza la lógica en el frontend

Cómo instalarlo

  • La forma más sencilla es agregar el script mediante CDN, así:
  • También se puede descargar el archivo directamente o usar el Datastar bundler para generar un bundle propio
  • No hace falta instalar npm ni configurar un entorno Node

Atributos data-* y reactividad

  • La idea central es definir el comportamiento de forma declarativa mediante los atributos data-* de HTML
    • Ejemplo: data-on-click="alert('Hello!')"
  • El atributo data-on especifica la expresión de Datastar que se ejecutará cuando ocurra un evento determinado, y ahí también se puede usar JavaScript normal
  • Ofrece autocompletado y soporte de sintaxis mediante una extensión para VSCode y un plugin para IntelliJ

Patching del DOM dirigido por el backend

  • Datastar funciona con un modelo donde el servidor dirige el frontend
    • Cuando el servidor envía fragmentos HTML, Datastar los fusiona en el DOM usando una estrategia de morphing
    • El morphing actualiza solo las partes modificadas, conservando el estado y mejorando el rendimiento
  • Ejemplo: 
    <button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button>  
<div id="hal"></div>
    Si el servidor responde con un fragmento HTML, Datastar reemplaza automáticamente el elemento con id="hal"

Streaming basado en Server-Sent Events (SSE)

  • El servidor puede enviar el evento datastar-patch-elements para actualizar el DOM en tiempo real

  • El siguiente ejemplo muestra cómo imprimir una línea de HAL y reiniciarla de nuevo un segundo después

    event: datastar-patch-elements  
data: elements <div id="hal">I’m sorry, Dave. I’m afraid I can’t do that.</div>  

event: datastar-patch-elements  
data: elements <div id="hal">Waiting for an order...</div>

  • Para esto, Datastar ofrece SDK para varios lenguajes:

    • Clojure, C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Node.js
    • Cada SDK emite eventos de patching del DOM mediante clases como PatchElements o ServerSentEventGenerator

Datastar Inspector y herramientas

  • Además de las herramientas de desarrollo del navegador, se puede usar Datastar Inspector para revisar visualmente los eventos SSE
  • Además de la documentación oficial, ofrece abundante material como DeepWiki generado por IA, ejemplos de código para LLM y documentación en una sola página

Conclusión

  • Datastar es un enfoque moderno que simplifica el desarrollo de aplicaciones de hipermedia centradas en HTML
  • Es más ligero que los frameworks SPA tradicionales y ofrece una experiencia de desarrollo reactivo equilibrada entre backend y frontend
  • Es adecuado para proyectos que necesitan streaming en tiempo real, control de UI centrado en el servidor y despliegue sin dependencias

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-10-12
Opiniones de Hacker News

  • El equipo de Datastar tiene convicciones y una filosofía muy claras, y además dedica generosamente su tiempo incluso a quienes recién empiezan. En medio de la polémica alrededor de la versión Pro, eso se está olvidando, pero esto de ninguna manera es una estrategia de monetización, y la empresa está registrada como organización sin fines de lucro. Solo apartaron como Pro funciones que realmente necesita una minoría, y como precisamente ese pequeño grupo es el que más consulta sobre esas funciones, así controlan de forma eficiente la carga de soporte. Más bien parece un enfoque innovador y justo porque (a) señala que son funciones con las que hay que tener cuidado por lo problemáticas que pueden ser, (b) hace que quienes más soporte requieren o más valor obtienen de Datastar paguen un pequeño costo, y (c) permite dedicar más tiempo a toda la comunidad, con un efecto positivo

    • Si funciones como data-animate, data-on-resize y data-scroll-into-view son realmente de las que “te meten en problemas”, entonces están mal diseñadas. Tampoco creo que sean funciones que solo necesite una minoría. No me molesta que cobren por lo que quieran, pero no creo que haga falta inventar una excusa para ello

    • Me pregunto si de verdad la función copy-to-clipboard genera una carga de soporte tan alta. Si el nivel de Datastar fuera realmente tan pobre, eso implicaría que incluso una función simple necesita mucho soporte para funcionar bien, y me cuesta estar de acuerdo

  • Si crees que Datastar no da para tiempo real/colaboración/multijugador, o que las funciones Pro son imprescindibles, basta con ver estas 3 demos que aguantaron la portada de HN funcionando en un VPS de 5 dólares y sin funciones Pro para notar que Datastar es una ingeniería realmente impresionante

  • Guía de hilos relacionados que están en curso en HN:

  • No entiendo bien por qué la comunidad está siendo tan hostil. Datastar es mayormente open source, funciona con cualquier lenguaje y además es un proyecto interesante porque está pensando cómo financiar su desarrollo. Me parece natural que impulsen su propio proyecto a su manera. También pienso probar a hackear con golang, y gracias por el esfuerzo. Solo tengo una observación: en mi país, 299 dólares es muchísimo dinero, y algunas funciones Pro podrían ser realmente necesarias, así que el precio se siente demasiado pesado. Me gustaría que consideraran algo como precios dinámicos por país, al estilo Steam, o apoyo por donaciones. Funciones como animaciones, por ejemplo, en sveltekit se ofrecen gratis; no es que quiera recibir todo gratis, es que de verdad no me alcanza. Ojalá cobraran más a empresas y lo hicieran más barato para desarrolladores solitarios. Nunca he pagado por una comunidad o proyecto en línea, pero por Datastar sí me gustaría aportar unos 5 a 10 dólares. Ojalá el precio de la capa para independientes bajara al nivel de un juego de Switch como silksong. Es un proyecto realmente genial, así que da pena que la reacción de la comunidad sea tan exageradamente crítica

    • Esa opinión me parece la única crítica razonable de toda la discusión hasta aquí. 299 dólares es, de verdad, una cifra inaccesible para muchísima gente. Sin embargo, también puede ser una cantidad pequeña en comparación con el valor que aportan desarrolladores que viven en países con un costo de vida alto. Es buena idea querer un sistema de precios por país, pero implementarlo puede ser complicado y el beneficio real quizá mínimo. Como las funciones open source gratuitas ya entregan más del 95% del valor y la funcionalidad, la mayoría de la gente que realmente no necesita la licencia Pro simplemente debería usar gratis todo lo que pueda, aprender de ello o beneficiarse de ello sin problema

    • Mi crítica parte de lo siguiente

      • En la página principal no se menciona Pro en absoluto; me enteré hurgando en la documentación. Se siente como un gancho
      • Pro agrupa funciones reales, no solo soporte o ejemplos
      • Si dependes de funciones Pro, quedas atado a Datastar y el control del mantenimiento queda en manos del proveedor
      • Sin Pro, el sitio ni siquiera funciona, así que el vendor lock-in se vuelve un problema mayor
      • No hay demos para probar qué estás comprando con Pro; no hay nada que puedas testear en el navegador como en Alpine.js o React Flow Pro
      • Aunque recibas el código fuente, tampoco puedes compartir mejoras
      • No es un problema de precio, sino de estructura y de valor; para algunos puede ser barato y para otros caro
      • Ejemplos de modelos Pro bastante decentes para tomar como referencia: Alpine.js Pro, React Flow Pro

    • Incluso una empresa pequeña tiene que cubrir su propio soporte, así que en países con costo de vida alto, con 5 dólares no alcanza ni para atender un solo ticket de soporte

  • Llevo varios meses desarrollando un frontend con Go y Templ sobre Datastar. Me gusta mucho la función @actions y la forma en que la página se actualiza según la respuesta. Aun así, personalmente sigo pensando qué hacer con la función signals. Para cosas como un campo único o un dropdown está bien, pero mi backend usa una API estilo Kubernetes, y cuando intento guardar recursos JSON en una signal, no encaja bien porque Datastar parsea la estructura en sub-signals. En especial, estructuras como los labels de Kubernetes, donde la key lleva un prefijo de hostname, no se pueden manejar en absoluto y las signals terminan hechas un desastre. El data binding funciona bien con rutas simples de keys, pero no con rutas que requieren índices o keys tipo hostname. Además, las reglas de conversión automática de atributos HTML en JS (snake→camel, etc.) y el manejo de modifiers también generan muchos errores, así que se vuelve complejo. Aun así, me gusta que unifique capacidades de HTMX/Alpine en una sola implementación hipermedia. También me gusta poder evitar el ecosistema de NodeJS. En la RC cambió el wire format, y como estaba implementándolo directamente con Fiber sin usar el SDK de Go, actualizar fue difícil. Pero creo que el cambio de formato fue para bien. El equipo va en buena dirección, así que ojalá siga evolucionando

  • La idea de Datastar me parece muy buena, y en algún momento incluso pensé en adoptarla. Pero me preocupa que la versión open source haya sido limitada para no competir en funciones con Pro; eso podría ser un camino rápido hacia un hard fork. No es que tenga un ecosistema gigantesco, así que veo suficientes razones para cambiarse
    [edit: el modelo de open core con algunos plugins cerrados puede ser perfectamente razonable, y aunque no lo fuera, hay muchas alternativas. Ojalá tanto los desarrolladores como los usuarios de Datastar tengan éxito]

    • Si te preocupa un hard fork, sería útil para todos que alguien hiciera un fork de los plugins de la era pre-Pro y los adaptara a la versión Pro actual de Datastar. Son piezas de código pequeñas, de unas 50 líneas, así que sería muy fácil

    • La expresión “poner limitaciones” me parece exagerada. Los atributos/eventos exclusivos de Pro son pocos y no son funciones centrales. De hecho, todo eso se puede reemplazar con un poco de JS enviado desde el servidor. Lista concreta aquí: https://data-star.dev/reference/datastar_pro

    • De verdad recomiendo hacer un fork; ojalá alguien lo haga

  • Quizá es porque ya estoy demasiado acostumbrado al ecosistema de React, pero para mí este enfoque se siente lógicamente mucho más difícil cuando quieres hacer cosas de cierta complejidad en adelante. Si no estoy entendiendo mal la explicación, Datastar es un patrón backend-frontend donde el backend devuelve HTML, y por mi experiencia pasada es algo que de verdad no quisiera volver a hacer. Sobre todo para usuarios con conexiones lentas —y todavía hay muchos con dsl, satélite antiguo, 2G, etc.—, la experiencia se va a sentir mucho peor porque en vez de recibir varias veces pequeñas cantidades de JSON, estarían recibiendo HTML más grande varias veces

    • En mi experiencia, cuando usas una app de React en 2G/3G, muchas veces simplemente no carga nunca; en cambio, si recibes HTML de una sola vez, la mayoría de las veces el contenido aparece en 1 o 2 segundos. Los ingenieros suelen reinventar timeouts arbitrarios, así que la detección del progreso ocurre en el socket, pero la app no transmite esa sensación. Ojalá no insistieran tanto en que todo se sienta “rapidísimo” de manera artificial

    • Ese patrón de “el backend devuelve html” era como funcionaban los sitios web en la época del módem de 56k, y todavía recuerdo cuando hacíamos layouts con decenas de tablas anidadas

    • El frontend es algo muy amplio. Para sitios como un blog personal o una tienda, donde hay mucho contenido estático, lo importante es cargar rápido y la interacción es baja, herramientas del estilo htmx funcionan bien. Pero si quieres construir una app al nivel de Figma o Discord, este enfoque no alcanza. En el extremo más avanzado, el DOM no es más que una cárcel, y solo satisface una combinación de canvas con cálculo en GPU

    • Si necesitas modo completamente offline, claro que este enfoque no sirve y hay que ir por otra cosa. Pero la mayoría de los sitios no necesitan realmente estado persistente, así que con caché de páginas o solo estado de eventos ya alcanza bastante bien. Si haces correr el SDK JS de datastar dentro de un service worker y sincronizas al storage del navegador solo el estado esencial, hasta podría hacer de backend. Incluso con una conexión lenta, si usas compresión agresiva en el stream SSE, aunque se transmita mucha información redundante la tasa de compresión supera fácilmente el 90%. Además, internet lento suele venir acompañado de dispositivos lentos, así que Datastar es muchísimo más liviano que cosas pesadas como React o CSS-in-JS, y funcionalmente casi no pierdes nada mientras todo se vuelve muchísimo más simple

  • No es un patrón especialmente nuevo. Ya se pasó por esto en la transición de DHTML a XHR, y en su momento casi se abandonó por varios trade-offs. Incluso tecnologías nuevas como el DOM patching terminan arrastrando los mismos problemas: acoplamiento fuerte, inestabilidad, peso y latencia. Datastar se siente más como una solución para que una empresa pequeña reduzca costos de desarrollo que como algo que rompa una nueva frontera técnica. No está mal, pero al final da la sensación de que la historia se repite

    • Como autor de Datastar, justamente la intención es que no haya nada nuevo. Extrañaba esa buena época en la que jQuery apenas tocaba un poco la página, antes de que los spa intentaran hacer todo en el frontend y se perdiera la esencia de que el backend es quien tiene el estado. Lo que quiero no es innovar, sino normalizar

    • Me pregunto si Astro no resolvió ya este problema

  • Me encantó tanto el video (película) al final de la página que me dio ganas de usarlo sí o sí en mi próximo proyecto. La parte de “The planet uncomplicanus” me pareció especialmente memorable

  • También me gusta lo que logró https://www.zjax.dev/