Webapps en pur HTML : un seul fichier, portable et avec mise à jour automatique

• Hyperclay permet de créer des webapps où toute l’interface, la logique et les données sont intégrées dans un unique fichier HTML
• Le fichier lui-même peut être modifié immédiatement, avec édition instantanée et partage en temps réel, et il est possible de contrôler directement l’apparence, le comportement et le mode d’édition de l’app
• La structure permet une exécution et un enregistrement immédiats sans processus séparé de build ou de déploiement, sans base de données ni backend complexe
• Avec un seul fichier HTML, il est possible d’exécuter l’app partout : dans le navigateur, sur un serveur ou hors ligne, et toutes les modifications sont versionnées et récupérables
• Le projet est conçu pour réduire la complexité du développement web moderne et permettre à n’importe qui de créer facilement des applications interactives vivantes, en temps réel

---

Introduction : Hyperclay, des webapps vivantes créées à partir d’un seul fichier HTML

• Hyperclay offre aux programmeurs une façon de façonner des webapps comme on façonne un produit, à partir d’un fichier HTML portable unique, sans gérer d’infrastructure complexe
• Le projet vise une structure autonome dans un seul fichier, en éliminant les éléments considérés comme indispensables dans le développement web classique : fichiers de configuration, build, framework, pipeline de déploiement

Concept clé et avantages

• L’app est constituée d’un seul fichier HTML
• Il est possible d’éditer le fichier lui-même en temps réel via une interface visuelle, et ces modifications sont immédiatement enregistrées de façon persistante comme état de l’application
• L’interface, la logique et les données sont toutes incluses dynamiquement dans un même fichier
• Comme un document, l’app peut être modifiée instantanément, puis ses changements peuvent être immédiatement partagés ou téléchargés pour un usage hors ligne
• À l’image d’un « Google Docs for interactive code », le partage, la modification et le contrôle de propriété sont très libres

Résumé des principales fonctionnalités

• Manipulation directe : l’app peut être modifiée pendant son exécution. Les changements sont appliqués immédiatement, sans compilation ni rechargement
• What you see is what you build : si l’on modifie l’UI ou directement le code source, l’app change aussitôt, sans couche intermédiaire
• Véritable portabilité : l’app peut être exportée en fichier HTML et exécutée partout (serveur ou hors ligne) de manière identique. Chaque sauvegarde bénéficie d’un versioning permettant la restauration
• Tout cela fonctionne sans technologie spéciale, uniquement avec un fichier HTML standard

Architecture technique

• Hyperclay se compose d’un serveur NodeJS et d’une bibliothèque JS côté client
• Quand la page HTML modifie elle-même le DOM, elle envoie le document.body.outerHTML modifié au serveur, et le fichier HTML lui-même est mis à jour
• Les changements intervenant dans l’app, comme l’attribut checked d’une case à cocher, sont enregistrés de façon persistante dans le code HTML, ce qui permet de retrouver le même état à la connexion suivante
• Prise en charge du versioning et de la gestion des droits de lecture/écriture

Exemples concrets

• Un blog éditable directement, une checklist d’horaires de travail et bien d’autres apps peuvent être créés et enregistrés dans un seul fichier HTML
• L’état de l’app peut être écrit directement dans le document avec l’attribut contenteditable ou sous la forme ``

Contexte et problème identifié

• En créant des dizaines de sites web chaque année, le besoin est apparu de rendre le codage de webapps aussi naturel que l’écriture
• Les sites web statiques traditionnels ont des changements éphémères (les actions des utilisateurs ne sont pas enregistrées)
• Pour implémenter la persistance des données sur le web, il faut généralement mettre en place base de données, API, templates, système de comptes, etc., ce qui représente un travail excessif
• C’est inefficace pour les prototypes, outils simples, journaux de développement personnels, blogs et autres cas où l’on veut créer rapidement, modifier en temps réel et partager immédiatement

La réponse apportée par Hyperclay

• L’UI, l’état et le comportement sont intégrés dans un seul fichier HTML
• Comme on ouvre une application desktop, on peut ouvrir facilement, modifier immédiatement, puis publier le résultat en ligne sans attendre
• Le projet propose le concept d’objet numérique persistant (shared, cloneable, persistent)
• Il peut s’appliquer à de nombreux outils : créateurs de sites web, outils de documents, schémas ou présentations, dashboards, blogs, formulaires ou quiz, visualisation de données, etc.

Résumé global du concept

• La plupart des webapps utilisent déjà du HTML
• En supprimant les étapes intermédiaires, le fichier HTML peut jouer le rôle de base de données / API / UI à lui seul, simplifiant la stack à quelques lignes
• Les développeurs peuvent réduire la complexité et créer des apps faciles à utiliser et à maintenir avec un minimum de code

Exemples d’utilisation de Hyperclay

• Blog, checklist ou n’importe quelle autre app : tout peut être créé, déployé, partagé et modifié avec un seul fichier HTML
• Utilisable directement sous la forme `Mon blog !

`, avec `` pour enregistrer durablement chaque état dans le document

Conclusion

• Hyperclay propose une nouvelle manière de créer des webapps interactives légères et hautement portables, que chacun peut partager, enregistrer et restaurer en temps réel, sans les lourdeurs du développement web
• C’est une plateforme de webapps nouvelle génération que développeurs, designers et non-spécialistes peuvent utiliser facilement

[bobross0]

C’est intéressant.

[aobamisaki]

C’est intéressant : le principe de fonctionnement ressemble à celui des éditeurs web qu’on voyait partout autrefois, mais le fait que tout tienne dans un seul fichier HTML est vraiment intrigant. Personnellement, j’ai aussi l’impression que c’est une sorte de proof of concept, mais je me demande honnêtement ce que cela pourrait donner si c’était bien exploité.

[ifmkl]

Le fonctionnement me semble simplement identique à celui de l’éditeur déjà présenté ici par le passé : https://fr.news.hada.io/topic?id=19611, non ? De mon côté aussi, j’y ai ajouté sur le serveur un petit backend en nodejs pour l’auto-hébergement afin d’enregistrer les posts rédigés avec l’éditeur, puis deux fonctionnalités dans index.html pour charger et afficher la liste, et je m’en sers comme d’un petit tableau d’affichage / blog simple ; en regardant autour, j’ai l’impression que c’est exactement la même chose.

[reagea0]

C'est intéressant !
Je me demande ce qu'il en est de la sécurité.

[m00nlygreat]

Une idée intéressante. TiddlyWiki était aussi amusant.

[developerjhp]

C’est intéressant..

[GN⁺]

Discussion Hacker News

• Hyperclay permet, via un serveur NodeJS et une bibliothèque JS frontend, à une page HTML de mettre à jour le DOM et de rester continuellement à jour en remplaçant le source .html modifié
  Par exemple, lorsqu’on clique sur une case à cocher, l’attribut checked est ajouté, et l’état de document.body.outerHTML est sauvegardé globalement avec Hyperclay pour être restauré tel quel lors de la visite suivante
  Il prend aussi en charge le versioning automatique et la gestion des permissions en lecture/écriture
  Je pense que c’est surtout utile quand le développeur et l’éditeur de contenu sont la même personne, car avec plusieurs éditeurs simultanés ils risquent d’écraser les modifications des autres
• Si un serveur NodeJS est indispensable, je suis un peu perdu quant à l’idée d’un fichier HTML totalement autonome
• J’ai ajouté cela tel quel sur la page d’accueil
  Au passage, le développeur est en train d’implémenter un moyen de pousser des « migrations de schéma basées sur le DOM » à toutes les applications forkées
• J’ai entendu dire que TiddlyWiki avait servi d’inspiration, mais je me demande si le principe central de TiddlyWiki n’était pas justement de ne pas nécessiter de serveur
  En pratique, quand on fabrique une petite webapp, on finit souvent par atteindre un point où un serveur devient nécessaire, mais l’association d’une approche sans serveur et d’un couplage serveur paraît un peu contradictoire
  Cela dit, l’avantage serait une meilleure accessibilité cross-device et un montage plus simple pour l’édition en ligne
  Dans mon cas, j’édite sur téléphone dans un éditeur de texte puis je synchronise sur mon laptop avec une app de sync
• J’aimerais que les standards du Web prennent mieux en charge les pages locales exécutées via le protocole file://
  Chaque fois que j’essaie de faire une mini-app simple en HTML/Vue, je tombe sur plusieurs problèmes et je dois toujours chercher des contournements
  Par exemple, un fichier HTML local ne peut pas importer des modules JS locaux, ni ouvrir d’autres fichiers locaux (audio, etc.)
  Je comprends qu’il faille des restrictions pour éviter les accès incontrôlés, mais ce serait bien d’avoir un mécanisme d’autorisation explicite par extension ou par répertoire
  Démarrer un serveur web à chaque fois est trop pénible et disproportionné ; idéalement, on saisirait juste une URL et l’app démarrerait immédiatement
  • Une grosse limitation pour les webapps de type générateur, c’est que seule une page chargée en HTTPS peut utiliser l’API du presse-papiers ; sur file:///, la fonction de copie ne marche donc pas
    Même pour une app totalement hors ligne, sans build ni dépendances, cette limite oblige à remplacer un bouton par une zone de texte, ce qui est fastidieux
    Pour lancer un serveur local, on peut utiliser un devcontainer VS Code afin que le serveur démarre automatiquement, et avec quelques commandes supplémentaires on peut aussi avoir du HTTPS en local
  • Autrefois, Windows avait les HTA, des fichiers HTML avec une autre extension, sans menus de navigateur et avec accès au système de fichiers
    C’était fragile côté sécurité, mais une version moderne, par exemple basée sur Electron et avec accès à un dossier ou à une base sqlite, pourrait être utile
    Une autre alternative serait un générateur d’apps wasm comme Orca, qui fournit seulement un canvas sans navigateur ni DOM
  • Je comprends les risques des fichiers HTML locaux, mais j’aimerais qu’il existe dans le navigateur un mode « hors ligne uniquement » séparant le système de fichiers local et les pages externes
    Ce ne serait pas une solution parfaite, mais ce serait déjà très utile, car on pourrait se servir du navigateur comme d’un serveur local limité, de manière simple et intuitive
  • J’ai toujours eu un certain agacement face au verrouillage progressif de HTML comme plateforme locale
    Cela dit, l’audio, le JavaScript, etc. fonctionnent encore dans une certaine mesure, et lancer un serveur web avec python/node est immédiat, donc ce n’est pas non plus très compliqué
    Il suffit d’ajouter une commande webserver_here dans le terminal ou de la laisser tourner en permanence
    D’ailleurs, comme les risques du HTML local ont augmenté, j’en viens à vouloir des frontières encore plus strictes
  • J’avais récemment réfléchi au même sujet ici et ici
    Pour l’instant, les seules alternatives sont localStorage et l’export/import manuel
    Hyperclay m’a donné des idées, et je m’intéresse à une app Electron qui s’installerait une seule fois puis chargerait plusieurs mini-apps, un peu comme Electron Fiddle
• J’étais curieux de comprendre l’implémentation technique de Hyperclay
  Je ne savais pas si cela reposait simplement sur localStorage, ou si cela écrasait directement des fichiers via la FileSystemAPI ; il manquait des explications détaillées sur le fonctionnement réel
  Je me demandais aussi si, au moment de sauvegarder, les changements s’appliquaient automatiquement sans boîte de dialogue « Enregistrer sous »
  • Hyperclay propose deux modes
    1. Hébergé : plusieurs apps HTML appellent chacune leur endpoint /save pour enregistrer et écraser leur HTML (avec sauvegardes et versioning)
    2. Local : on télécharge l’open source Hyperclay Local(lien) et on l’exploite soi-même ; là aussi, l’endpoint /save permet les sauvegardes, et on peut l’héberger sur son propre serveur en le personnalisant (il suffit d’implémenter l’auth)
  • Honnêtement, si on pousse encore un peu plus loin, est-ce que cela ne finit pas par ressembler essentiellement à PHP avec de la logique serveur ajoutée, ou à WordPress ?
    J’ai l’impression d’un cycle où, à mesure que le système se duplique, il devient plus complexe et plus lourd, sans forcément apporter d’amélioration réelle
  • Le message « j’ignore le bruit du développement web moderne pour construire l’expérience que je veux » mélangé à de courts textes et à des images de mèmes m’a semblé un peu étrange
    L’expérience que je recherche, c’est une explication centrale, un récit cohérent derrière, et des schémas uniquement là où ils sont nécessaires
  • Il y a une base de données sur le serveur, et elle stocke du HTML
    Donc on n’est pas dans un modèle JSON où seuls les changements sont conservés à part, mais plutôt dans une sauvegarde de l’intégralité du HTML à chaque état
  • Si j’ai bien compris, le fichier HTML lui-même est mis à jour
    Les formulaires, attributs, balises, etc. sont modifiés directement dans le source HTML
• Cela donne l’impression de se rapprocher à nouveau de la vision originelle du WWW
  Les tout premiers navigateurs web (l’application de Tim Berners-Lee sur NeXT) intégraient aussi des fonctions d’édition
  Si l’édition HTML a disparu du Web à ses débuts, c’est parce que
  1. la méthode HTTP PUT n’existait pas encore, donc on ne pouvait pas enregistrer le HTML modifié sur le Web, seulement en local
  2. des navigateurs comme Mosaic ont été diffusés sans fonctions d’édition, notamment pour des raisons de complexité, ce qui a orienté la popularisation du Web dans une autre direction
  • Un Web lisible / annotable / inscriptible correspond depuis longtemps à l’idée que je me fais du Web
    C’est génial de créer une boîte à outils propre à chaque page comme le fait Hyperclay, mais l’idéal serait selon moi d’avoir des outils standard disponibles partout au niveau du navigateur (agent utilisateur)
  • Le W3C a maintenu pendant plus de dix ans un éditeur web appelé Amaya
    C’était une bonne idée, et je pense qu’il a aussi bien joué son rôle de testbed
    C’est dommage qu’il ait disparu, car il correspondait clairement à la vision initiale
  • Dans le contexte initial de TBL (Tim Berners-Lee), sauvegarder en local équivalait à sauvegarder sur le Web
    Sur les stations de travail universitaires, le partage réseau via NFS et autres faisait que les fichiers étaient en pratique stockés publiquement et accessibles à la même adresse machine
    Sur les stations SGI, il suffisait de configurer le réseau et tout fonctionnait immédiatement
    En outre, le Web était centré sur la structuration de l’information, le contenu comptant davantage que l’apparence
    Avec le temps, on s’est focalisé sur le modèle WYSIWYG et sur l’abus des tableaux/divs au service de la mise en forme, au point d’en perdre l’esprit initial
    Concevoir quelque chose de simple et compréhensible par tous est vraiment difficile ; aujourd’hui, on en est arrivé à une structure assez complexe que seule une petite élite de spécialistes maîtrise
    Il regrette qu’HTML soit toujours facile à utiliser, tout en étant devenu dans le développement moderne une technique complexe et spécialisée
    On a l’impression qu’il ne reste qu’un petit nombre de personnes qui comprennent encore vraiment le contexte visé à l’origine par TBL
  • À propos de l’idée que « le navigateur web est aussi un éditeur »
    Aujourd’hui, tous les navigateurs permettent déjà de modifier HTML/JS/CSS en direct via les outils de développement, donc on peut se demander s’ils ne sont pas déjà tous des éditeurs
    Je me demande si les gens n’utilisent pas les devtools, ou s’ils n’emploient plus que React ou TypeScript au lieu de vanilla JS/HTML
    Chrome, Firefox et Safari proposent tous des fonctionnalités proches d’un IDE intégré au navigateur, permettant même de coder directement
• En regardant Hyperclay, il semble que le système s’appuie sur le DOM (DOM virtuel)
  Ce serait encore mieux avec quelques éléments supplémentaires à la Shopify sur les politiques et les mentions légales
  Si on regarde mon profil HN, on comprend pourquoi je trouve ça cool tout en estimant qu’il faut un cadrage juridique
• J’ai déjà tenté quelque chose de similaire pour des fichiers de sauvegarde de jeu
  La première ligne avait la forme <!DOCTYPE html><html><head><script>const rawData =, la deuxième contenait tout l’état
  Quand on clique sur le bouton de sauvegarde, on récupère document.documentElement.outerHTML, puis on remplace la deuxième ligne par l’état le plus récent avant de télécharger le tout
  Cela fonctionne sans serveur
  Code associé
  • Dans Chrome, on peut créer le signet data: URL ci-dessous pour ouvrir dans un onglet un éditeur type bloc-notes ; tant que l’onglet reste ouvert, l’état est conservé

    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>  
    

  • J’ai moi aussi créé un jeu qui fonctionne comme un unique fichier HTML
    On peut modifier du texte puis l’enregistrer comme une nouvelle version locale
    Cela marche bien avec Android + Brave, mais ce n’est pas pris en charge avec iOS + Safari
• TiddlyWiki est lui aussi un outil de ce domaine, avec plus de vingt ans d’histoire
  Hyperclay semble davantage mettre l’accent sur le multi-utilisateur / multi-tenancy et la persistance basée sur une base de données
  TiddlyWiki mérite aussi d’être regardé
• On dirait un projet où quelqu’un a redécouvert les archives de Windows 98 et des HTA
  Wiki HTA
  • Les HTA avaient un côté Electron originel
    En revanche, dans l’ancien environnement IE, le débogage était un véritable enfer
  • Les HTA étaient une technologie à la fois formidable (et en même temps affreuse), très en avance sur leur époque
    Cela ressemblait à une simple page web, mais c’était spécifique à IE et pouvait même lancer des processus locaux
    La persistance restait problématique, et la ressemblance est en réalité très limitée
  • Avant cela, Outlook Web Access jouait peut-être un rôle assez similaire
    Outlook on the web
  • J’ai eu exactement la même pensée, j’allais poster le même commentaire
• Je trouve l’idée originale et j’aimerais vraiment l’essayer un jour
  En regardant le site, j’aime bien l’ensemble, mais je me demande où les limites apparaissent en pratique
  Côté sécurité : si moi je peux modifier la page, est-ce que d’autres le peuvent aussi ? Comment les permissions sont-elles gérées ?
  À partir de quel volume de code ou de logique cela devient-il difficile à maintenir ? Et que se passe-t-il quand la quantité de données augmente ?
  Par exemple, si je crée une app de gestion de bières, est-ce que d’autres utilisateurs peuvent copier l’app séparément et l’utiliser avec leurs propres données, sans accéder aux miennes ?
  • Sécurité : c’est le même modèle de confiance que pour presque tous les constructeurs de sites web comme SquareSpace
    L’utilisateur peut modifier librement son propre site
    S’il abuse de cette confiance, il risque la perte de l’accès à son compte payant et, en cas de préjudice causé à autrui, sa responsabilité peut être engagée
  • Droit de modification : toute personne ayant créé l’app peut la modifier
    Si la fonctionnalité signups est activée, d’autres utilisateurs peuvent aussi forker facilement l’app, avec traçabilité vers l’original
    Une fonction de push des mises à jour vers les apps forkées est en cours d’implémentation
  • Difficulté de maintenance : Pieter Levels de NomadList exploite aussi une app à 60 k$ par mois avec un simple index.php, donc au final cela dépend surtout de la manière dont on organise le code et de ce qu’on accepte d’y laisser traîner
  • D’autres personnes peuvent forker l’app et l’utiliser en ne stockant que leurs propres données
    Des fonctions de collaboration sont prévues plus tard, mais pour l’instant cela convient surtout à un usage individuel
• Je trouve l’idée vraiment novatrice
  Le projet Webstrates expérimente lui aussi quelque chose de proche
  Il s’agit de créer des logiciels collaboratifs pour petits groupes en utilisant le DOM comme couche de persistance, alors que la différence avec Hyperclay est d’appliquer directement ce mécanisme à des pages web traditionnelles
  Plus récemment, ils testent aussi une approche local-first avec MyWebstrates
  Je me demande si Hyperclay pourrait lui aussi prendre en charge l’édition hors ligne via un Webworker
  • Clemens, je suis quelqu’un qui a été profondément marqué par Webstrates
    Je ne l’ai découvert que l’an dernier en réfléchissant à Hyperclay
    J’aimerais vraiment faire une version local-first de Hyperclay, et je pense que l’édition hors ligne est un pilier du logiciel personnel
    Serais-tu partant pour échanger par visioconférence ?