Webapps puros en HTML de un solo archivo, portables y con autoactualización

• Hyperclay permite crear webapps donde toda la UI, la lógica y los datos se integran en un solo archivo HTML
• Es posible hacer ediciones inmediatas y compartir en tiempo real directamente desde el propio archivo, con control total sobre la apariencia, el comportamiento y hasta la forma de edición de la app
• Ofrece una estructura de ejecución y guardado instantáneos sin proceso de build o despliegue aparte, base de datos ni backend complejo
• Con un solo archivo HTML, la app puede ejecutarse en cualquier lugar: navegador, servidor u offline, y todos los cambios quedan versionados y pueden recuperarse
• Está diseñado para reducir la complejidad del desarrollo web moderno y permitir que cualquiera cree fácilmente apps interactivas vivas en tiempo real

---

Introducción: Hyperclay, webapps vivas hechas con un solo archivo HTML

• Hyperclay ofrece a los programadores la experiencia de moldear webapps como si estuvieran esculpiendo un producto, usando un único archivo HTML portable y sin gestionar infraestructura compleja
• Busca una estructura autosuficiente basada en un solo archivo, eliminando elementos que antes eran esenciales en el desarrollo web como archivos de configuración, builds, frameworks y pipelines de despliegue

Concepto central y ventajas

• La app está compuesta por un solo archivo HTML
• El propio archivo puede editarse en tiempo real mediante una UI visual, y esos cambios se guardan de forma permanente como estado de la app
• La UI, la lógica y los datos están incluidos dinámicamente dentro de un mismo archivo
• El usuario puede modificar la app al instante como si fuera un documento, y compartir o descargar los cambios de inmediato para usarlos también offline
• Como en la analogía de "Google Docs para código interactivo", compartir, editar y controlar la propiedad resulta flexible y libre

Resumen de funciones principales

• Manipulación directa: se puede editar la app mientras está en ejecución. Los cambios se reflejan al instante, sin compilar ni recargar
• What you see is what you build: al modificar la UI o editar directamente el código fuente, la app cambia de inmediato, sin capas intermedias
• Portabilidad real: la app puede exportarse como archivo HTML y ejecutarse igual en cualquier lugar (servidor u offline). Cada guardado queda versionado y puede recuperarse
• Todo esto se logra sin tecnología especial, únicamente con un archivo HTML estándar

Estructura técnica

• Hyperclay está compuesto por un servidor NodeJS y una biblioteca JS del lado del cliente
• Cuando la propia página HTML modifica el DOM, envía el document.body.outerHTML cambiado al servidor, y ese mismo archivo HTML se actualiza
• Los cambios dentro de la app, como el atributo checked de un checkbox, se guardan permanentemente en el código HTML, lo que permite reproducir el mismo estado en la siguiente visita
• Incluye control de versiones y gestión de permisos de lectura/escritura

Ejemplos reales

• Es posible crear y guardar todo tipo de apps en un solo archivo HTML, como blogs editables directamente o listas de verificación de horario laboral
• Con el atributo contenteditable o con algo como ``, el estado de la app se registra directamente en el documento

Contexto y problemática

• Tras crear decenas de sitios web cada año, existía la necesidad de que programar webapps fuera tan natural como escribir
• Los sitios web estáticos tradicionales tienen cambios efímeros (las acciones del usuario no se guardan)
• Para implementar persistencia de datos en la web, suele hacer falta demasiado trabajo: base de datos, API, plantillas, sistema de cuentas, etc.
• Esto resulta ineficiente para prototipos, herramientas simples, registros personales de desarrollo, blogs y otros casos donde se quiere crear rápido, editar en tiempo real y compartir

Cómo lo resuelve Hyperclay

• Integra UI, estado y comportamiento en un solo archivo HTML
• Se puede abrir y modificar de inmediato con facilidad, como si se abriera una app de escritorio, y reflejar el resultado online al instante
• Propone el concepto de objetos digitales persistentes (shared, cloneable, persistent)
• Puede aplicarse a creadores de sitios web, herramientas de documentos, diagramas y presentaciones, dashboards, blogs, creación de encuestas y quizzes, visualización de datos y más

Resumen general del concepto

• La mayoría de las webapps ya usan HTML
• Si se eliminan las capas intermedias, el archivo HTML puede asumir el papel de base de datos / API / UI, simplificando el stack a apenas unas cuantas líneas
• Los desarrolladores pueden reducir la complejidad y crear apps con código mínimo que sigan ofreciendo buena usabilidad y mantenimiento

Ejemplos de uso de Hyperclay

• Cualquier app, desde un blog hasta una checklist, puede escribirse, desplegarse, compartirse y editarse con un solo HTML
• Se puede usar directamente con algo como `¡Mi blog!

`, y con `` cada estado queda registrado de forma permanente en el documento

Conclusión

• Hyperclay propone una nueva forma de crear webapps interactivas livianas y altamente portables, permitiendo que cualquiera las comparta, guarde y recupere en tiempo real sin las complicaciones del desarrollo web
• Es una plataforma de webapps de próxima generación que puede ser usada fácilmente no solo por desarrolladores y diseñadores, sino por cualquier persona

[bobross0]

Interesante.

[aobamisaki]

Esto se parece en principio a aquellos editores web que antes estaban por todas partes, pero resulta interesante que funcione solo con un archivo HTML. Personalmente, también me parece una especie de Proof-of-Concept, aunque sinceramente también me da curiosidad ver qué podría pasar si esto se aprovechara bien.

[ifmkl]

¿No funciona esto básicamente igual que el editor que apareció antes en https://es.news.hada.io/topic?id=19611? Yo también le añadí en mi servidor un backend sencillo con Node.js para self-hosting, para guardar las publicaciones escritas con el editor, y le agregué dos funciones a index.html: cargar y mostrar la lista. Lo uso como un blog/tablero de publicaciones simple, y por lo que vi, se siente prácticamente igual.

[reagea0]

¡Qué interesante! Me pregunto qué tal será la seguridad.

[m00nlygreat]

Qué idea tan interesante. tiddlyWIki también era divertido.

[developerjhp]

Qué interesante..

[GN⁺]

Comentarios de Hacker News

• Hyperclay permite que una página HTML actualice el DOM y se mantenga continuamente al día reemplazando el código fuente .html modificado mediante un servidor NodeJS y una biblioteca JS de frontend
  Por ejemplo, al hacer clic en una casilla de verificación se agrega el atributo checked, y ese estado de document.body.outerHTML se guarda globalmente con Hyperclay para reflejarse tal cual en la siguiente visita
  También admite control automático de versiones y gestión de permisos de lectura/escritura
  Creo que es más útil cuando el rol de desarrollador y editor de contenido es el mismo; si varios editores lo usan al mismo tiempo, podrían sobrescribir los cambios de los demás
• Si un servidor NodeJS es obligatorio, entonces me confunde un poco que se presente como un archivo HTML completamente autocontenido
• Agregué esto tal cual a la página principal
  Por cierto, estoy implementando una forma de hacer push de “migraciones de esquema basadas en DOM” a todas las apps que los desarrolladores hayan forkeado
• Escuché que TiddlyWiki fue una inspiración, pero ¿no era precisamente su esencia una estructura que no necesitaba servidor?
  En la práctica, cuando uno crea una webapp sencilla sí llega un punto en que hace falta un servidor, pero esa mezcla entre un enfoque sin servidor y uno acoplado al servidor se siente un poco contradictoria
  Aun así, una ventaja sería mejor acceso entre dispositivos, y la edición en línea parece que sería más fácil
  En mi caso, edito desde el teléfono en un editor de texto y sincronizo con la laptop usando una app de sincronización
• Ojalá los estándares web dieran mejor soporte a las páginas locales ejecutadas con el protocolo file://
  Cada vez que intento hacer una miniapp simple en HTML/Vue, surgen varios problemas y siempre termino buscando soluciones alternativas
  Por ejemplo, un archivo HTML local no puede importar módulos JS locales ni abrir otros archivos locales (como audio)
  Entiendo que hacen falta restricciones para evitar accesos indiscriminados, pero estaría bien algún mecanismo para permitirlo indicando ciertas extensiones o directorios
  Tener que levantar un servidor web cada vez se siente demasiado engorroso y excesivo; lo ideal sería escribir la URL y que la app corra de inmediato
  • Una gran limitación en las webapps tipo generador es que solo las páginas cargadas por HTTPS pueden usar la API del portapapeles, así que en file:/// la función de copiar no funciona
    Incluso en apps totalmente offline, sin build ni dependencias, esta limitación obliga a reemplazar botones por áreas de texto, lo cual es molesto
    Para levantar un servidor local, usar un devcontainer de VS Code hace que el servidor se inicie automáticamente, y con un comando extra también se puede tener HTTPS en local
  • Antes, en Windows existía el enfoque HTA: archivos HTML con otra extensión, sin menú del navegador y con permisos de acceso al sistema de archivos
    Era débil en seguridad, pero hoy una versión moderna basada en Electron con acceso a carpetas o a una base sqlite podría ser bastante útil
    Otra alternativa sería un constructor de apps wasm como Orca, que solo ofrece canvas sin navegador ni DOM
  • Entiendo el riesgo de los archivos HTML locales, pero me gustaría que el navegador tuviera un modo “solo offline” para separar el sistema de archivos local de las páginas externas y controlar el acceso
    No sería una solución perfecta, pero permitiría usar el navegador como un servidor local restringido de forma simple e intuitiva, y eso ya sería bastante útil
  • Siempre me molestó un poco que se empezara a encerrar HTML como plataforma local
    Aun así, cosas como audio y JavaScript siguen funcionando hasta cierto punto, y levantar un servidor web con python/node se hace de inmediato, así que tampoco es tan difícil
    Se arregla agregando un comando webserver_here a la terminal o dejándolo siempre activo
    De hecho, el riesgo del HTML local hace que uno quiera límites aún más estrictos
  • Hace poco estuve pensando en algo parecido aquí y aquí
    Por ahora, la única alternativa es localStorage con exportación/importación manual
    Hyperclay me dio una idea, y me interesa imaginar una app en Electron que se instale una sola vez y luego cargue muchas miniapps, como Electron Fiddle
• Me daba curiosidad cómo está implementado técnicamente Hyperclay
  No quedaba claro si solo hablaban de localStorage o si sobrescriben archivos directamente con FileSystemAPI, entre otros detalles del funcionamiento
  También quería saber si, cuando el usuario guarda, se refleja automáticamente sin mostrar el diálogo de “guardar como”
  • Hyperclay tiene dos formas de funcionar
    1. Hosting: varias apps HTML llaman a su endpoint /save para guardar y sobrescribir HTML (con respaldo y control de versiones)
    2. Local: puedes descargar el Hyperclay Local de código abierto (enlace) y operarlo por tu cuenta; también llama al endpoint /save, permite respaldos y puedes alojarlo personalizado en tu propio servidor (solo hace falta implementar auth)
  • No sé, si llevas esto un paso más allá, ¿no termina pareciéndose en esencia a PHP o WordPress con sintaxis de servidor añadida?
    Da la impresión de un ciclo en el que el sistema se multiplica y se vuelve cada vez más complejo, aumentando la carga más que aportando una mejora real
  • Sentí un poco rara esa mezcla entre el mensaje “ignora el ruido del desarrollo web moderno y crea la experiencia que quieres” y la puesta en escena entre textos cortos e imágenes meme
    La experiencia que yo quiero es una explicación central clara, una historia con hilo conductor y diagramas solo donde realmente hacen falta
  • Hay una base de datos en el servidor y allí se guarda el HTML
    O sea, no parece un enfoque basado en JSON para guardar solo los cambios, sino más bien almacenar el HTML completo en cada momento
  • Por lo que entiendo, se actualiza el propio archivo HTML
    Los cambios en formularios, atributos, etiquetas, etc. se reflejan directamente en el código fuente HTML
• Se siente como un regreso a la visión original de la WWW
  Los primeros navegadores web (la app de Tim Berners-Lee para NeXT) también incluían funciones de edición
  Las razones por las que la edición de HTML desapareció de la web temprana fueron:
  1. no existía el método HTTP PUT, así que el HTML editado no podía guardarse en la web y solo podía guardarse localmente
  2. navegadores como Mosaic se distribuyeron sin funciones de edición por razones de complejidad, y la masificación tomó otro rumbo
  • Una web donde se pueda leer/comentar/escribir es la web que llevo mucho tiempo deseando
    Es genial que, como Hyperclay, cada página pueda tener su propio toolkit, pero lo verdaderamente deseable sería contar con herramientas estándar a nivel del navegador (agente de usuario) disponibles en cualquier parte
  • La W3C mantuvo durante más de 10 años un editor web llamado Amaya
    Me parecía una gran idea y un muy buen banco de pruebas
    Da pena que haya desaparecido, pero encajaba claramente con la visión inicial
  • En el contexto inicial de TBL (Tim Berners-Lee), guardar localmente era igual a guardar en la web
    En las estaciones de trabajo universitarias se usaban recursos compartidos en red como NFS, así que en la práctica los archivos quedaban publicados y accesibles con la misma dirección de la máquina
    En estaciones SGI funcionaba perfectamente apenas configurabas la red
    Además, el foco de la web era estructurar información, y el contenido importaba más que la apariencia
    Con el tiempo, esa intención se fue perdiendo por la obsesión con la apariencia, el modelo WYSIWYG y el abuso de tablas/divs
    Es realmente difícil diseñar algo simple que cualquiera pueda entender, y hoy se ha convertido en una estructura bastante compleja que solo comprende un pequeño grupo de especialistas
    Es una pena que HTML siga siendo fácil de usar, pero en el desarrollo moderno se haya vuelto una tecnología compleja y especializada
    Parece que ya quedan muy pocos que entienden bien el contexto al que apuntaba originalmente TBL
  • Sobre la idea de que “el navegador web también es un editor”
    Hoy en día todos los navegadores permiten modificar HTML/JS/CSS en vivo mediante herramientas de desarrollador, así que uno termina pensando que todos son editores
    Me pregunto si la gente no usa devtools, o si solo usa React o TS en lugar de vanilla JS/HTML
    Chrome, Firefox y Safari ya ofrecen funciones a nivel de IDE integradas en el navegador, así que incluso se puede programar directamente ahí
• Revisando Hyperclay, parece que usa DOM (DOM virtual)
  También estaría bien agregar un poco más de política estilo Shopify y avisos legales
  Si ven mi perfil de HN, entenderán por qué esto me parece genial y al mismo tiempo siento que hacen falta consideraciones legales
• He probado algo parecido con archivos de guardado de juegos
  La primera línea tenía la forma <!DOCTYPE html><html><head><script>const rawData =, y la segunda contenía el estado completo
  Al presionar el botón de guardar, tomaba document.documentElement.outerHTML, reemplazaba la segunda línea por el estado actualizado y lo descargaba
  Funciona incluso sin servidor
  Código relacionado
  • En Chrome, si creas el siguiente marcador con URL data: puedes dejar abierto un editor tipo bloc de notas en una pestaña, y mientras no la cierres el estado se conserva

    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>  
    

  • Yo también hice algo parecido: un juego que funciona como un solo archivo HTML
    Después de editar el texto, se puede guardar como una nueva versión local
    En Android + Brave funciona bien, pero en iOS + Safari no está soportado
• TiddlyWiki también es una herramienta con más de 20 años de historia en este espacio
  Hyperclay parece poner más énfasis en multiusuario/multitenancy y persistencia basada en base de datos
  También vale la pena echarle un vistazo a TiddlyWiki
• Parece un proyecto de alguien que redescubrió los archivos HTA de Windows 98
  Wiki de HTA
  • HTA era como el Electron original
    Eso sí, en el viejo entorno de IE depurar era un infierno
  • HTA era una tecnología buena para su tiempo (y a la vez terrible)
    Parecía una página web normal, pero era exclusiva de IE y además tenía permisos para ejecutar procesos locales
    El problema era manejar la persistencia, y la similitud aquí es bastante limitada
  • Antes de eso, parece que Outlook Web Access cumplía una función parecida
    Outlook on the web
  • Pensé exactamente lo mismo y venía a comentar eso
• Me parece una idea peculiar y me gustaría probarla algún día
  También estuve viendo el sitio y, en general, me gustó, pero me pregunto dónde empiezan a aparecer las limitaciones reales
  En seguridad: si yo puedo cambiar una página, ¿otros también pueden? ¿Cómo se gestionan los permisos?
  ¿En qué punto se vuelve difícil de mantener cuando crecen la cantidad de código y la lógica? ¿Qué pasa cuando aumenta el volumen de datos?
  Por ejemplo, si yo hago una app para gestionar cervezas, ¿otro usuario podría copiar solo la app y usarla por separado, sin mis datos?
  • Seguridad: es prácticamente el mismo modelo de confianza que usan SquareSpace y casi todos los constructores de sitios web
    Los usuarios pueden modificar libremente su propio sitio
    Si un usuario rompe esa confianza, pierde acceso a la cuenta de pago y además asume responsabilidad si causa daños a otros
  • Permisos de edición: cualquiera que haya creado una app puede modificarla
    Si activas la función signups, otros usuarios también pueden forke ar la app fácilmente y mantener trazabilidad respecto al original
    También se está implementando la función para hacer push de actualizaciones a las apps forked
  • Dificultad de mantenimiento: Pieter Levels de NomadList también opera una app que genera $60k al mes con un solo index.php, así que al final depende de cómo ordenes el código y cuánto estés dispuesto a tolerar lo innecesario
  • Otras personas pueden forkear la app y hacer que solo guarde sus propios datos
    Más adelante planeo agregar funciones colaborativas, pero por ahora es más adecuado para usuarios individuales
• La idea se siente novedosa
  El proyecto Webstrates está experimentando con algo parecido
  Usa el DOM como capa de persistencia para crear software colaborativo para grupos pequeños, mientras que Hyperclay se diferencia en que aplica este mecanismo directamente a páginas web tradicionales
  Últimamente también están probando un enfoque local-first con MyWebstrates
  Me pregunto si Hyperclay también podría soportar edición offline usando Webworker
  • Clemens, soy alguien profundamente impresionado por Webstrates
    Lo descubrí por primera vez el año pasado mientras pensaba en Hyperclay
    De verdad quiero intentar hacer una versión local-first de Hyperclay, y creo que la edición offline es un pilar del software personal
    ¿Te interesaría intercambiar ideas por videollamada?