.. kann von Obsidian (und ähnlichen Strategien) viel lernen
Design-Tooling-Support
Ich arbeite seit 2018 konsequent mit Vue und Nuxt. Ich hatte die Entscheidung damals gründlich getroffen, der Prozess zog sich über ca. 3 Monate, in denen ich vor allem gegen React abgegrenzt hatte.
In den Jahren seitdem habe ich das Vorgehen nie wieder radikal in Frage gestellt. Das hat mir ein gründliches Stück 'Javascript-Framework-Fatigue' erspart. Sicherlich ist die Entscheidung vor 1,5 Jahren, mit Odoo einzusteigen, ein gesundes Stück 'Distanzierung'.
Obwohl mit Pruvious ein unersetzbares Stück Nuxt aufgetaucht ist habe ich in den letzten Wochen Vue und Nuxt in Frage gestellt (als langfristige Solo-Strategie). Ich war eigentlich bereit, in ein Parallel-Arbeiten mit mehreren Front-End-Frameworks einzuwilligen, mit Solutions wie z.B. ShadCN, Astro ist dies auch einfacher als je zuvor.
Seit einem Tag weiß ich nun: Vue hat gewonnen!! Ich bin überzeugt, dass es nach wie vor das richtige Tool ist. Überzeugt haben mich:
Obsidian > Pruvious > Odoo bilden das technische Dreieck, innerhalb dessen die entscheidenden Lösungen zu finden sind, die Theaterpedia besonders machen. Es werden sich typischerweise an allen 3 Ecken Subsysteme bilden, die nicht!! vollständig synchron gehalten werden müssen. Z.B. werden Implementierungen in der Pruvious-Ecke über Fähigkeiten verfügen, die nur teilweise an den anderen Ecken erreichbar sind. Aber einen wichtigen Kern der Pruvious-Fähigkeiten kann Pruvious für das komplette System bereitstellen.
Ist die Drafting- und Learning-Plattform, entwickelt sich zu einem dynamisch mitwachsendem Arbeitsplatz, der für Freelancer schnell eine allumfassende Plattform werden kann.
Über ein Obsidian-Plugin können Static-Websites erzeugt werden, die via iFrame Zugriff auf basale Business-Prozesse von Odoo anbieten können. Es werden 4 verschiedene basale Themes angeboten, die ausreichend sind, um für einen Zeitraum von 6-18 Monaten eine einfache Internet-Präsenz zu starten, Inhalte zu generieren, Feedback zu sammeln und unkompliziert Änderungen vorzunehmen.
In dieser Zeit lernen die Akteure mit Content-Types, Meta-Daten und Classes zu operieren, verwenden Sync-IDs, um Infos von Theaterpedia einzubinden. So wird Obsidian zur Onboarding-Strategie, um sich in einem zweiten Schritt relativ treffsicher in Odoo oder Pruvious zurecht zu finden.
Obsidian bietet unendliche Möglichkeiten der persönlichen Anpassung und On-Desktop-Integration > im Tooling kann dies bedeuten, das ggf. bestehende Obsidian-Plugins adaptiert werden, die in Svelte oä. programmiert sind. Obsidian ordnet via YAML-Props einzelne Markdown-Dateien einem Odoo-Datensatz zu und kann so Änderungen im Odoo-Datensatz mitverfolgen (z.B. Datumsänderungen eines Events) oder auch selber auslösen.
Odoo hält sich typischerweise im Hintergrund und tritt für End-User (Teilnehmer:innen von Theaterpädagogik) nicht direkt in Erscheinung.
Ist die Plattform über die der Webauftritt aller Theaterpedia-Designs realisiert wird. Pruvious wird sowohl für Suchmaschine, Regio als auch Einzelwebsites eingesetzt. Zunächst stellen wir die horizontale Integration (mehrere Webauftritte werden zu einem Portal integriert: Regio + Theaterpedia-Suchmaschine) in den Mittelpunkt, danach die vertikale Integration kompletter Businessmodelle einer einzelnen Domain für die verteilte Bearbeitung mit konsistentem Design (Beispiel: DAS Ei).
Vitepress, NuxtContent könnten im Prinzip sehr gut alle readonly- oder mostly-readonly Präsenzen rendern und als static-websites mit High-Speed ausliefern. Dazu müsste in irgendeiner Form der Content statisch indiziert und aktualisiert werden. Es müsste eine Postgres-2-static-Bridge programmiert werden; wir werden diese Option prüfen, falls Performance-Issues auftauchen. Höchstwahrscheinlich wird es aber gelingen, Pruvious mit Caching, Redis etc. selber zu ähnlichen Leistungen zu bringen und dabei aber deutlich bessere und flexiblere Optionen einer Suchmaschine bereitstellen zu können.
Indem Tailwind via Odoo möglich ist und auch in Obsidian Tailwind-Bezüge hergestellt werden können, ist endlich eine klare Fokussierung auf Vue-Design-Components möglich.
Auch der Rest des Systems ist klar zugeordnet: Odoo-ORM und Odoo-Interfaces/Api, schlichtes HTML als Austauschformat für InnerContent zwischen Odoo-Pruvious-Vitepress und überschaubares Markdown rund um Obsidian. Fast alle Funktions-Bereiche von Theaterpedia haben eine eindeutige Implementierung. Fast durchgängig wird in Typescript implementiert.
Wie können einzelne Funktionsbereiche, Features von Theaterpedia abgesichert weden, falls einzelne OpenSource-Projekte veralten oder im Serverbetrieb plötzlich ausfallen?
falls Tailwind ohne Vue / ohne buildstep eingesetzt werden muss, ist vermutlich AlpineJS + Tailwind die richtige Wahl. HTMX ist sehr opinionated und erfordert massive Servereingriffe. Siehe hier
z.B. Pines-Components mit DaisyUI kombinieren oder in der Alpine-Toolbox suchen.
Überlegungen / Kritik an TW 4 von M:
der Übergang wird noch dauern, aber am Ende musst du "nur" die Konfiguration ändern (CSS-Variablen anstatt JS). Falls du crearis-ui zu ShadCN refaktorisieren möchtest, verwende gleich CSS-Variablen für Farben, manche Abstände und nur Variablen die Sinn machen (die man berechnen kann). Die Ideologie in Version 4 ist, alles mit Variablen zu machen (inkl. Fonts, alle Abstände), und ich finde das ehrlich gesagt Quatsch
vorläufiger Ersatz für noch fehlende Toasts:
Hier ein Toaster den ich cool finde: https://vue-sonner.vercel.app/
Original: https://sonner.emilkowal.ski/
Vanilla: https://sourdough-toast.vercel.app/example
Obsidian hat eine tendenziell doppeldeutige Politik. Einerseits sind sie sehr bemüht, eine gesunde Community zu entwickeln, stellen ihr Produkt für viele kostenfrei zu Verfügung. Andererseits legen sie den Source-Code nicht offen, was in vieler Hinsicht eine Behinderung darstellt. Bei der Lektüre in anderen Projekten (LogSeq und Joplin) ist mir aber aufgefallen, dass die Frage der Lizenzierung offensichtlich kritisch ist (Joplin hat vermutlich von einer offenen OS-Lizenz auf AGPL gewechselt, weil es nichts abbekommen hat von zahlreichen Kommerzialisierungen).
Auch Nuxt-Labs sitzen in diesem Boot zwischen Nuxt-Content und Nuxt-Studio. Irgendwie viele der Akteure, einen Teil des Markdown-Kuchens zu kommerzialisieren.
Ist für Theaterpedia die wichtigste Alternative zu Obsidian > hat nur grobe Ähnlichkeiten zu Obsidian, verfügt aber über Features, die langfristig für Theaterpedia evtl. sogar noch wichtiger sind (z.B. für eine Workshop-Datenbank, für das Publishing von Projekten etc.).
Der Aufwand ist aber deutlich höher, bis mit Zettlr eine ähnlich in den Alltag von Freelancern integrierte Lösung erstellt ist. Dies liegt im Wesentlichen daran, dass Zettlr keine Plugin-Schnittstelle anbietet. Zettlr ist ein reines Publishing-Tool, komplett Pandoc-kompatibles Markdown und vor allem: Ist in Vue3 programmiert!! Es würde wahrscheinlich bedeuten, einen systematischen Fork von Zettlr zu generieren und zu supporten, in den Crearis-Features einprogrammiert werden.
Sehr ähnlich zu Obsidian. Ist aber nicht (mehr) so aktiv, insgesamt vermutlich ein Stück 'technischer' als Obsidian, es wäre vermutlich möglich, hier relativ schnell zumindest für eine Übergangszeit eine Zwischenlösung zu implementieren, die ähnlich funktioniert wie das Setup in Obsidian.
Bleibt abzuwarten, wie die Nuxt-Integrationen sich insgesamt weiterentwickeln (Volta etc.). Im Moment noch zu spezifisch, schwache Integration in Arbeitsabläufe jenseits Github.
Joplin, LogSeq und Obsidian basieren auf Codemirror und Electron, Pruvious und Nuxt.Studio basieren auf ProseMirror/TipTap. Es wäre evtl. möglich, z.B. ausgehend von einem Fork ein eigenes Editor-Projekt zu generieren, ein Fallbeispiel Joplin: Das Fork wäre dass (einige wichtige) Joplin Plugins weiter verwendet werden können aber lokal gespeichert wird.
Nach allem, was ich bislang gesehen und geprüft habe, ist Obsidian den Konkurrenten in vielen kleinen Punkten letztendlich doch überlegen. Herausragend ist vor allem die Plugin-Community rund um Obsidian. Vermutlich war das initiale Konzept von Obsidian rund um die Plugins so klar und zugänglich aufgestellt. Es bleibt spannend, das zu beobachten, wie sich die Dinge weiter entwickeln. Es gibt sicherlich eine Wahrscheinlichkeit, dass Obsidian auch FOSS wird ab einem bestimmten Punkt der Marktdominanz. Es kann aber auch ganz anders kommen, dass das Projekt stärker kommerzialisiert wird.
Eine umfangreiche Klärung von Voraussetzungen, Zusammenhängen und Strategien hat stattgefunden und ist jetzt abgeschlossen.
Jetzt steht an eine zeitgesteuerte Umsetzung der Erkenntnisse, ohne dabei noch viel rechts und links zu gucken, um dann erst im Vorlauf des 1.0-Release technische Hypothesen und Prüfsteine basierend auf dem programmierten Code zu überprüfen und Entscheidungen für Dokumentation und Release zu treffen, die das Projekt auf ein nachhaltiges Gleis setzen.
Ein wesentliches Kriterium der letzten Wochen war es, technische Lösungen aufzubauen, die sofort starten, sofort alpha-released werden können. Der agile Zyklus soll dauerhauft in Gang gesetzt werden, dass basierend auf konkreten Nutzer-Erfahrungen das Projekt weiterentwickelt wird.
Dies sind die wichtigsten Ausgangs- und Zielpunkte:
Die Hauptentscheidung der letzten Wochen: Theaterpedia vollzieht einen Paradigmenwechsel
anstatt zu versuchen:
Die Daten von Theaterpedia sollen in einem Format gespeichert werden, in dem sie 15-30 Jahre verbleiben können, so dass sie nicht mehr migriert werden müssen (oder nur noch sehr langsam). [1]
Die wichtigste Konsequenz dieser Entscheidung: Theaterpedia gibt den Teilnehmer:innen nicht das ggf. unrealistische Versprechen.
Das Ziel ist stattdessen:
Tools, Frameworks und Programmiersprachen kommen und gehen. Wichtig ist, dass die Daten bleiben dürfen wie sie sind.
Diesen Standpunkt vertritt "Kepano", der CEO von Obsidian - er macht einen wichtigen Zusammenhang klar:
in 5-15 Jahren wird es Vue und Nuxt, vlt. die ganzen Front-End-Frameworks in der uns heute bekannten Form vermutlich kaum noch geben, ähnlich wie es jetzt heute jQuery kaum noch gibt
falls Theaterpedia erfolgreich verläuft, wird aber ein Haufen Daten existieren mit einer unendlichen Anzahl 'handgemachter Zusammenhänge', die sich vermutlich nicht einfach so irgendwie 'technisch aktualisieren' lassen
Theaterpedia braucht ein Datenformat, in dem die Inhalte auch einen krassen Wechsel des Toolings unbeschadet überstehen
dieses Datenformat tritt doppelt in Erscheinung:
Ab hier noch zu prüfen: Ist HTML-Repräsentation von Markdown in DB/Pruvious noch erforderlich, wird es dadurch nicht überflüssig kompliziert?
das Datenformat hat mehrere Models (Event-Model, Blog-Model, Episode-Model, Company, User ...), jede Entity eines Models setzt sich aus 3 Field-Groups zusammen, die sowohl in Datenbank wie auch Markdown + YAML gespeichert werden können
in der Datenbank wird multilanguage-content in demselben Datensatz gespeichert
Es ist ein glücklicher Zufall, dass am Ende einer langen Kette von Entscheidungen nun trotzdem wieder ein fast monolithisches Vue-Nuxt-Konzept für das Front-End-Tooling herausgekommen ist. Es sah zwischenzeitlich sehr deutlich nach einem Konzept aus, in dem Vue vlt. noch die erste Geige spielt aber parallel dazu auch React und HTMX stehen. Ich habe gründlich recherchiert, welche Chancen und Risiken eine Öffnung in Richtung Astro mit sich bringen würde.↩︎