Dies ist ein Folgebeitrag zu https://de.news.hada.io/topic?id=19746.
Er behandelt die Gründe für die Wahl von Rhymix zum Aufbau einer inländischen Community-Website sowie den Entwicklungsprozess der Website mit Rhymix.
Nachfolgend die ChatGPT-Zusammenfassung.
Zusammenfassung der Erfahrungen mit der CMS-Auswahl und Entwicklung von zod.kr (Kurzfassung)
- Hintergrund: Das koreanische CMS-Umfeld wurde als zu veraltet eingeschätzt, aus pragmatischen Gründen wurde jedoch entschieden, kein neues System zu bauen, sondern ein bestehendes CMS zu verwenden.
- CMS-Vergleich:
- Gnuboard 5: Wegen Codequalität, Sicherheits- und Strukturproblemen ausgeschlossen.
- Rhymix: Durch die XE-Basis vertraut, mit verbesserter Struktur, Unterstützung moderner Syntax und guter Erweiterbarkeit → endgültige Auswahl.
- Vorteile von Rhymix:
- Viele moderne Funktionen wie Composer, modulare Struktur, Cache-Unterstützung und asynchrone Queues.
- Nachteile:
- Veraltete Admin-UI, unvollständige Third-Party-Komponenten, fehlende Dokumentation usw.
- Design: Nutzung eines responsiven Themes + Behebung zahlreicher Bugs sowie Verbesserungen an CSS/JS.
- Zusätzliche Funktionen:
- Viele Funktionen wie Web-Push, Event-Management, Uploads mit R2-Integration und Benutzerfunktionen wurden selbst implementiert.
- Modulentwicklung: Wegen fehlender Anleitungen erfolgte die Umsetzung durch Codeanalyse und eigenständiges Verständnis der Struktur.
👉 Kurz gesagt: In einem veralteten CMS-Umfeld fiel die pragmatische Wahl auf Rhymix, und durch viel Trial-and-Error sowie umfangreiche Anpassungen wurde zod.kr stabil aufgebaut.
2 Kommentare
Vielen Dank für dieses äußerst wertvolle Material zur tatsächlichen Entwicklung und zum Betrieb einer Website. Ich lese es mit großem Interesse.
Aus der Sicht eines Nutzers, der von den frühen XE1-Tagen bis hin zu Rhymix über mehr als ein Jahrzehnt hinweg damit gearbeitet hat, kann ich dem sehr gut zustimmen.
Ich denke, das größte Problem ist, dass ein großer Teil des Marktes, auf den Rhymix abzielt, nicht ausreichend in der Lage ist, selbst zu entwickeln.
Wer selbst entwickeln kann, entscheidet sich oft eher für Laravel oder Ähnliches, statt die mangelhafte Dokumentation, die unklare Struktur und die Legacy-Altlasten von XE oder Rhymix in Kauf zu nehmen.
Wie der Autor des Originalbeitrags setze auch ich in einigen neuen Projekten aus folgenden Gründen auf Rhymix:
und so weiter. Trotzdem frage ich mich jedes Mal intensiv, ob diese Entscheidung wirklich die richtige ist.
Ich nutze Rhymix gewissermaßen als Ersatz für ein Framework und habe persönlich verschiedene Versuche unternommen, um die Punkte zu ergänzen, die ich dabei als unbefriedigend empfunden habe.
https://github.com/nemorize/rx-make (develop-Branch / PoC-Projekt, kein geplanter Einsatz in Produktion)
Ich probiere vieles aus — etwa Rhymix vollständig zu einem Framework bzw. einer Bibliothek zu machen, den Zugriff auf Legacy-APIs zu minimieren und modernere APIs neu aufzubauen, die ungefähr mit den Legacy-Systemen kompatibel sind ... aber ich zerbreche mir darüber wirklich sehr den Kopf, haha..
Ich habe diese Überlegungen bisher noch nie klar geordnet, aber bei dieser Gelegenheit sollte ich sie einmal sauber strukturieren.