Datastar - framework hipermídia leve para criar aplicativos web interativos

 (data-star.dev)
16 pontos por GN⁺ 2025-10-12 | 1 comentários | Compartilhar no WhatsApp
  • Datastar é um framework leve capaz de criar desde sites estáticos simples até webapps colaborativos em tempo real, e pode ser iniciado adicionando apenas uma tag de script ao HTML
  • Adota uma abordagem hypermedia-first que estende o HTML para permitir a criação de UIs interativas centradas no backend
  • Assim como o htmx, oferece reatividade no backend e, como o Alpine.js, também oferece reatividade no frontend, funcionando sem pacotes npm nem dependências
  • No frontend, implementa comportamento reativo com atributos padrão data-*, enquanto no backend realiza modificações no DOM e mudanças de estado por meio de eventos
  • Com atualizações em tempo real baseadas em SSE (Server-Sent Events) e SDKs para várias linguagens, tem como objetivo simplificar o desenvolvimento de webapps reativos guiados pelo backend

Visão geral do Datastar

  • O Datastar é um framework baseado em hipermídia que estende o HTML, com uma arquitetura que permite implementar webapps interativos em tempo real manipulando o DOM diretamente a partir do backend
  • No navegador, basta carregar um script de apenas 10,7 KB para ativar todos os recursos, sem necessidade de ferramentas de build nem instalação de frameworks
  • Herdando os princípios de Hypermedia Systems, o servidor conduz o estado da UI, e o cliente o reflete de forma reativa
  • Ao tratar atualizações de dados, mudanças de estado e patching do DOM como eventos de backend, minimiza a lógica no frontend

Como instalar

  • A forma mais simples é adicionar o script via CDN, assim:
  • Também é possível baixar o arquivo diretamente ou usar o Datastar bundler para gerar um bundle próprio
  • Não é necessário instalar npm nem configurar ambiente Node

Atributos data-* e reatividade

  • O ponto central é definir o comportamento de forma declarativa por meio dos atributos data-* do HTML
    • Exemplo: data-on-click="alert('Hello!')"
  • O atributo data-on especifica a expressão Datastar a ser executada quando um evento específico ocorre, e JavaScript comum também pode ser usado ali
  • Oferece autocompletar e suporte de sintaxe por meio de uma extensão para VSCode e um plugin para IntelliJ

Patching do DOM guiado pelo backend

  • O Datastar funciona com uma abordagem em que o servidor conduz o frontend
    • Quando o servidor envia fragmentos de HTML, o Datastar os mescla ao DOM com uma estratégia de morphing
    • O morphing atualiza apenas as partes alteradas para preservar o estado e melhorar o desempenho
  • Exemplo: 
    <button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button>  
<div id="hal"></div>
    Quando o servidor responde com um fragmento de HTML, o Datastar substitui automaticamente o elemento id="hal"

Streaming baseado em Server-Sent Events (SSE)

  • O servidor pode enviar o evento datastar-patch-elements para atualizar o DOM em tempo real

  • O exemplo a seguir mostra a fala do HAL sendo exibida e depois reinicializada 1 segundo depois

    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 isso, o Datastar fornece SDKs para várias linguagens:

    • Clojure, C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Node.js
    • Cada SDK emite eventos de patching do DOM por meio de classes como PatchElements ou ServerSentEventGenerator

Datastar Inspector e ferramentas

  • Além das ferramentas de desenvolvedor do navegador, é possível usar o Datastar Inspector para visualizar eventos SSE
  • Além da documentação oficial, também há materiais abundantes como DeepWiki gerada por IA, exemplos de código para LLMs e documentação em página única

Conclusão

  • O Datastar é uma abordagem moderna que simplifica o desenvolvimento de aplicações hipermídia centradas em HTML
  • É mais leve que frameworks SPA tradicionais e oferece uma experiência de desenvolvimento reativa equilibrada entre backend e frontend
  • É adequado para projetos que precisam de streaming em tempo real, controle de UI centrado no servidor e deploy sem dependências

Leituras relacionadas

1 comentários

 
GN⁺ 2025-10-12
Opinião no Hacker News

  • A equipe do Datastar tem convicções e uma filosofia bem claras, e são pessoas incríveis que dedicam tempo generosamente até para iniciantes. Em meio à controvérsia em torno da versão Pro, isso está sendo esquecido, mas isso de forma alguma é uma estratégia de monetização, e a empresa é registrada como sem fins lucrativos. Eles separaram como Pro apenas recursos de que poucas pessoas precisam, de modo a controlar com eficiência o aumento da carga de suporte, já que são justamente esses pequenos grupos que mais entram em contato querendo essas funções. Na verdade, é uma abordagem inovadora e justa que (a) sinaliza que são recursos com potencial de "dar dor de cabeça", (b) faz com que os usuários que mais precisam de suporte ou que extraem muito valor do Datastar paguem um pequeno valor, e (c) permite dedicar mais tempo à comunidade como um todo, o que é positivo

    • Se recursos como data-animate, data-on-resize e data-scroll-into-view são mesmo os que "dão dor de cabeça", então o projeto não foi bem pensado. Também não acho que sejam recursos necessários só para poucos. Não tenho problema nenhum com eles cobrarem pelo que quiserem, mas acho que não precisa inventar desculpas para isso

    • Fico curioso para saber se a função de copiar para a área de transferência realmente gera uma carga tão grande de suporte. Se o nível do Datastar é realmente tão ruim assim, então até funções simples exigiriam muito suporte para funcionar direito, e acho difícil concordar com isso

  • Se você acha que o Datastar não é suficiente para tempo real/colaboração/multiplayer, ou que os recursos Pro são indispensáveis, vale olhar estes 3 demos que rodaram em um VPS de 5 dólares e aguentaram ficar na capa do HN sem recursos Pro; isso mostra como a engenharia do Datastar é realmente impressionante

  • Aviso de threads relacionadas em andamento no HN:

  • Não entendo bem por que a comunidade está sendo tão hostil. O Datastar é majoritariamente open source, funciona com qualquer linguagem, e o fato de estarem pensando em como financiar o desenvolvimento também faz dele um projeto interessante. Acho natural tocar o próprio projeto do seu próprio jeito. Estou pensando até em fuçar com ele em golang, e agradeço pelo esforço. Só tenho um feedback: no meu país, 299 dólares é realmente muito dinheiro, e alguns recursos Pro podem ser realmente necessários, então o preço pesa demais. Seria bom considerar uma política de preços dinâmica por país, como a da Steam, ou alguma forma de apoio via doação. Coisas como animações já vêm de graça no sveltekit; não é que eu queira tudo de graça, é que realmente não consigo pagar. Seria melhor cobrar mais de empresas e menos de desenvolvedores solo. Nunca paguei por comunidades ou projetos online, mas no caso do Datastar eu toparia apoiar com algo como 5 a 10 dólares. Minha esperança é que baixem o preço da camada solo para algo no nível de um jogo de Switch (silksong). É uma pena ver uma reação tão criticamente exagerada da comunidade para um projeto tão legal

    • Esse comentário me parece a única crítica razoável em toda a discussão até aqui. 299 dólares realmente é um valor inacessível para muita gente. Por outro lado, pode até ser pouco em comparação com o valor entregue por desenvolvedores que vivem em países caros. A ideia de adotar preços por país é boa, mas a forma de implementar isso é complicada e o ganho real pode ser pequeno. Como os recursos open source gratuitos já entregam mais de 95% do valor e da funcionalidade, a maioria das pessoas que realmente não precisa da licença Pro deveria simplesmente usar à vontade a versão gratuita, aprender com ela ou tirar proveito dela

    • Minha crítica parte dos seguintes pontos

      • Na homepage não há qualquer menção ao Pro; você só descobre fuçando a documentação. Parece uma isca
      • O Pro agrupa funcionalidades reais, não apenas suporte ou exemplos
      • Se você depender de recursos Pro, fica preso ao Datastar e a manutenção fica na mão do fornecedor
      • Sem o Pro, o site simplesmente não funciona, então o vendor lock-in vira um problema maior
      • Não há exemplos práticos para experimentar o que se compra no Pro; nada que dê para testar no navegador como no Alpine.js ou React Flow Pro
      • Mesmo recebendo o código-fonte, você não pode compartilhar melhorias
      • A questão não é o preço, mas a estrutura e o valor; para alguns pode ser barato, para outros caro
      • Exemplos de modelos Pro razoáveis para referência: Alpine.js Pro, React Flow Pro

    • Empresas pequenas também precisam dar suporte por conta própria, então em países caros 5 dólares não pagam nem um único ticket de suporte

  • Estou desenvolvendo há alguns meses um frontend com Go e Templ usando Datastar. Estou muito satisfeito com o recurso de @actions e com a forma como a página é atualizada conforme a resposta. Só que pessoalmente ainda tenho dúvidas sobre a funcionalidade de signals. Para campo único ou dropdown funciona bem, mas meu backend usa uma API no estilo Kubernetes, então quando tento armazenar recursos JSON em um signal, isso não encaixa bem por causa da forma como o Datastar decompõe a estrutura em sub-signals. Em especial, estruturas como labels do Kubernetes, em que a chave vem com prefixo de hostname, simplesmente não funcionam, e os signals viram uma bagunça. O data binding funciona bem com caminhos de chave simples, mas não com caminhos que exigem índice ou chave com hostname. Além disso, as regras de conversão automática de atributos HTML para JS (snake→camel etc.) e o tratamento de modifiers também geram muitos erros, o que complica bastante. Ainda assim, gosto do fato de ele unificar recursos de HTMX/Alpine e implementar isso no estilo hypermedia. Também gosto de poder evitar o ecossistema NodeJS. Houve uma mudança no wire format durante o RC, e como eu uso Fiber e implementei tudo direto sem o SDK de Go, foi difícil atualizar; mas acho que a mudança de formato foi positiva. A equipe está indo numa boa direção, então espero que continue evoluindo

  • As ideias do Datastar parecem muito boas, e eu já pensei em adotá-lo. Minha preocupação, no entanto, é que limitar a versão open source para não competir em recursos com a Pro pode ser um caminho rápido para um hard fork. Não é como se ele já tivesse um grande ecossistema, então acho que há motivos suficientes para trocar
    [edit: o modelo de open core com alguns plugins fechados pode ser muito razoável e, mesmo que não seja, há muitas opções. Espero que tanto os desenvolvedores quanto os usuários do Datastar tenham sucesso]

    • Se a preocupação é com hard fork, então seria útil para todo mundo fazer fork dos plugins da era pré-Pro e adaptá-los à versão Pro atual do Datastar. São códigos bem pequenos, coisa de umas 50 linhas, então é bem fácil

    • Dizer que estão "limitando" é exagero. Os atributos/eventos exclusivos do Pro são poucos e não são funcionalidades centrais. Na verdade, quase tudo pode ser substituído com um pouco de JS enviado pelo servidor. Lista específica aqui: https://data-star.dev/reference/datastar_pro

    • Eu realmente recomendo um fork, queria que alguém fizesse isso

  • Talvez porque eu esteja acostumado demais ao ecossistema React, mas sinto que, para qualquer coisa minimamente complexa, essa abordagem parece logicamente muito mais difícil. Se eu não entendi errado, o Datastar é um padrão backend-frontend em que o backend retorna HTML, e pela minha experiência passada é algo que eu realmente não gostaria de fazer de novo. Especialmente para usuários com conexão lenta (ainda existe muita gente em DSL, satélite antigo, 2G etc.), a sensação de desempenho vai cair muito, porque em vez de receber várias pequenas quantidades de JSON, eles vão receber várias respostas HTML bem maiores

    • Pela minha experiência, usar um app React em 2G/3G muitas vezes significa que ele simplesmente nunca carrega. Já quando vem tudo em HTML de uma vez, na maioria dos casos o conteúdo aparece em 1 ou 2 segundos. Os engenheiros vivem reinventando timeout arbitrário, então a detecção de progresso até pode estar no socket, mas no app não se sente isso. Eu preferiria que não tentassem tanto parecer "rápido"

    • Esse padrão de "o backend retorna html" era como os sites funcionavam na era do modem de 56k, e eu ainda lembro de fazer layout com dezenas de tabelas aninhadas

    • Frontend é um campo muito amplo. Para coisas como blog pessoal ou loja, com muito conteúdo estático, necessidade de carregamento rápido e pouca interatividade, ferramentas do tipo htmx fazem sentido. Mas se você quer criar algo no nível de Figma ou Discord, essa abordagem não basta. No extremo, os mestres dessa área veem o DOM como uma prisão, e só ficam satisfeitos com a combinação de canvas e computação via GPU

    • Se for totalmente offline, então claro que não há outra saída além de outra abordagem. Mas a maioria dos sites não precisa realmente de estado persistente, então cache de página ou apenas estado de eventos já bastam razoavelmente. Dá até para rodar o datastar js sdk dentro de um service worker e sincronizar só o estado essencial com o storage do navegador, fazendo o papel do backend. Mesmo em conexões lentas, se você comprimir bem o stream SSE, a redundância de informação aumenta e a taxa de compressão passa de 90%. Internet lenta normalmente também vem acompanhada de dispositivos lentos, então o Datastar fica muito mais leve do que React, css-in-js e afins, quase sem perda funcional, além de ser absurdamente mais simples

  • Não é um padrão particularmente novo. Já passamos por essa abordagem na transição de DHTML para XHR, e ela foi praticamente abandonada por causa de vários trade-offs. Tecnologias novas como DOM patching acabam trazendo os mesmos problemas (acoplamento forte, fragilidade, volume, latência). O Datastar parece mais uma solução para reduzir custos de desenvolvimento em empresas pequenas do que algo que rompe novos limites técnicos. Não acho ruim, mas no fim dá a sensação de que a história está se repetindo

    • Como autor do Datastar, o fato de não haver nada de novo é justamente a intenção. Sinto falta daquela época boa em que o jQuery só fazia pequenas intervenções na página; depois veio a SPA tentando fazer tudo no frontend e se perdeu a essência de que o backend é quem segura o estado. O que eu quero não é inovação, mas normalização

    • Fico pensando se o Astro já não resolveu esse problema

  • Gostei tanto do vídeo (filme) no fim da página que ele me deu vontade de usar isso no meu próximo projeto. A parte "The planet uncomplicanus" foi especialmente marcante

  • Também gostei do que https://www.zjax.dev/ conseguiu fazer