Show HN : Nash - un carnet autonome créé dans un seul fichier HTML

• Nash est un carnet autonome basé sur HTML qui s’ouvre et se modifie dans un navigateur web, sans service séparé
• Les notes enregistrées peuvent être modifiées hors ligne, avec l’objectif d’être manipulées comme des fichiers de document plutôt qu’avec Notion ou Word
• Il peut servir à créer du contenu de type document HTML, comme un blog statique, du contenu sur une seule page, ou l’ajout de photos de pizza depuis une galerie
• Envoyé par messagerie, il peut être consulté via un aperçu, ce qui permet aussi de partager de longs contenus comme des fichiers
• Nash est publié en open source et la page de note vide peut être librement modifiée et utilisée

---

Un carnet HTML utilisable uniquement avec un navigateur

• Nash est un carnet autonome orienté note as HTML
• Il ne nécessite ni logiciel ni service séparé, et peut être utilisé avec un simple navigateur web généralement déjà installé
• Les notes enregistrées prennent en charge la modification hors ligne
• Une page de note vide peut être ouverte sur nash.html

Types de contenu possibles et mode de partage

• Il peut être utilisé pour créer un blog statique ou du contenu sur une seule page
• Il permet aussi de rédiger du contenu en joignant par exemple des photos présentes dans une galerie
• Lorsqu’il est envoyé par messagerie, il peut être consulté en aperçu, ce qui le rend utile pour partager de longs contenus
• Il est né de l’expérience consistant à réaliser rapidement des POC d’idées simples avec un seul fichier HTML, et constitue une première tentative de créer un fichier de document fonctionnant sans service ni logiciel séparé
• Nash est publié en open source, et peut être librement modifié et utilisé

[xguru]

Nash, une note autonome fonctionnant dans un seul fichier HTML

Vous l’aviez publié sur Show GN, puis aussi sur Hacker News, et vous avez reçu beaucoup de votes. Félicitations !

[GN⁺]

Commentaires sur Hacker News

• Une bonne partie du gros du travail est gérée par un attribut HTML simple mais puissant, et il semble étonnamment que peu de développeurs le connaissent
  C’est une fonctionnalité qui existe depuis assez longtemps

  • Cette seule ligne représentait quasiment 90 % de l’implémentation initiale de Writely
    Writely est la startup qui est ensuite devenue Google Docs, et je parle en tant que l’un de ses fondateurs
    Les 90 % restants, c’était le code backend qu’il fallait écrire pour synchroniser correctement les modifications, parce que chaque navigateur avait ses propres bugs bizarres d’implémentation de contenteditable :-)
  • Vraiment impressionnant. Vers 2016, je créais encore beaucoup de sites sur mesure pour des PME, et je me suis rendu compte que la plupart pouvaient être faits avec quelque chose comme WP
    Sauf que (1) le styling de WP était trop pénible et je ne voulais pas en assurer la maintenance, (2) je ne voulais pas dépendre des fonctionnalités de plugins ni des mises à niveau de WP, et (3) je voulais permettre à des personnes avec des droits d’accès différents de modifier différentes parties d’une même page, ce qui était pratiquement impossible dans la plupart des CMS
    J’ai donc construit un CMS quasiment à partir de zéro, basé seulement sur contenteditable et TinyMCE, et j’ai ajouté cette balise aux zones éditables. Bien sûr, avant l’enregistrement, le backend vérifie qui a le droit de modifier quoi
    Quand un client ou un employé se connecte, il peut modifier directement uniquement les zones de page auxquelles il a droit, et le CMS affiche une bordure en pointillés autour des parties modifiables. Les polices et les couleurs sont enregistrées dans la configuration de TinyMCE, donc pas besoin de fouiller dans le HTML ni d’y toucher. On peut aussi le faire directement si on veut
    Pour les clients, cela donne une impression assez magique. Ils n’ont pas besoin d’aller sur une page d’édition séparée pour voir le résultat des changements : ils modifient sur place dans la page, enregistrent, et c’est publié immédiatement
    La plupart de ces sites sont encore en ligne 5 à 10 ans plus tard, avec presque aucune maintenance de mon côté
  • J’ai créé une démo live de ce concept il y a quelques semaines. Pour une fonction cachée de HTML, c’est vraiment simple et puissant
    https://news.ycombinator.com/item?id=43179649
  • C’est sympa. Il y a longtemps, j’avais créé un éditeur de PDF en convertissant des documents en HTML puis en ajoutant contenteditable="true" au div de plus haut niveau
  • Ça se lit un peu comme « oh, il y a un truc incroyable ici, ça s’appelle la roue et ça existe depuis assez longtemps »
    Il me semble avoir travaillé avec ça il y a 20 ans
    ContentEditable a été introduit pour la première fois dans IE 5.5 en 2000, et en 2007 il était utilisable dans tous les grands navigateurs

• J’aime beaucoup, et en regardant le source, j’apprécie encore plus que ce soit écrit en JavaScript pur
  On sous-estime aujourd’hui à quel point on peut créer des web apps assez interactives sans bibliothèques ni frameworks
  L’idée de faire une web app locale simple sous forme de page HTML unique est aussi excellente. Un jour, j’étais allé dans un musée des sciences avec mon enfant, on avait essayé un petit animateur stop motion, puis j’ai créé une web app similaire et l’ai copiée sur son ordinateur portable sous forme d’un seul fichier HTML, utilisable sans Internet
  Cela dit, comme je n’avais pas envie d’écrire directement du JavaScript pur, je l’ai faite avec React et un bundler, et le résultat est empaqueté dans un seul fichier HTML. Je la posterai peut-être un jour sur Show HN

  • Comme il y avait autrefois « pas besoin de jQuery pour faire ça », il nous faut maintenant « pas besoin de React, Vue, Svelte ou autre pour faire ça »
    Avec du JavaScript pur ordinaire et un bon niveau, on peut faire presque tout de manière plus propre et plus maintenable
    Après des décennies à maintenir le code écrit par d’autres, je constate qu’une conception stupidement simple faite par quelqu’un d’intelligent bat les autres combinaisons
  • C’est ce que j’aime avec Quarto. On peut créer un fichier HTML autonome et le partager avec d’autres

• Bien fait
  Cela vaudrait aussi la peine d’envisager de changer le comportement pour que, lorsqu’on ouvre la page dans le navigateur depuis le disque local, elle passe automatiquement en mode édition, tandis que lorsqu’elle est publiée sur le site web de quelqu’un et accessible sur le Web public, elle devienne une vue en lecture seule normale. Il suffit de vérifier si l’adresse est en http/https
  Bien sûr, il faudrait prévoir un contournement, comme un paramètre de chaîne de requête ou un fragment d’URL magique, pour pouvoir quand même l’afficher en mode édition
  Il faudrait aussi pouvoir prévoir des exceptions pour certains domaines ou préfixes d’URL. En définissant par défaut keepworking.github.io ou <https://keepworking.github.io/nash/>, le mode édition serait aussi activé sur ce site, ce qui évite d’avoir quoi que ce soit de spécial à faire pour la démo
  Ce serait encore mieux si ces exceptions étaient modifiables par l’utilisateur. Par exemple, d’autres pourraient obtenir le même comportement sans l’astuce du point 1

  • J’aime vraiment l’idée d’un site web dont on peut modifier le contenu et l’enregistrer en local
    Personnellement, je trouve ça excellent et j’aimerais que cela reste tel quel

• Avec https://rpdillon.net/redbean-tiddlywiki-saver.html, on peut en faire une application portable autosuffisante avec une « vraie » sauvegarde

  • J’avais fait quelque chose de similaire auparavant, visible sur https://original.littr.me
  • Ce serait bien de faire en sorte qu’il propose d’enregistrer le fichier
    On se rapprocherait ainsi beaucoup plus d’une fonctionnalité permettant d’avoir des marque-pages personnels quand on le souhaite

• Sympa. Il y avait déjà eu une discussion précédente mentionnant cette idée et TiddlyWiki
  https://news.ycombinator.com/item?id=43179649

  • L’un de mes favoris dans ce domaine est Feather Wiki : https://feather.wiki/

• J’aimerais que les navigateurs prennent mieux en charge les web apps locales
  Si les fichiers locaux pouvaient accéder facilement à un stockage persistant, cela ouvrirait beaucoup de possibilités pour des applications GUI rapides et simples. Ce serait en fait l’inverse d’Electron

  • Comment un fichier pourrait-il accéder à quoi que ce soit ? Un fichier n’est que des données, il ne peut rien faire

• Super. Je suis sans doute tellement habitué à écrire la partie JavaScript d’un site web en dehors du HTML proprement dit que, la première fois que j’ai vu ça, je me suis dit : « Waouh, c’est fou qu’on puisse faire ça uniquement avec du HTML »
  Mais en regardant le source, j’ai vu que le JavaScript était dans une balise script tout à fait ordinaire, et ça m’a rappelé qu’on peut effectivement faire comme ça

  • HTML est sous-estimé
    La plupart des écrans que nous voyons tous les jours, même les éditeurs de code, sont des pages HTML
  • Ce n’est pas forcément la méthode à adopter si l’on veut de la séparation ou du versioning. Mais c’est clairement possible
    Ce qui est encore plus étonnant, c’est que des gens utilisent des frameworks en mettant dans le HTML des choses qui ne sont même pas du JavaScript, avec une structure où du JavaScript externe vient se greffer plus tard ou doit faire de l’hydratation. On a l’impression que ça combine le pire des deux mondes
    Je suis plutôt à l’opposé : JavaScript est au centre, et à part index.html, je n’ai aucun fichier avec l’extension .html. Je ne mets pas non plus de HTML dans le JavaScript. Les templates partiels sont tous en .htm et sont hydratés avant d’être ajoutés au DOM

• Ce serait bien d’avoir un avertissement quand on essaie de fermer la page après avoir modifié quelque chose sans l’enregistrer
  Ça vaudrait le coup d’envisager l’ajout d’un gestionnaire onbeforeunload

  • Cette page web affiche déjà un avertissement à la fermeture, mais c’est une bonne suggestion en général

• J’aime ce genre d’outil simple. Il y a quelque temps, j’ai créé une petite « page d’accueil »/tableau de bord personnalisé : https://github.com/rcarmo/onepage-by-spec

  • Je viens de le mettre à jour pour qu’il puisse aussi « enregistrer »

• Vraiment bien. C’est frustrant de voir de plus en plus de logiciels cacher derrière un abonnement des fonctionnalités faciles à exécuter localement, et qui l’étaient déjà, tout en imposant des limitations artificielles
  Je développe un éditeur Markdown gratuit qui fonctionne uniquement dans le navigateur et permet de modifier des fichiers locaux via la nouvelle File System Access API. Cette API n’est disponible que dans les navigateurs basés sur Chromium
  https://zareith.github.io/chillmd/