Show HN: Nash - Eigenständige Notizen aus einer einzigen HTML-Datei

 (keepworking.github.io)
3 Punkte von GN⁺ 2025-03-16 | 2 Kommentare | Auf WhatsApp teilen
  • Nash ist eine HTML-basierte eigenständige Notiz, die ohne separaten Dienst direkt im Webbrowser geöffnet und bearbeitet werden kann
  • Gespeicherte Notizen lassen sich auch offline bearbeiten; das Ziel ist ein Umgang wie mit einer Dokumentdatei statt mit Notion oder Word
  • Es kann zur Erstellung von HTML-dokumentartigem Content genutzt werden, etwa für statische Blogs, Single-Page-Content oder zum Anhängen von Pizzafotos aus der Galerie
  • Wird es per Messenger verschickt, kann es als Vorschau angesehen werden, sodass sich auch längere Inhalte wie Dateien teilen lassen
  • Nash ist als Open Source veröffentlicht, und die leere Notizseite kann frei angepasst und verwendet werden

HTML-Notizen nur mit dem Browser

  • Nash ist eine eigenständige Notiz mit dem Ansatz note as HTML
  • Es benötigt keine zusätzliche Software oder Dienste; ein gewöhnlicher Webbrowser, der normalerweise bereits installiert ist, genügt
  • Gespeicherte Notizen unterstützen Offline-Bearbeitung
  • Eine leere Notiz kann unter nash.html geöffnet werden

Mögliche Inhalte und Freigabe

  • Es kann zur Erstellung statischer Blogs oder von Single-Page-Content verwendet werden
  • Auch das Verfassen von Inhalten durch Anhängen von Fotos aus der Galerie ist möglich
  • Wird es per Messenger versendet, lässt es sich als Vorschau ansehen und kann zum Teilen längerer Inhalte genutzt werden
  • Es entstand aus der Erfahrung, einfache Ideen als POC mit einer einzelnen HTML-Datei umzusetzen, und ist ein erster Versuch, eine Dokumentdatei zu schaffen, die ohne separate Dienste oder Software funktioniert
  • Nash ist als Open Source veröffentlicht und kann frei angepasst und verwendet werden

Verwandte Beiträge

2 Kommentare

 
xguru 2025-03-16

Nash, eine Notiz-App, die als einzelne HTML-Datei läuft

Sie hatten das bereits bei Show GN gepostet und nun auch bei Hacker News eingestellt – und haben viele Upvotes bekommen. Herzlichen Glückwunsch!
 
GN⁺ 2025-03-16
Hacker-News-Kommentare

  • Ein erheblicher Teil der schweren Arbeit wird von einem einfachen, aber mächtigen HTML-Attribut erledigt, das überraschend viele Entwickler anscheinend nicht kennen.
    Diese Funktion gibt es schon ziemlich lange.

    • Diese eine Zeile machte fast 90 % der frühen Implementierung von Writely aus.
      Writely war das Startup, aus dem später Google Docs wurde; ich sage das als einer der Gründer.
      Die restlichen 90 % waren Backend-Code, den wir schreiben mussten, um die Bearbeitungen korrekt zu synchronisieren, weil jeder Browser andere merkwürdige Implementierungsfehler bei contenteditable hatte :-)
    • Wirklich beeindruckend. Um 2016 herum habe ich noch viele maßgeschneiderte Websites für kleine und mittlere Unternehmen gebaut und gemerkt, dass das meiste davon mit etwas wie WP möglich wäre.
      Allerdings (1) war das Styling in WP zu lästig, und ich wollte es nicht warten, (2) wollte ich mich nicht auf Plugin-Funktionen und WP-Upgrades verlassen, und (3) wollte ich, dass Personen mit unterschiedlichen Zugriffsrechten verschiedene Bereiche derselben Seite bearbeiten können, was in den meisten CMS praktisch unmöglich war.
      Also habe ich ein CMS fast von Grund auf nur auf Basis von contenteditable und TinyMCE gebaut und die entsprechenden Tags an die bearbeitbaren Bereiche gehängt. Natürlich prüft das Backend vor dem Speichern, wer was bearbeiten darf.
      Wenn sich ein Kunde oder Mitarbeiter einloggt, kann er direkt nur die Seitenbereiche bearbeiten, für die er berechtigt ist, und das CMS zeigt bearbeitbare Teile mit einem gestrichelten Rahmen an. Fonts und Farben sind in den TinyMCE-Einstellungen hinterlegt, sodass man nicht im HTML suchen oder daran herumfummeln muss. Wer möchte, kann es aber auch direkt anfassen.
      Für Kunden wirkt das ziemlich magisch: Sie müssen nicht auf eine separate Bearbeitungsseite wechseln, um zu sehen, wie Änderungen aussehen, sondern bearbeiten direkt an Ort und Stelle auf der Seite, speichern – und es ist sofort veröffentlicht.
      Die meisten dieser Websites laufen auch heute, 5 bis 10 Jahre später, noch, und auf meiner Seite ist kaum Wartung nötig.
    • Vor ein paar Wochen habe ich eine Live-Demo dieses Konzepts gebaut. Für eine versteckte Funktion von HTML ist sie wirklich simpel und mächtig.
      https://news.ycombinator.com/item?id=43179649
    • Gefällt mir. Ich habe früher einmal einen PDF-Editor gebaut, indem ich ein Dokument nach HTML konvertiert und dann contenteditable="true" in das oberste div gesetzt habe.
    • Liest sich wie: „Oh, hier ist etwas Großartiges, es heißt Rad und existiert schon ziemlich lange.“
      Ich glaube, ich habe schon vor 20 Jahren damit gearbeitet.
      ContentEditable wurde erstmals 2000 in IE 5.5 eingeführt und war 2007 in allen großen Browsern nutzbar.

  • Gefällt mir sehr, und nach einem Blick in den Source ist es noch besser, weil es in reinem JavaScript geschrieben wird.
    Es wird unterschätzt, dass man heutzutage auch ohne Libraries oder Frameworks ziemlich interaktive Web-Apps bauen kann.
    Die Idee, eine einfache lokale Web-App als einzelne HTML-Seite zu bauen, ist ebenfalls wirklich gut. Ich war früher mit meinem Kind in einem Wissenschaftsmuseum, dort haben wir einen einfachen Stop-Motion-Animator ausprobiert; ich habe eine ähnliche Web-App gebaut und als einzelne HTML-Datei auf den Laptop meines Kindes kopiert, sodass sie auch ohne Internet nutzbar war.
    Allerdings war ich zu faul, reines JavaScript direkt zu schreiben, also habe ich sie mit React und einem Bundler gebaut; das Ergebnis wird in eine einzelne HTML-Datei gepackt. Vielleicht stelle ich sie irgendwann als Show HN vor.

    • So wie es früher „Dafür brauchst du kein jQuery“ gab, braucht es jetzt „Dafür brauchst du kein React oder Vue, Svelte und Ähnliches“.
      Mit normalem Vanilla JavaScript und ordentlichem Können lässt sich fast alles sauberer und wartbarer bauen.
      Nachdem ich jahrzehntelang Dinge anderer Leute gewartet habe, schlägt ein fast schon idiotisch einfaches Design von klugen Leuten die anderen Kombinationen.
    • Das mag ich an Quarto: Man kann eigenständige HTML-Dateien erzeugen und mit anderen teilen.

  • Gut gemacht.
    Man könnte auch überlegen, das Verhalten so zu ändern, dass die Seite automatisch in den Bearbeitungsmodus geht, wenn man sie im Browser von der lokalen Festplatte öffnet, und zu einer normalen schreibgeschützten Ansicht wird, wenn sie auf einer Website veröffentlicht und im öffentlichen Web erreichbar ist. Dazu reicht es, zu prüfen, ob die Adresse http/https ist.
    Natürlich sollte es einen Umweg geben, um sie trotzdem im Bearbeitungsmodus anzeigen zu können, etwa über einen Query-String-Parameter oder ein Magic-URL-Fragment.
    Außerdem sollte man Ausnahmen für bestimmte Domains oder URL-Präfixe definieren können. Wenn der Standard keepworking.github.io oder <https://keepworking.github.io/nash/> wäre und dort der Bearbeitungsmodus ebenfalls aktiv bliebe, müsste man für die Demo nichts extra tun.
    Noch besser wäre es, wenn diese Ausnahme vom Nutzer bearbeitbar wäre. Dann könnten zum Beispiel auch andere ohne den Trick aus Punkt 1 dasselbe Verhalten bekommen.

    • Die Idee einer Website, deren Inhalte man bearbeiten und lokal speichern kann, gefällt mir wirklich.
      Persönlich finde ich sie großartig und hoffe, dass es so bleibt, wie es jetzt ist.

  • Mit https://rpdillon.net/redbean-tiddlywiki-saver.html kann man daraus eine in sich geschlossene portable App machen, die „wirklich“ speichert.

    • Ich habe früher etwas Ähnliches gebaut; man kann es unter https://original.littr.me sehen.
    • Es wäre gut, wenn sie das Speichern einer Datei anbieten würde.
      Dann käme sie der Funktion, bei Bedarf persönliche Bookmarks zu haben, deutlich näher.

  • Schön. Es gab eine frühere Diskussion, in der diese Idee und TiddlyWiki erwähnt wurden.
    https://news.ycombinator.com/item?id=43179649

  • Ich wünschte, Browser würden lokale Web-Apps besser unterstützen.
    Wenn lokale Dateien leicht auf persistenten Speicher zugreifen könnten, würde das viele Möglichkeiten für schnelle, einfache GUI-Apps eröffnen. Im Grunde die Gegenrichtung zu Electron.

    • Wie kann eine Datei auf irgendetwas zugreifen? Eine Datei ist einfach nur Daten und kann gar nichts tun.

  • Cool. Vielleicht bin ich einfach zu sehr daran gewöhnt, den JavaScript-Teil einer Website außerhalb des eigentlichen HTML zu schreiben, aber als ich es zum ersten Mal sah, dachte ich: „Wow, erstaunlich, dass man das nur mit HTML machen kann.“
    Als ich mir dann den Source ansah, steckte JavaScript in einem ganz normalen script-Tag, und ich erinnerte mich wieder daran, dass das eben auch geht.

    • HTML wird unterschätzt.
      Der Großteil der Oberflächen, die wir jeden Tag sehen, sogar Code-Editoren, sind HTML-Seiten.
    • Wenn man Trennbarkeit oder Versionsverwaltung will, ist das nicht unbedingt der Weg, den man gehen muss. Aber es ist definitiv ein Weg, der möglich ist.
      Noch erstaunlicher ist, dass Leute Frameworks verwenden, dabei Dinge in HTML packen, die nicht einmal JavaScript sind, und Strukturen nutzen, bei denen externes JavaScript später angehängt oder hydriert werden muss. Das fühlt sich an wie die schlechten Seiten beider Ansätze zusammen.
      Ich bin eher am anderen Ende: JavaScript steht im Mittelpunkt, und außer index.html habe ich keine Dateien mit der Endung .html. Auch in JavaScript bette ich kein HTML ein. Alle Partial-Templates sind .htm und werden hydriert, bevor sie dem DOM hinzugefügt werden.

  • Es wäre gut, wenn beim Schließen der Seite nach einer Bearbeitung ohne Speichern eine Warnung erscheint.
    Man könnte in Erwägung ziehen, einen onbeforeunload-Handler hinzuzufügen.

    • Diese Webseite zeigt beim Schließen zwar bereits eine Warnung, aber allgemein ist das ein guter Vorschlag.

  • Ich mag solche einfachen Tools. Vor Kurzem habe ich eine einfache, angepasste „Homepage“/ein Dashboard gebaut: https://github.com/rcarmo/onepage-by-spec

    • Habe es gerade aktualisiert, sodass auch „Speichern“ möglich ist.

  • Wirklich gut. Es ist frustrierend, wie viel Software inzwischen Funktionen, die sich leicht lokal ausführen lassen und das früher auch taten, hinter Abos versteckt und künstliche Einschränkungen einführt.
    Ich baue einen kostenlosen Markdown-Editor, der nur im Browser läuft und über die neue File System Access API lokale Dateien bearbeiten kann. Diese API ist nur in Chromium-basierten Browsern verfügbar.
    https://zareith.github.io/chillmd/