TSBOARD (Open-Source-Community-Builder, geschrieben in TypeScript)
(github.com/sirini)Was ist TSBOARD?
- TSBOARD steht für Type Safety BOARD und ist ein in TypeScript geschriebenes Community-Building- bzw. Forensystem.
- Für das Backend werden die Laufzeitumgebung Bun, die hier auf GeekNews bereits einmal vorgestellt wurde, sowie das Web-Framework ElysiaJS verwendet. Dadurch arbeitet es im Vergleich zu herkömmlichen Foren-Engines schneller.
- Im Frontend kommen Vue und Vuetify zum Einsatz. Allerdings lässt der ästhetische Sinn des Entwicklers etwas zu wünschen übrig, weshalb ich diesen Beitrag in der Hoffnung schreibe, dass ich künftig vielleicht die Hilfe großzügiger Designerinnen und Designer bekommen könnte. (+ Natürlich ist auch die Hilfe großzügiger Entwicklerinnen und Entwickler willkommen!)
Warum wurde es entwickelt?
- Ich habe mit
PHPangefangen, Webprogramme zu entwickeln, und bin ein Entwickler, der noch die Zeiten von Zeroboard und GnuBoard erlebt hat. - Meine letzte Erinnerung an JavaScript war ungefähr: eine Sprache, die ohne
jQuerykaum zu gebrauchen war (...). - Doch durch die fortlaufenden Verbesserungen der Standards, das Aufkommen von
Node.jsund meine verspätete Begeisterung für Microsofts TypeScript hat sich das geändert. (Eigentlich war ich wohl viel zu spät dran.) - Deshalb wollte ich noch einmal ein Webprogramm entwickeln und dabei das Forensystem, das ich schon immer bauen wollte, ausschließlich in TypeScript schreiben.
- Außerdem wollte ich es – wenn schon – so entwickeln, dass es einfach zu benutzen ist und zugleich schneller sowie sicherer arbeitet. Deshalb ist TSBOARD entstanden.
Die besonderen Vorteile von TSBOARD
- TSBOARD ist sowohl im Frontend als auch im Backend in TypeScript geschrieben und gewährleistet damit ein Höchstmaß an Type Safety. (Nichts ist vollkommen, aber auf die Type Safety habe ich am meisten Wert gelegt.)
- Wer schon einmal Full-Stack-Entwicklung auf Basis von
Node.jsgemacht hat, wird das Design leicht verstehen und direkt nutzen können. Da auch ich es beim Lernen von Grund auf entwickelt habe, habe ich mich stark an Best Practices anderer orientiert. - Für die Entwicklung kleiner bis mittelgroßer Community-Websites sind alle notwendigen Funktionen integriert. Bei der Entwicklung habe ich mich an bekannten koreanischen Community-Seiten wie Clien, Quasar Zone, Giggle Hardware oder dem neueren Damoang orientiert.
Es gibt auch Nachteile.
- Die Bun-Laufzeitumgebung funktioniert auf virtuellen CPUs nicht richtig. Auf günstigen Virtual-Server-Hostings lässt sie sich daher nur schwer sinnvoll einsetzen. Da TSBOARD ebenfalls von Bun abhängt, gilt das auch hier.
- TSBOARD verwendet Client Side Rendering. Als jemand, der
PHPimmer noch sehr schätzt, war mir der Begriff Server Side Rendering eher fremd. Diese Methode hat verschiedene Vor- und Nachteile, aber ich wollte zunächst einen (für mich) neuen Ansatz ausprobieren. Da ich TSBOARD außerdem mit dem Ziel entwickelt habe, die Serverlast zu senken, könnte genau das für manche eindeutig ein Nachteil sein. - Tatsächlich habe ich vor über einem halben Jahr mit der Entwicklung begonnen, aber es gibt noch immer viele unzureichende Punkte, sodass ich das Projekt erst jetzt überhaupt vorstellen kann. Ich hoffe, dass dieser Nachteil künftig mit der Hilfe der Menschen, denen ich noch begegnen werde, behoben werden kann.
Abschluss: In der Hoffnung, dass bekannte Community-Seiten TSBOARD eines Tages übernehmen
- Als ich gesehen habe, wie GnuBoard von PHP zu Python wechselt, hatte ich das Gefühl, dass auch Webprogramme weiterhin ständig neue Wege ausprobieren. Dasselbe gilt für Rhymix, das aus XE hervorgegangen ist. Das Web ist nach wie vor dynamisch – und die Entwicklung ebenso.
- Auch ich möchte mit dem TSBOARD-Projekt auf meine kleine Weise zum Web-Ökosystem beitragen und hinterlasse deshalb diesen Vorstellungstext.
- Ich träume von dem Tag, an dem eine neu entstehende Community-Website TSBOARD übernehmen wird, haha.
Vielen Dank, dass ihr diesen langen Text gelesen habt!
21 Kommentare
Ich bin mir nicht sicher, ob es hilfreich ist, einem Beitrag von vor etwa zwei Wochen noch einen zusätzlichen Kommentar hinzuzufügen, haha.
Während ich darüber nachgedacht habe, wie ich das SEO-bezogene Feedback von GeekNews umsetzen kann,
habe ich
sitemap.xmlimplementiert und hinterlasse diesen Kommentar, um die Inhalte im Sinne der Suchmaschinenoptimierung zu teilen!Kurz gesagt: Die Suchmaschine greift über
robots.txt>sitemap.xmlzu und sammelt die Daten letztlich unter dem Pfadhttps://tsboard.dev/tsapi/seo/main.html (Beispielseite).
Wenn Nutzer über die Suche auf die Seite gelangen, werden sie von dort aus über die Links wieder zur ursprünglichen Website weitergeleitet.
Weitere Details findet ihr unter dem folgenden Link!
https://tsboard.dev/board/free/18
Ich hatte auch überlegt, ein Projekt, das ich als Hobby entwickle, mit bun laufen zu lassen, aber es überrascht mich, dass es auf einer virtuellen CPU nicht richtig funktioniert. Und bei der Registrierung stand bei den Passwortbedingungen „Großbuchstaben“, daher dachte ich, dass Kleinbuchstaben nicht enthalten sein müssten, aber das war wohl irreführend, haha. Sie sollten wohl „Groß- und Kleinbuchstaben“ schreiben.
Ich hinterlasse vorsichtshalber eine Antwort. Wer die Bun-Runtime in Betracht zieht, muss sich nun keine Sorgen mehr über Probleme beim Betrieb auf virtuellen CPUs machen ...! Ich habe es mit Version 1.1.31 getestet und bestätigt, dass es problemlos funktioniert. :)
Ah, vielen Dank für den Kommentar, und ich werde den von Ihnen angesprochenen Teil mit den Passwortbedingungen auf jeden Fall noch anpassen. Haha.
Bun habe ich selbst auch nicht wirklich tiefgehend genutzt, aber beim Verwenden konnte ich in vielerlei Hinsicht viele überraschende Erfahrungen machen. Es gab oft Fälle, in denen Funktionen, die in Node.js selbstverständlich funktionierten, aus irgendeinem Grund nicht gingen (darunter zum Beispiel auch das Problem, dass beim Erstellen von Ordnern die Option
recursive: truenicht unterstützt wurde), und zugleich gab es viele Aspekte, bei denen man gemerkt hat, wie erstaunlich stark auf Geschwindigkeit fokussiert wird (weshalb ich es letztlich nur noch sympathischer finden konnte).Inzwischen heißt es wohl Bundows, und die Bun-Runtime wird unter Windows nun offiziell unterstützt, aber vor 1.1 ging das nicht, sodass man sie unter WSL2 ausführen musste. Dass es auf virtuellen CPUs läuft, wird Bun vermutlich auch in Zukunft eher nicht unterstützen. Zwar wird sogar eine Distribution (
baseline) für CPUs bereitgestellt, die keine AVX2-Befehle unterstützen, aber dass virtuelle CPUs nicht unterstützt werden, ist in vielerlei Hinsicht trotzdem bedauerlich — ob das nun an einer Einschränkung von Zig liegt, der Sprache, in der Bun entwickelt wird, weiß ich nicht. Mein Eindruck bei der Nutzung war einfach: Auch Bun hat offenbar für die Geschwindigkeit an einigen Stellen Kompromisse gemacht.Falls es hier zukünftige Bun-Nutzer gibt, die diesen Kommentar lesen, noch ein kleiner Nachtrag: Trotz der verschiedenen Einschränkungen ist Bun eine attraktive Option. Vor allem, wenn Sie sich als Web-Framework für ElysiaJS entscheiden, denke ich, dass es zumindest in puncto Geschwindigkeit keinen Grund zur Enttäuschung geben wird. Wenn ich wieder an den Punkt käme, ganz von vorn ein Runtime auszuwählen ... würde ich zwar noch etwas länger darüber nachdenken, mich am Ende aber trotz aller Probleme vermutlich wieder für Bun entscheiden. Diese beinahe fanatische Fixierung auf Verarbeitungsgeschwindigkeit und die Haltung, ein bereits als gelöst geltendes JS-Runtime-Ökosystem herauszufordern, berühren irgendwie etwas in mir. Haha.
Beim Durchsehen des GitHub-Codes sind bei mir ein paar Fragen aufgekommen, deshalb hinterlasse ich diese hier.
Persönlich war ich sehr beeindruckt, weil endlich einmal ein Board auf TS-Basis erschienen ist, auf das ich schon lange gehofft hatte!
In v0.8.40 wurde die Konfiguration von Fremdschlüsseln übernommen! https://tsboard.dev/board/free/18
Oh, vielen Dank für Ihren Kommentar!
Mit dem Setzen von Beziehungen meinen Sie wohl, dass keine Fremdschlüssel eingerichtet sind! Das hatte keinen besonderen Grund; ich wollte das einrichten, sobald die Tabellenstruktur einigermaßen feststeht, aber währenddessen kamen andere Dinge dazwischen, sodass ich es bisher noch nicht umsetzen konnte. Inzwischen haben sich die Abhängigkeiten zwischen den TSBOARD-Tabellen und die referenzierten Spalten weitgehend stabilisiert, daher werde ich nun auch Fremdschlüssel einrichten und das Ganze so umstellen, dass die Integrität besser gewährleistet ist!
Über NoSQL hatte ich kurz nachgedacht, aber... da es ohnehin schon so viel Neues zu lernen gab – angefangen bei TypeScript bis hin zu Vue, Node.js/Bun und mehr – habe ich mich entschieden, nicht zu wechseln. Relationale Datenbanken sind angesichts ihrer langen Geschichte inzwischen zwar schon recht alt, aber ich habe auch darüber nachgedacht, ob es nicht einen guten Grund gibt, warum sie nach wie vor an so vielen Stellen nützlich eingesetzt werden. Zum Zeitpunkt, an dem ich diesen Kommentar schreibe, sehe ich das so; falls später einmal ein Bedarf entsteht, könnte ich aber auch etwas wie MongoDB in Betracht ziehen. haha
Dass es bislang noch kein auf TypeScript basierendes Board gab, ist für mich persönlich tatsächlich überraschend, aber vielleicht ist das auch nur eine Frage der Zeit. Ich würde mich freuen, wenn viele weitere Projekte in einem anderen Stil als TSBOARD entstehen würden! haha Vielen Dank für Ihren Kommentar!
Ehrlich gesagt hatte ich wegen der alten PHP-Board-Systeme früher keine großen Erwartungen, aber nachdem ich die Demo-Seite (https://tsboard.dev) gesehen habe, habe ich meine Meinung geändert. Die Qualität ist wirklich sehr hoch.
Ich denke, solche Punkte könnten wichtig sein!
Habt ihr den Editor selbst implementiert? Respekt. Ich vermute, ihr habt wohl eine Editor-Engine(?) verwendet, aber man spürt auf jeden Fall einen enormen handwerklichen Anspruch.
Vielen Dank für den Kommentar! Nochmals vielen Dank, dass Ihnen die Qualität der Seite tsboard.dev so gut gefällt. haha
Für die von Ihnen angesprochene SSR-Unterstützung habe ich die Roadmap in zwei Phasen aufgeteilt. Zuerst möchte ich ergänzende Maßnahmen anwenden und danach in einer späteren Version CSR und SSR sinnvoll kombinieren und so weiterentwickeln. Um die Performance ausreichend zu erhalten und zugleich besser für SEO zu optimieren, muss ich vor allem selbst noch viel mehr lernen, daher brauche ich wohl noch etwas Zeit. Ich hoffe, dass ich, wenn ich nicht aufgebe und kontinuierlich weitermache, auch andere großartige Entwickler kennenlernen, schneller lernen und vielleicht Unterstützung bekommen kann. haha
Nicht eingeloggte Nutzer hatte ich bei der Entwicklung von TSBOARD ursprünglich nicht berücksichtigt, um die Entwicklungszeit zu verkürzen und die Einfachheit des Designs beizubehalten, aber ich werde mir dazu noch mehr Gedanken machen! Zum Zeitpunkt, an dem ich diese Antwort schreibe, wären allerdings viele Änderungen nötig, wenn auch Nichtmitglieder berücksichtigt werden sollen, daher scheint das kurzfristig schwierig zu sein. ^^;;;
Den Editor habe ich auf Basis des tiptap-Editors Stück für Stück aufgebaut, aber die Implementierung des Editors hat überraschend viel Zeit verschlungen. Soweit ich mich erinnere, war es früher vielleicht CKEditor...? So etwas konnte man wohl einfach übernehmen, aber heutzutage muss man das anscheinend wie Lego Stein für Stein zusammensetzen. schluchz. Dazu kam noch zusätzliche Mühe, um die TSBOARD-Funktionen zu integrieren. Während der Entwicklung dachte ich mir, es wäre schön, wenn jemand allein diesen Editor schon fertig bauen würde, haha... Falls also jemand einen brauchbaren Editor auf tiptap-Basis braucht, können die von mir in TSBOARD implementierten Codes wahrscheinlich als Referenz dienen, damit sich vieles schneller und einfacher entwickeln lässt.
Es gibt überraschend viele Leute, die das so positiv sehen, sodass ich fast denke, die Zeit, in der ich überlegt habe, ob ich überhaupt einen Vorstellungsbeitrag schreiben soll, war verschwendet. TSBOARD hat noch viele Schwächen, aber ich hoffe trotzdem auf Ihre weitere Unterstützung!
Ich habe mit der Entwicklung in php angefangen, und es ist auch gerade so eine Zeit, in der ich, weil ich von typescript begeistert bin, vieles ausprobiere.
Irgendwie fühle ich mich dadurch verbunden und freue mich darüber.
Freut mich! Ich bin irgendwie ebenfalls auf einer ähnlichen Reise unterwegs. Haha, die Sprache PHP bekommt bis heute hier und da noch ihr Fett weg, was ich persönlich etwas schade finde. Aber nachdem ich TypeScript ausprobiert habe, denke ich, dass ein bisschen Kritik vielleicht doch in Ordnung ist. Haha, ich hoffe, dass auch Sie, yeppyshiba, mit TypeScript viele spannende Projekte umsetzen werden. :)
Wirklich großartig 👍
Vielen Dank!! Es ist zwar noch ein unfertiges Projekt, aber ich freue mich sehr, dass Sie es wohlwollend sehen. Haha.
Ich werde weiter hart daran arbeiten, TSBOARD zu verbessern, damit ich es Ihnen eines Tages, wenn Sie es brauchen, mit gutem Gewissen empfehlen kann. :)
So etwas habe ich vermisst … danke.
Vielen Dank für Ihren Kommentar! Falls Sie irgendwann einmal ein Webprogramm ähnlich wie TSBOARD benötigen, würde ich mich freuen, wenn Sie sich daran erinnern und es testen würden. Ich werde weiterhin mit großem Einsatz daran arbeiten, damit Sie es bei Bedarf noch bequemer nutzen können!
Oh ...! Ich erinnere mich noch an das sirini-Board aus der PHP-Zeit, wirklich eine Ewigkeit her.
Damals habe ich sogar Skins für das Sirini-Board entwickelt und Sicherheitslücken gemeldet – wie geht es Ihnen heute? :)
Beim Durchsehen des Codes war mein Eindruck, dass der serverseitige Code irgendwie noch stark nach PHP aussieht, haha (JS-Code mit PHP-Anmutung?)
Wie bereits jemand anderes erwähnt hat, dürfte CSR den Nachteil haben, bei SEO und Ähnlichem im Hintertreffen zu sein.
Ich hoffe, dass dieser Punkt gut verbessert werden kann, haha
Ach, dann waren Sie ja der Wohltäter, der mir früher einmal geholfen hat! Es freut mich sehr, Sie auf diese Weise wiederzutreffen, haha.
Außerdem ist es mir damals wie heute ein wenig peinlich, weil ich anscheinend nur recht banale Dinge baue, auf die wohl jeder kommen könnte. ^^;;
Wie Sie gesagt haben, steckt im Backend-Code noch ein gewisser PHP-Stil, haha. Auch ich frage mich manchmal: Gibt es die Funktionen, die ich in PHP benutzt habe, nicht auch in JS? Dann suche ich jedes Mal danach und vergebe manchmal Funktionsnamen mit ähnlichen Bezeichnungen. Wenn ich mich noch mehr an JS/TS-Code gewöhne und weiter refaktoriere, lässt sich das vielleicht noch verbessern. Hahaha.
Den SEO-Teil muss ich, wie Sie angemerkt haben, wohl noch ergänzen. Mein kurzer Gedanke dazu ist, andere statische Seiten wie etwa RSS hinzuzufügen, aber ich werde Verschiedenes ausprobieren.
Übrigens ist es wirklich erstaunlich und ich bin sehr dankbar, dass es jemanden gibt, der sich noch an mich aus der PHP4-Zeit erinnert! Tatsächlich habe ich lange überlegt, ob ich diesen Beitrag überhaupt schreiben soll. Haha;; Ich werde versuchen, auch weiterhin wenigstens ein wenig mehr Menschen zu helfen. Bitte schenken Sie auch TSBOARD weiterhin viel Liebe!
Beim Lesen des Beitrags sind bei mir ein paar Fragen aufgekommen, daher hinterlasse ich einen Kommentar. (Ich habe mir den Code nicht angesehen)
Mich würde interessieren, warum das Backend nicht Node.js-kompatibel entwickelt wurde. (Ist die Performance zu schlecht, um die genannten Nachteile auszugleichen?)
Falls es sich um CSR handelt: Wie ist der Plan für SEO? Bei einer Community scheint auch Suchmaschinen-Traffic wichtig zu sein.
Hallo! Vielen Dank, dass Sie einen Kommentar hinterlassen haben. (Ehrlich gesagt dachte ich, das würde in allgemeinem Desinteresse untergehen, deshalb freue ich mich sehr.)
Über die Punkte, nach denen Sie gefragt haben, habe ich selbst auch sehr viel nachgedacht; ich würde mich freuen, wenn Sie es einfach als eine von mehreren möglichen Sichtweisen lesen.
Ach, nur als Hinweis: Nach PHP habe ich meine Webentwicklung im echten Berufsalltag kein einziges Mal weitergeführt. Ich habe weder die Ära der Node.js-Revolution noch die Zeit, in der React die Webwelt verändert hat, aktiv verfolgt, daher mag meine Perspektive an manchen Stellen etwas ungewohnt wirken. :)
Als ich anfing, TSBOARD zu entwickeln, bin ich zunächst einfach davon ausgegangen, dass es bereits irgendein bekanntes, auf Node.js basierendes (mir nur unbekanntes) Board, Blog oder jedenfalls etwas Ähnliches zu dem geben würde, was ich bauen wollte. Wie ich eingangs erwähnt habe, hatte ich im Berufsalltag nichts mit Webentwicklung zu tun, und ich hatte auch nie wirklich ein Side Project gemacht, daher lag diese Annahme für mich nahe. Ich dachte ganz selbstverständlich: Es wird sicher schon etwas auf Node.js-Basis geben, also hat es wenig Sinn, wenn ich noch einmal etwas Neues mache. Wenn ich ohnehin etwas Neues lerne, dann probiere ich es lieber auf Bun-Basis aus — und diese Entscheidung hat sich bis heute fortgesetzt.
Wenn man über Performance nachdenkt, halte ich Node.js für die kleine Community-Site, die ich ursprünglich im Blick hatte (weniger als 10 gleichzeitige Nutzer), tatsächlich für völlig ausreichend. Bevor ich Bun ernsthaft in Betracht gezogen habe, habe ich auch mit Node.js + Hono getestet, und aus meiner Sicht gab es dabei eigentlich keine Probleme. Allerdings waren die überwältigende Performance, die Bun gezeigt hat, und zusätzlich die Performance von ElysiaJS, das auf Bun aufbaut, wirklich beeindruckend, sodass ich darauf nicht verzichten wollte. Da ich annahm, dass bereits jemand anderes ein hervorragendes Board auf Node.js-Basis gebaut haben würde, dachte ich, ich bräuchte eine höhere Performance, um mit diesem hypothetischen Board konkurrieren zu können. Am Ende habe ich deshalb die Node.js-Kompatibilität aufgegeben und die Architektur abhängig von Bun gestaltet. (Inzwischen bereue ich das ein wenig. Offenbar gibt es auf Node.js-Basis gar kein bekanntes Board wie GnuBoard, Rhymix oder XE ...? Oder habe ich es nur nicht gefunden??)
Da haben Sie vollkommen recht. Wenn man Suchmaschinen-Traffic bekommen will, muss der Google-Crawler die Inhalte letztlich lesen und für Suchtreffer zuordnen können. Diesen Teil habe ich bislang noch nicht umgesetzt, aber ich überlege, ob man auf Wunsch der Nutzer die neuesten Inhalte separat in statischer Form bereitstellen könnte, ähnlich wie man einen RSS-Feed veröffentlicht. Ich denke auch darüber nach, ob eine externe Bereitstellung im JSON-Format es Aggregatoren erleichtern würde, die Daten zu aktualisieren. Darüber werde ich noch weiter nachdenken. (Ich hatte an RSS gedacht, aber heutzutage benutzt das anscheinend kaum noch jemand, oder?? Vielleicht war ich wirklich zu lange aus der Webwelt raus T_T)
Unabhängig von möglichen SEO-Maßnahmen habe ich mich für CSR entschieden, weil ich die Serverlast noch konsequenter reduzieren wollte. Soweit ich weiß, hat selbst die relativ neue Seite Damoang (ich weiß gar nicht, ob ich den Namen der Community hier einfach so öffentlich nennen darf) mit erheblicher Traffic-Last und Serverbelastung zu kämpfen. Wenn man an einen Community Builder denkt, ist SEO zwar wichtig, aber ich wollte zuerst das Problem angehen, das direkt mit den Kosten zusammenhängt, und habe daher zunächst CSR gewählt. Als jemand, der PHP immer noch liebt, ist mir SSR eigentlich sogar vertrauter, aber ich dachte mir: Wenn der Client die Rechenleistung etwas aktiver nutzt, könnte der Server wieder mehr Luft bekommen. So können Sie diese Entscheidung verstehen.
Ich hoffe, das hat einige Ihrer Fragen geklärt. Außerdem sind die Entscheidungen, die ich getroffen habe, jeweils mit klaren Vor- und Nachteilen verbunden, deshalb halte ich TSBOARD selbst nicht für die einzig richtige Antwort. Ich habe verschiedene Trade-offs abgewogen, und Sie können es als Entscheidungen betrachten, die ich auf Grundlage meiner begrenzten Überlegungen getroffen habe. Wenn TSBOARD künftig breiter genutzt wird, kann ich meine Meinung jederzeit ändern und auch andere Ansätze ausprobieren. :)
Das Design ist bereits auf CSR ausgelegt, daher würde eine Umstellung auf SSR vermutlich Arbeiten auf dem Niveau einer fast vollständigen Neuentwicklung erfordern.T_T
Zwar verbessern aktuelle Such-Crawler die Verarbeitung von JS teilweise, aber an schlichtes HTML kommen sie wohl trotzdem nicht heran.
Normale Browser könnten per CSR bedient werden, während Such-Bots (
GoogleBot,Yetiusw.) per SSR verarbeitet werden.Persönlich halte ich so einen Ansatz allerdings eher für eine Zwischenlösung, und wenn man SEO wirklich gut unterstützen will, ist SSR am Ende wohl die richtige Antwort.
Auch bei CSR wird die Last auf dem Backend letztlich steigen, wenn das Anfragevolumen zunimmt, und es scheint sinnvoller zu sein, die Backend-Last durch ein gutes Cache-Design und verschiedene weitere Maßnahmen zu reduzieren ^^;
Bei TSBOARD ist, wie Sie gesagt haben, derzeit alles auf Basis von CSR umgesetzt, daher werden wir zumindest in der Version v1.y.z wohl nach dem Prinzip „nur CSR“ arbeiten müssen. Als mögliche Ergänzung könnte man etwa nur für die Startseite SSR anwenden, da dort alle Beiträge angezeigt werden, oder wie von Ihnen vorgeschlagen eine separate Seite hinzufügen, damit Bots die Plain-HTML-Seite crawlen können. Solche Verbesserungen werden wir nach Möglichkeit in der Versionsreihe v0.9.z berücksichtigen!
Ich wollte das noch erwähnen, weil ich etwas besorgt bin, dass manche denken könnten: „TSBOARD ist CSR-basiert, also wird es nicht von Suchmaschinen gefunden!“ Im Fall des Googlebots heißt es, dass er inzwischen bereits so weit verbessert wurde, dass er auch Inhalte von Websites erfassen kann, die mit CSR erstellt wurden! (Weil es Google ist, vielleicht ...?) SEO ist dabei zwar eindeutig im Nachteil, aber es ist nicht so, dass es überhaupt nicht funktioniert — Sie müssen sich also nicht allzu viele Sorgen machen.
Es gibt sicher nicht nur CSR und SSR, sondern auch Ansätze irgendwo dazwischen, daher werde ich mir dazu noch mehr Gedanken machen und auch eine v2.0.0-Roadmap mit dem Ziel aufstellen, die SEO zu verbessern. (Das ist allerdings noch Zukunftsmusik, haha.) Vielen Dank für Ihren Rat, und obwohl das Projekt noch in vieler Hinsicht unausgereift ist, hoffe ich weiterhin auf Ihr Interesse an TSBOARD!