Webapps em HTML puro de arquivo único, portáteis e com atualização automática

• Hyperclay permite criar webapps em que toda a UI, lógica e dados são integrados em um único arquivo HTML
• É possível fazer edição imediata e compartilhamento em tempo real diretamente no próprio arquivo, controlando você mesmo a aparência, o comportamento e até a forma de edição do app
• Oferece uma estrutura de execução e salvamento imediatos sem processo separado de build e deploy, banco de dados ou backend complexo
• Com apenas um arquivo HTML, é possível executar o app em qualquer lugar, como no navegador, no servidor ou offline, e todas as alterações são versionadas e podem ser restauradas
• Foi projetado para reduzir a complexidade do desenvolvimento web moderno e permitir que qualquer pessoa crie facilmente apps interativos vivos em tempo real

---

Introdução: Hyperclay, webapps vivos feitos com um único arquivo HTML

• Hyperclay oferece aos programadores a experiência de criar webapps como se estivessem moldando um produto, usando um único arquivo HTML portátil e sem gerenciar infraestrutura complexa
• O objetivo é eliminar elementos antes considerados essenciais no desenvolvimento web, como arquivos de configuração, build, frameworks e pipelines de deploy, e chegar a uma estrutura completa com apenas um arquivo

Conceito central e vantagens

• O app é composto por um único arquivo HTML
• É possível editar o próprio arquivo em tempo real por meio de uma UI visual, e essas edições são salvas permanentemente como o estado do app
• UI, lógica e dados ficam todos incluídos dinamicamente em um único arquivo
• O usuário pode modificar o app na hora como se fosse um documento, e compartilhar ou baixar imediatamente as alterações para uso offline
• Como na analogia “Google Docs for interactive code”, há liberdade para compartilhar, editar e controlar a propriedade

Resumo dos principais recursos

• Manipulação direta: é possível editar enquanto o app está em execução. As mudanças são aplicadas imediatamente, sem compilação nem recarregamento
• What you see is what you build: ao modificar a UI ou editar diretamente o código-fonte, o app muda na mesma hora, sem camadas intermediárias
• Portabilidade real: o app pode ser exportado como arquivo HTML e executado da mesma forma em qualquer lugar (servidor ou offline). Todo salvamento recebe versionamento e pode ser restaurado
• Tudo isso funciona sem nenhuma tecnologia especial, apenas com um arquivo HTML padrão

Estrutura técnica

• Hyperclay é composto por um servidor NodeJS e uma biblioteca JS no lado do cliente
• Quando a própria página HTML modifica o DOM, ela envia o document.body.outerHTML alterado ao servidor, e esse próprio arquivo HTML é atualizado
• Alterações dentro do app, como o atributo checked de um checkbox, são salvas permanentemente no código HTML, permitindo reproduzir o mesmo estado no próximo acesso
• Há suporte a controle de versão e controle de permissões de leitura/escrita

Exemplos práticos

• É possível criar e salvar em um único arquivo HTML apps como blogs editáveis diretamente, checklists de horas de trabalho e muito mais
• O estado do app é gravado diretamente no documento com o atributo contenteditable ou no formato ``

Contexto e problema identificado

• Ao criar dezenas de sites todos os anos, surgiu a necessidade de que programar webapps fosse tão natural quanto escrever
• Sites estáticos tradicionais têm mudanças efêmeras (as ações do usuário não são salvas)
• Para implementar persistência de dados na web, normalmente é preciso um esforço excessivo com banco de dados, API, templates e sistema de contas
• Isso é ineficiente para protótipos, ferramentas simples, logs pessoais de desenvolvimento, blogs e outros casos em que se quer criar rápido, editar em tempo real e compartilhar

Como o Hyperclay resolve isso

• UI, estado e comportamento são integrados em um único arquivo HTML
• Assim como abrir um app de desktop, é possível abrir facilmente e editar na hora, refletindo o resultado online imediatamente
• Apresenta o conceito de objetos digitais persistentes (shared, cloneable, persistent)
• Pode ser aplicado a vários tipos de ferramenta, como construtores de sites, ferramentas de documentos, diagramas e apresentações, dashboards, blogs, criação de enquetes e quizzes, e visualização de dados

Resumo do conceito geral

• A maioria dos webapps já usa HTML
• Ao eliminar etapas intermediárias, o arquivo HTML passa a cumprir o papel de banco de dados / API / UI, simplificando a stack a apenas algumas linhas
• Os desenvolvedores podem reduzir a complexidade e criar apps com o mínimo de código, mas ainda com ótima usabilidade e manutenção

Exemplos de uso do Hyperclay

• Blogs, checklists e praticamente qualquer app podem ser criados, distribuídos, compartilhados e editados com um único HTML
• Pode ser usado imediatamente no formato `내 블로그!

`, e com `` cada estado fica registrado permanentemente no documento

Conclusão

• Hyperclay propõe uma nova forma de criar webapps interativos leves e altamente portáteis, que qualquer pessoa pode produzir, compartilhar, salvar e restaurar em tempo real sem a burocracia do desenvolvimento web
• É uma plataforma de webapps de nova geração que pode ser usada com facilidade não só por desenvolvedores e designers, mas por qualquer pessoa

[bobross0]

Interessante.

[aobamisaki]

Isso parece ter um princípio de funcionamento semelhante ao daqueles editores web que estavam por toda parte antigamente, mas é interessante que funcione apenas com um único arquivo HTML. Pessoalmente, isso também me parece uma espécie de Proof-of-Concept, mas, sinceramente, também fico curioso para saber no que isso poderia dar se fosse bem aproveitado.

[ifmkl]

Isso não funciona basicamente da mesma forma que o editor que apareceu antes em https://pt.news.hada.io/topic?id=19611? Aqui também adicionei um backend simples em nodejs no servidor para self-hosting, para salvar os posts escritos no editor, e mais duas funções no index.html para carregar e mostrar a lista, e uso isso como um quadro de blog simples; olhando ao redor, a sensação é a mesma.

[reagea0]

Interessante!
Fico curioso sobre como fica a segurança.

[m00nlygreat]

Ideia interessante. O tiddlyWIki também era divertido.

[developerjhp]

Interessante..

[GN⁺]

Comentários no Hacker News

• O Hyperclay permite que páginas HTML atualizem o DOM e se mantenham continuamente atualizadas substituindo o código-fonte .html modificado por meio de um servidor NodeJS e de uma biblioteca JS de frontend
  Por exemplo, ao clicar em uma caixa de seleção, o atributo checked é adicionado, e esse estado de document.body.outerHTML é salvo globalmente com o Hyperclay para ser reaplicado na próxima visita
  Também oferece versionamento automático e controle de permissões de leitura/escrita
  Acho que isso é mais útil quando o papel de desenvolvedor e editor de conteúdo é o mesmo, porque, se vários editores usarem ao mesmo tempo, eles podem sobrescrever as alterações uns dos outros
• Se um servidor NodeJS é obrigatório, fico confuso porque então isso não parece possível apenas com um arquivo HTML totalmente autocontido
• Adicionei isso literalmente à página inicial
  Aliás, estou implementando uma forma de enviar "migrações de esquema baseadas em DOM" para todos os apps que os desenvolvedores fizerem fork
• Ouvi dizer que o TiddlyWiki foi uma inspiração, mas não era justamente o ponto central do TiddlyWiki funcionar sem servidor?
  Na prática, quando você cria um webapp simples, acaba chegando a um ponto em que precisa de um servidor, mas essa mistura de abordagem sem servidor com acoplamento a servidor parece um pouco contraditória
  Ainda assim, uma vantagem seria melhorar o acesso entre dispositivos, e a edição online parece mais fácil
  No meu caso, eu edito no celular com um editor de texto e sincronizo com o laptop por um app de sincronização
• Eu gostaria que os padrões da web dessem suporte melhor a páginas de arquivo local executadas via protocolo file://
  Sempre que eu fazia miniapps simples em HTML/Vue, surgiam vários problemas e eu acabava tendo que procurar soluções alternativas
  Por exemplo, um arquivo HTML local não consegue importar módulos JS locais nem abrir outros arquivos locais (como áudio)
  Entendo que restrições sejam necessárias para evitar acesso indiscriminado, mas seria bom se houvesse uma forma de permitir isso explicitando certas extensões ou diretórios
  Ter que subir um servidor web toda vez é trabalhoso e exagerado demais; o ideal seria simplesmente digitar a URL e o app já rodar
  • Uma grande limitação em webapps do tipo gerador é que só páginas carregadas via HTTPS podem usar a API da área de transferência, então a função de copiar não funciona em file:///
    Até apps totalmente offline, sem build nem dependências, acabam tendo que trocar botões por áreas de texto por causa dessa limitação, o que é inconveniente
    Para rodar um servidor local, dá para usar um devcontainer do VS Code para subir o servidor automaticamente, e com um comando extra também dá para ter HTTPS localmente
  • Antigamente o Windows tinha o modelo HTA, que eram arquivos HTML com outra extensão, sem menus do navegador e com permissão de acesso ao sistema de arquivos
    Em termos de segurança era frágil, mas hoje uma versão moderna baseada em Electron, com acesso a pasta e banco sqlite, poderia ser útil
    Outra alternativa são construtores de apps wasm como o Orca, que fornecem só canvas, sem navegador nem DOM
  • Entendo os riscos de arquivos HTML locais, mas gostaria que o navegador tivesse um modo "somente offline" que separasse o sistema de arquivos local das páginas externas
    Não resolveria tudo perfeitamente, mas ainda assim seria útil por permitir usar o navegador como um servidor local limitado de forma simples e intuitiva
  • Eu tinha certo incômodo com o fato de começarem a restringir o HTML como plataforma local
    Ainda assim, áudio, JavaScript e outras coisas funcionam até certo ponto, e subir um servidor web com python/node também não é tão difícil
    Basta adicionar um comando webserver_here no terminal ou deixá-lo sempre disponível
    Na verdade, os riscos do HTML local me fazem querer limites ainda mais rígidos
  • Recentemente tive preocupações parecidas aqui e aqui
    Por enquanto, as únicas alternativas são localStorage e exportação/importação manual
    Tirei uma ideia do Hyperclay e tenho interesse em imaginar um app em Electron que você instala uma vez e depois usa para carregar vários miniapps, como o Electron Fiddle
• Fiquei curioso sobre como o Hyperclay é implementado tecnicamente
  Não ficou claro se é só questão de localStorage, ou se ele sobrescreve arquivos diretamente com a FileSystemAPI, entre outros detalhes de funcionamento
  Também queria saber se, quando o usuário salva, isso é aplicado automaticamente sem uma caixa de diálogo "salvar como"
  • O Hyperclay tem dois modos
    1. Hospedado: vários apps HTML chamam seu próprio endpoint /save para salvar e sobrescrever HTML (com backup e versionamento)
    2. Local: você baixa o Hyperclay Local de código aberto (link) e roda por conta própria; ele também chama o endpoint /save, permite backup e pode ser hospedado em um servidor customizado por você (basta implementar a autenticação)
  • Não sei... levando isso um passo além, isso não acaba sendo essencialmente parecido com PHP com sintaxe de servidor adicionada, ou com WordPress?
    Conforme o sistema se multiplica, ele vai ficando mais complexo e dá a impressão de um ciclo em que a carga aumenta em vez de haver uma melhora real
  • A encenação da mensagem "ignorar o ruído do desenvolvimento web moderno e construir a experiência que eu quero" misturada entre textos curtos e imagens de meme me pareceu um pouco estranha
    A experiência que eu quero é uma explicação central, um pano de fundo com fluxo e diagramas apenas onde forem realmente necessários
  • Há um banco de dados no servidor, e a estrutura armazena HTML
    Ou seja, não parece ser baseado em JSON salvando só as mudanças, mas sim em armazenar o HTML completo a cada momento
  • Pelo que entendi, o próprio arquivo HTML é atualizado
    Alterações em formulários, atributos, tags etc. são refletidas diretamente no código-fonte HTML
• Isso dá a sensação de se aproximar de novo da visão original da WWW
  Os primeiros navegadores web (o app do Tim Berners-Lee para NeXT) também incluíam funções de edição
  Os motivos pelos quais a edição de HTML desapareceu da web no começo foram:
  1. o método HTTP PUT não existia, então não dava para salvar o HTML editado na web e só localmente
  2. navegadores como o Mosaic foram distribuídos sem recursos de edição por razões como complexidade, e a direção da popularização acabou mudando
  • Uma web em que se pode ler/comentar/escrever é a web que eu queria há muito tempo
    É legal criar um toolkit próprio para cada página, como no Hyperclay, mas o ideal mesmo seria haver ferramentas padronizadas no nível do navegador (agente do usuário) que pudessem ser usadas em qualquer lugar
  • O W3C manteve por mais de dez anos um editor web chamado Amaya
    Acho que foi uma boa ideia e cumpriu bem o papel de testbed
    É uma pena que tenha desaparecido, mas combinava claramente com a visão inicial
  • No contexto inicial do TBL (Tim Berners-Lee), salvar localmente era o mesmo que salvar na web
    Em workstations universitárias, compartilhamentos de rede como NFS faziam com que arquivos ficassem efetivamente publicados e acessíveis pelo mesmo endereço da máquina
    Em workstations SGI, se a rede estivesse configurada, isso funcionava perfeitamente de imediato
    Além disso, o foco da web era estruturar informação, e o conteúdo importava mais do que a aparência
    Com o tempo, veio a obsessão pela aparência com o modelo WYSIWYG e o abuso de tabelas/divs, e esse espírito inicial foi se perdendo
    Fazer um design simples que qualquer pessoa entenda é realmente difícil, e hoje isso virou uma estrutura bastante complexa, compreendida só por um pequeno grupo de especialistas
    É lamentável que HTML ainda seja algo fácil de usar, mas no desenvolvimento moderno tenha se tornado uma técnica complexa e especializada
    Parece que restaram poucos que realmente entendem o contexto que o TBL pretendia
  • Sobre a ideia de que "o navegador também é um editor"
    Hoje em dia, todos os navegadores permitem editar HTML/JS/CSS ao vivo via ferramentas de desenvolvedor, então isso faz pensar se todos eles já não são editores
    Fico me perguntando se as pessoas não usam devtools, ou se só trabalham com React ou TS em vez de JS/HTML vanilla
    Chrome, Firefox e Safari oferecem recursos a nível de IDE embutida no navegador, então também dá para programar diretamente neles
• Pelo que vi do Hyperclay, ele parece usar DOM (DOM virtual)
  Seria ainda melhor se adicionasse também algo no estilo das políticas e avisos legais da Shopify
  Se você olhar meu perfil no HN, vai entender por que acho isso legal, mas também por que sinto falta da parte jurídica
• Já tentei algo parecido com arquivos de save de jogos
  A primeira linha era algo como <!DOCTYPE html><html><head><script>const rawData =, e a segunda linha continha o estado completo
  Quando eu apertava o botão de salvar, pegava document.documentElement.outerHTML, atualizava a segunda linha com o estado mais recente e fazia o download
  Isso funcionava sem servidor
  Código relacionado
  • No Chrome, dá para criar o marcador abaixo com URL data: e manter um editor estilo bloco de notas em uma aba; enquanto a aba não for fechada, o estado é preservado

    data:text/html,<html><head><title>Notepad</title><style>html,body{margin:0;padding:0;}textarea{padding:10px;font-family:Courier;font-size:16px;height:100%;width:100%;border:none;outline:none;}</style></head><body><textarea style="height:100%;width:100%;font-size:16px;padding:10px;"></textarea><script>document.getElementsByTagName('textarea')[0].focus()</script></body></html>  
    

  • Eu também fiz algo parecido, um jogo que funciona como um único arquivo HTML
    Depois de editar o texto, dá para salvar como uma nova versão local
    Funciona bem em Android + Brave, mas não é suportado em iOS + Safari
• O TiddlyWiki também é uma ferramenta dessa área com mais de 20 anos de história
  O Hyperclay parece colocar mais ênfase em multiusuário/multi-tenancy e persistência baseada em banco de dados
  Vale a pena consultar também o TiddlyWiki
• Parece um projeto de alguém que redescobriu os arquivos HTA do Windows 98
  Wiki do HTA
  • HTA tinha uma vibe de Electron original
    Só que, no antigo ambiente do IE, depurar aquilo era um inferno
  • HTA era uma tecnologia boa para a época (e ao mesmo tempo terrível)
    Parecia uma página web comum, mas era exclusiva do IE e tinha até permissão para executar processos locais
    O problema era gerenciar persistência, e a semelhança é bem limitada
  • Antes disso, parece que o Outlook Web Access cumpria um papel parecido
    Outlook on the web
  • Pensei exatamente a mesma coisa e ia comentar isso
• Achei a ideia única e quero muito testar um dia
  Também dei uma olhada no site e gostei bastante no geral, mas queria entender onde as limitações aparecem na prática
  Em termos de segurança: se eu posso mudar a página, outras pessoas também podem? Como as permissões são gerenciadas?
  Quando a quantidade de código e lógica cresce, em que ponto isso começa a ficar difícil de manter? E o que acontece quando o volume de dados aumenta?
  Por exemplo, se eu criar um app para gerenciar cervejas, outra pessoa pode copiar só o app e usar separadamente, sem os meus dados?
  • Segurança: é praticamente o mesmo modelo de confiança de quase todos os construtores de sites, como o SquareSpace
    O usuário pode modificar livremente o próprio site
    Se o usuário quebrar essa confiança, perde acesso à conta paga e, se causar prejuízo a terceiros, também assume a responsabilidade
  • Permissão de edição: qualquer pessoa que criar um app pode editá-lo
    Se o recurso "signups" estiver ativado, outros usuários também podem fazer fork do app facilmente, com rastreabilidade até o original
    Também estão implementando a função de enviar atualizações para apps derivados
  • Dificuldade de manutenção: Pieter Levels, do NomadList, também roda um app que fatura US$ 60 mil por mês com um único index.php, então no fim depende de como você organiza o código e de quanto consegue tolerar partes desnecessárias
  • Outras pessoas podem fazer fork do app e operá-lo salvando apenas os próprios dados
    No futuro planejam incluir recursos colaborativos, mas por enquanto ele é mais adequado para uso individual
• Essa ideia parece inovadora
  O projeto Webstrates também está experimentando algo parecido
  Eles estão criando software colaborativo para pequenos grupos usando o DOM como camada de persistência, e a diferença é que o Hyperclay aplica esse mecanismo diretamente a páginas web tradicionais
  Mais recentemente, vêm tentando uma abordagem local-first com o MyWebstrates
  Fico curioso se o Hyperclay também poderia oferecer edição offline usando Webworker
  • Clemens aqui, alguém profundamente impressionado com o Webstrates
    Conheci o projeto pela primeira vez no ano passado, quando estava idealizando o Hyperclay
    Eu realmente gostaria de fazer uma versão local-first do Hyperclay, e acho que edição offline é um pilar do software pessoal
    Você toparia trocar ideias por videochamada?