- Zielt auf eine Dokumentsprache, die Dokumentstrukturen für den Browser verständlich macht und sie über die Grenzen von PDF und statischen Webseiten hinaus für Leser direkt nutzbar werden lässt
- Nota-Dokumente werden zu JavaScript-Programmen kompiliert und im Browser ausgeführt; beim Schreiben von Dokumenten können Variablen, Funktionen und Datenstrukturen verwendet werden
- Entwickelt mit Blick auf die Integration von JavaScript-Bibliotheken wie KaTeX, Vega-Lite und Penrose sowie die Unterstützung von Accessibility-Anforderungen
- Mit dem Paket
@nota-lang/notalässt sich die ausführbare Dateinotainstallieren, und Dokumente können in Build- oder interaktiven Bearbeitungs-Workflows verarbeitet werden - Da es sich noch um eine neue und im Wandel befindliche Technologie handelt, können sich Architektur und API ändern; mit Bugs, Lücken und Ungenauigkeiten in Tools und Dokumentation ist zu rechnen
Dokumentstruktur, die der Browser versteht
- Nota ist eine Sprache zum Schreiben von Dokumenten wie wissenschaftlichen Arbeiten und Blogposts
- Ziel ist es, Dokumente in ein Medium des 21. Jahrhunderts zu überführen
- In Dokumenten gibt es viel Struktur, der Leser folgen muss, etwa Definitionen von Begriffen und Verweise
- Als Beispiel verweist das Wort
Notaauf einen im vorherigen Absatz definierten Begriff - Nota ermöglicht es Autoren, solche Strukturen auszudrücken, und der Browser versteht sie, sodass Leser sie nutzen können
- Auf der Beispielseite kann man auf den Verweis
Notaklicken oder doppelklicken, um das Verhalten zu sehen
- Als Beispiel verweist das Wort
- Nota-Dokumente werden zu JavaScript-Programmen kompiliert
- Dokumente können auf jedem Gerät mit Webbrowser angezeigt werden
- Variablen, Funktionen und Datenstrukturen können genutzt werden, um das Schreiben von Dokumenten zu vereinfachen
- Integration mit JavaScript-Bibliotheken wie KaTeX, Vega-Lite, Penrose ist möglich
- Accessibility-Anforderungen wie Screenreader lassen sich leicht unterstützen
Installation und Bearbeitungs-Workflow
- Nota kann verwendet werden, indem die ausführbare Datei
notaüber das Paket@nota-lang/notainstalliert wird- Voraussetzungen sind NodeJS ≥ 16 und npm ≥ 6
- Das globale Binärverzeichnis von NodeJS muss im
PATHder Shell liegen
- Ein einzelnes Nota-Dokument kann mit folgendem Ablauf gebaut werden
npm install --global @nota-lang/notaecho "@Title: Hello world" > index.notanota build index.notaopen dist/index.html
- Nota-Dateien können mit dem Befehl
nota edit index.notainteraktiv bearbeitet werden - Wie man Dokumente schreibt, steht in der Reference
- Wer Nota zu einer Website hinzufügen oder die Architektur ansehen möchte, sollte den Integration guide konsultieren
Die Lücke zwischen PDF und statischem Web
- Die wichtigsten Medien für digitale Dokumente teilen sich in PDF und Webseiten auf
- PDFs sind so entworfen, dass sie physische Dokumente abbilden, und übernehmen daher Beschränkungen von Papier wie Seitenumbrüche, feste Breite und unveränderliche Stile
- Webseiten ermöglichen dynamische Formatierung wie Größenanpassung für Smartphones, Übersetzung in andere Sprachen oder Farbänderungen für Nutzer mit Farbsehschwäche
- Webseiten ermöglichen auch dynamische Interaktionen wie Text, der mehr Kontext anfordert, Diagramme mit wechselnder Perspektive oder Anmerkungen für später
- Solche dynamischen Funktionen sind derzeit vor allem professionellen Webentwicklern zugänglich
- Bestehende Dokumentwerkzeuge wie LaTeX, Pandoc, Markdown und Scribble können meist nur statische Webseiten erzeugen
- Nota will diese Lücke mit einer Dokumentsprache verringern, die eine niedrige Einstiegshürde, hohe Erweiterbarkeit und eine sanfte Lernkurve bietet
Aktueller Stand und Referenzmaterial
- Nota ist noch eine neue und sich weiterentwickelnde Technologie
- Architektur und API ändern sich fortlaufend
- Die Tools können Bugs und fehlende Funktionen haben
- Die Dokumentation kann unvollständig oder ungenau sein
- Derzeit werden Early Adopters gesucht, die daran mitwirken wollen, Nota zu einer Dokumentsprache der Zukunft zu machen
- Die Komponenten
@Definitionund@Referlauben es dem Autor, mit einer kleinen Menge an Dokumentannotationen dem Nota-Runtime zu ermöglichen, die Definition eines Verweises als Tooltip im Kontext anzuzeigen- Künftige Versionen von Nota könnten Funktionen enthalten wie das Finden aller Verweise auf eine bestimmte Definition
- Mehr zur Designphilosophie steht in A New Medium for Communicating Research on Programming Languages
1 Kommentare
Meinungen auf Hacker News
Ich bin der Entwickler von Nota und überarbeite seit dem ersten Prototyp der Webseite das Design weiter
Ich arbeite an einer solideren Grundlage für Fragen wie wie man Inhalte und Berechnungen miteinander kombiniert (https://arxiv.org/abs/2310.04368) und wie Syntax die Arbeit an Dokumenten erleichtert/erschwert/unmöglich macht (https://github.com/cognitive-engineering-lab/doclang-benchma...)
An die große Philosophie glaube ich weiterhin, aber Nota wird in etwa 6 Monaten ziemlich anders aussehen. Die spannendste Entwicklung im Bereich Dokumentensprachen ist meiner Ansicht nach derzeit Typst; schaut es euch an: https://typst.app/
Die nächste Version von Nota wird zu 99 % in Rust geschrieben sein :-)
Wenn Performance wirklich das Problem ist, ergibt Rust mehr Sinn als JavaScript, aber ich bin mir nicht sicher, ob das für die meisten Anwendungsfälle entscheidend ist
LaTeX habe ich nie gemocht, obwohl ich viele große Dokumente damit geschrieben habe; es war eher ein akademisches Monster, nichts für Business-Anwendungen. Auch in Word waren Dinge, die man konsistent machen wollte, nicht immer einfach; Styles geraten schnell durcheinander, und Nummerierungen sowie Aufzählungen sind anfällig für schleichende Fehler
Wenn mehrere Überarbeitungsrunden hin und her gehen, wird Änderungsverfolgung zu einem großen Problem, und am Ende verlässt man sich darauf, dass die Gegenseite die Nachverfolgung nicht überschreibt. Schon ein Produkt, das garantiert, dass jede Änderung vom ersten Entwurf bis zur finalen Freigabe korrekt sichtbar bleibt, könnte eine Killer-App sein, die Unternehmen und Anwälte lieben würden
Wenn man noch Blockchain darüberstreut, ließe sich vielleicht leichter Investment einsammeln, aber eigentlich wirkt es eher wie ein grundlegendes Kryptografieproblem als wie ein Blockchain-Thema, und diese Komplexität scheint nicht nötig zu sein
Das Wichtigste an einer Dokumentsprache ist, diese beiden Dinge zu priorisieren. Ein TeX-Dokument beginnt zum Beispiel mit vorbereitendem Code wie
\documentclass, mehreren\usepackage, Theorem-Definitionen und Font-Einstellungen, während ein R-Markdown-/Quarto-Dokument direkt mit der tatsächlichen Bedeutung des Textes beginnt, etwa Titel, Autor und AbstractDer Unterschied in der Schwerpunktsetzung ist klar zu erkennen
Dazu gehören dichte, informationsreiche Layouts wie A0-Konferenzposter, Dokumentstile nach nationalen Standards wie GOST im postsowjetischen Raum, die explosionsartig wachsenden Anforderungen an Literaturverzeichnisstile je nach internationaler Tradition, etwas so aussehen zu lassen wie die Standard-Styles einer bestimmten MS-Word-Version, das präzise Platzieren von Bildern oder Text über Abbildungen für schnelle Korrekturen in Papers und die bewusste Anpassung solcher Dinge
In der TeX-Welt ist all das technisch möglich, erfordert in der Praxis aber so tiefe Schwarzmagie, dass selbst normale Nutzer mit Abschluss sich damit nicht befassen möchten
In den letzten Monaten habe ich es mit Spaß genutzt, um Ideen für SVG-Animationen (https://simpatico.io/svg) zu erkunden oder neue Datenstrukturen/Algorithmen (https://simpatico.io/stree3) auszuarbeiten
Der gesamte Server und der Markdown-Prozessor bestehen aus etwa 500 Zeilen gut lesbarem Node-Code, haben sehr wenige Abhängigkeiten, keine transitiven Abhängigkeiten und benötigen keinen Kompilierungsschritt. Standardmäßig erlaubt der Server keinerlei Drittanbieter-Ressourcen oder Cookies
Das Ganze steht unter MIT-Lizenz auf GitHub, und ich bin gerade dabei, es beim Umzug von einem persönlichen Repository in ein Organisations-Repository aufzuräumen. Siehe: https://simpatico.io/lit
Wo keine „unverzichtbare Dynamik“ nötig ist, ist ihr Fehlen meiner Ansicht nach eher ein Feature als ein Bug
Auf Mobilgeräten lese ich Webpages deutlich lieber als PDFs, weil sich eine vernünftige Webpage normalerweise an den mobilen Bildschirm anpassen kann
Wir brauchen ein Format, das visuelle Informationen und digitale Informationen gemeinsam kodiert. Die digitale Ebene muss standardmäßig nicht sichtbar sein, sollte aber bei Bedarf zugänglich sein
Natürlich wurden solche „Features“ in der ISO-Spezifikation PDF/A für die Langzeitarchivierung als Bugs betrachtet und entfernt: https://en.wikipedia.org/wiki/PDF/A
Der Punkt ist: Manchmal sollte ein Dokument einfach ein Dokument sein. Bei wissenschaftlichen Arbeiten ist LaTeX etwas, das Menschen für Menschen schreiben; dank eigener Befehle und Pakete kann man Klartextdokumente erstellen, die genauso lesbar sind wie die daraus erzeugten Papers. Auch in Sachen Barrierefreiheit ist das gut
Bei dynamischen Dokumenten gibt es ein spannendes, noch wenig erschlossenes Feld, aber es braucht gute Beispiele dafür, wie man es stilvoll einsetzt
Kurz gesagt: Es ist näher an LaTeX, enthält auch einige Markdown-Elemente, ist in JavaScript geschrieben, sodass viele Leute in einer Sprache beitragen können, die sie bereits kennen, und die MIT-Lizenz ist ebenfalls positiv
Ich weiß nicht, ob ich es sofort brauchen werde, aber es sieht ziemlich cool aus. Wenn ich etwas schreiben würde, das LaTeX-artige Funktionen braucht, die Einreichungsstelle aber kein LaTeX erzwingt, würde ich Nota wohl ausprobieren
Ich halte Knuth zwar fast für eine halbgöttliche Figur, aber er ist nicht vom Himmel herabgestiegen, hat uns TeX überreicht und gesagt: „Probiert niemals wieder etwas Neues aus“
Außerdem fehlen zu viele Fehlerschutzmechanismen und Komfortfunktionen, die moderne Sprachen bieten. Wenn ich LaTeX nutze, bin ich stark auf
\input{}-Fragmente angewiesen, um Blöcke zu isolieren und zu vermeiden, dass alles wegen eines einzigen fehlenden Escapes kaputtgehtIch hoffe weiterhin auf eine moderne Neuinterpretation, aber durch Jahrzehnte an Trägheit und Paketen rund um TeX fühlt es sich an, als säßen wir in einem lokalen Optimum fest, aus dem man nur schwer herauskommt
Ähnliche Dinge sind https://pandoc.org/, https://quarto.org/, https://markdoc.dev/, https://mdxjs.com/, https://typst.app/
Das Problem bei neuen Ansätzen in diesem Bereich ist, dass sie in ein ohnehin schon überfülltes Feld eintreten. Ob bestehende Lösungen unvollkommen sind, spielt dabei kaum eine Rolle
Es ist ein bisschen so, als würde man in eine europäische Altstadt mit tausend Jahren Baugeschichte kommen und behaupten, man habe einen großartigen Entwurf für ein neues Gebäude. Freie Grundstücke sind selten, und die Leute reißen alte Strukturen nicht einfach ab, nur um etwas Neues auszuprobieren. Sie müssen einen überwältigenden Vorteil erkennen
In der Architektur haben Stahl und Stahlbeton die vertikale Dimension eröffnet, die Raumnutzung massiv verbessert, und danach änderte sich die Geschichte
Die entscheidende Frage ist, ob es eine unerschlossene Dimension gibt, die Menschen zu einem weiteren Dokumentformat hinziehen kann, das ASCII, reStructuredText, wikitext, Markdown, TeX/LaTeX, AsciiDoc, HTML usw. „verbessern“ will
Die übliche Antwort ist eine semantische Hypertext-Infrastruktur. Die ursprüngliche Vision ist noch nicht verwirklicht. Wenn man annimmt, dass die heutigen geschlossenen Ökosysteme ein vorübergehender Albtraum sind, braucht ein wieder dezentralisiertes Web eine moderne, nutzerfreundliche und befähigende Infrastruktur zum Schreiben von Dokumenten
Es könnte aber auch andere Dimensionen geben, die das Erstellen und Teilen von Dokumenten auf ein neues Niveau heben. Die Schönheit von Innovation liegt darin, nicht an bestehende Regeln und Weisheiten gebunden zu sein
Man braucht ein effizientes Dokumentformat, und dafür muss es ein Format sein, das nicht versucht, alles zu machen. Das heißt, Tabellen sollten wie bei standardisierten Tabellenkalkulationsformaten Dokumenttypen nach Dateien trennen; anders als HTML, das Tabellen, Grafiken (SVG) und Ähnliches selbst übernehmen will
Wenn man alles in separate Dateien aufteilt, können Nutzer zum Betrachten oder Bearbeiten von Dokumenten das gewünschte Programm wählen, statt alles in einem Browser ansehen zu müssen; außerdem hilft es bei der Verteilung im Netzwerk und ist auch in Umgebungen mit wenig Speicherplatz oder Bandbreite vorteilhaft
Aus meiner Sicht muss daher nichts neu erfunden werden. Man sollte das bereits Erfundenen spezialisieren und verfeinern
Wenn man dem Link folgt, zeigt https://willcrichton.net/nota/ überzeugende Vorteile in der Nische, für die Nota gedacht ist: wissenschaftliche Arbeiten über Programmiersprachen verständlicher zu machen.
Ob es in hochwertiges PDF gerendert werden kann, ist natürlich eine notwendige Frage. Für die Kompatibilität mit bestehenden Systemen wäre es vielleicht sogar besser, nach LaTeX zu rendern.
Im Grunde ist Nota Markup + Code (JavaScript), und diese Kombination ist genau der Bereich, auf den MDX abzielt. Als das früher schon einmal jemand ansprach, sagte der Ersteller, Nota sei auf Dokumentation ausgerichtet, MDX auf Websites: https://news.ycombinator.com/item?id=31349579
Wenn das so ist, glaube ich, dass jemand Nota als Produkt verpacken müsste, damit es sich durchsetzt. Das Ergebnis sieht gut aus, aber Node.js anfassen zu müssen, nur um Dokumente zu erstellen, ist viel zu umständlich und fühlt sich wieder wie LaTeX an. Die meisten werden Notion oder eine Textverarbeitung bevorzugen.
Außerdem ist Nota kein direkter Konkurrent der TeX-Familie. Nota erzeugt etwas, das ein Webbrowser liest, xxxTeX erzeugt etwas, das ein PDF-Reader liest. Mir ist klar, dass xxxTeX auch andere Ausgabeformate erzeugen kann, aber die meisten nutzen es zur PDF-Erstellung.
MDX ist darauf vorbereitet, mit beliebigen Frameworks wie React/Vue usw. verwendet zu werden, aber das bedeutet im Grunde, dass es keinerlei eigene Meinung mitbringt.
Nota fühlt sich so an, als könnte man es in einen Static-Site-Generator einstecken. Dafür müsste man die beiden natürlich zur Zusammenarbeit bringen, aber für jemanden, der etwas engagierter ist als ich, halte ich das für eine erreichbare Erwartung.
Ich verstehe nicht, warum man eine Sprache braucht, die nach JavaScript kompiliert, nur um Textseiten zu erstellen. Dasselbe Ziel deckt AsciiDoc ab.
Auch echte Verlage wie O’Reilly verwenden AsciiDoc als Eingabeformat, um Bücher und Websites zu erstellen.
Ich nutze AsciiDoc seit einigen Jahren und mag es. Nur dort, wo AsciiDoc noch nicht unterstützt wird, gehe ich zu Markdown zurück. GitHub und GitLab unterstützen zum Beispiel das Rendern von AsciiDoc.
PyPI unterstützt es leider noch nicht, aber es ist schön zu sehen, dass offenbar mehr Leute einen Blick darauf werfen: https://github.com/pypa/readme_renderer/issues/205
Allerdings frustrieren mich die aktuellen Tools. Man sieht und schätzt, wie viel Arbeit in Asciidoctor steckt, aber es gibt keine semantische HTML5-Ausgabe, die Integration mit Bildgeneratoren ist schwierig oder zumindest schwieriger als nötig, und es ist so schwergewichtig, dass es die einzige Ruby-Abhängigkeit auf meinem ganzen Rechner ist.
Abgesehen vom Ruby-Problem sind diese Issues auf GitHub offen, daher denke ich, dass sie mit mehr Zeit und Ressourcen gelöst werden können.
Ich bin mir nicht sicher. Emacs org-mode wirkt besser und scheint weniger von JavaScript abhängig zu sein.
https://docusaurus.io/ ist ebenfalls sehr gut und flexibel. Wenn Nota auf ähnliche Weise erweitert werden soll, würde ich empfehlen, sich diese beiden anzusehen.
Ich habe gerade darüber nachgedacht, wie man am einfachsten einen Blog baut, der größtenteils statische Inhalte hat, aber bei Bedarf interaktive Grafiken oder beliebige Anpassungen zulässt. Ich frage mich, ob Nota dafür eine gute Wahl ist.
Als andere Option habe ich mir auch Quarto (https://quarto.org/) angesehen, und vielleicht könnte man auch einen einfachen Static-Site-Blog wie Jekyll verwenden und bei Bedarf das ausgegebene HTML direkt bearbeiten.
So kann man den gesamten HTML-Umfang nutzen, den Generierungsprozess anpassen, Abhängigkeiten relativ leicht verwalten, und die zugehörigen Formate sind standardisiert.
Bei Astro schreibt man Komponenten im React-Stil, und es kompiliert sie zu reinem HTML/CSS, außer in den Fällen, in denen tatsächlich JavaScript gebraucht wird. Meine persönliche Website und mein Blog sind ebenfalls mit Astro gebaut: https://sjer.red/, der Quellcode ist unter https://github.com/shepherdjerred/shepherdjerred.com
Es gibt auch ein Tutorial zum Erstellen eines Blogs mit Astro: https://docs.astro.build/en/tutorial/0-introduction/