Ulasan 7 bulan pengembangan dan 5 bulan setelah rilis zod.kr - Bagian pemilihan dan pengembangan CMS

Ini adalah tulisan lanjutan dari https://id.news.hada.io/topic?id=19746.

Tulisan ini membahas alasan memilih Rhymix untuk membangun situs komunitas domestik serta proses pengembangan situs menggunakan Rhymix.

Berikut adalah ringkasan oleh ChatGPT.

---

Ringkasan ulasan pemilihan dan pengembangan CMS zod.kr (ringkas)

• Latar belakang: Lingkungan CMS Korea dinilai terlalu usang, tetapi karena alasan realistis diputuskan untuk memakai CMS yang sudah ada alih-alih membuat yang baru.
• Perbandingan CMS:
  • Gnuboard5: Dikeluarkan dari pilihan karena kualitas kode, keamanan, dan masalah struktur.
  • Rhymix: Berbasis XE sehingga familier, dengan struktur yang diperbaiki, dukungan sintaks modern, dan ekstensibilitas yang baik → dipilih sebagai opsi akhir.
• Kelebihan Rhymix:
  • Banyak fitur modern seperti Composer, struktur modular, dukungan cache, dan antrean asinkron.
• Kekurangan:
  • UI admin yang kuno, ekosistem pihak ketiga yang belum matang, kurangnya dokumentasi, dan sebagainya.
• Desain: Memanfaatkan tema responsif + memperbaiki banyak bug serta meningkatkan CSS/JS.
• Penambahan fitur:
  • Web push, manajemen event, upload terintegrasi R2, fitur pengguna, dan banyak implementasi kustom lainnya.
• Pengembangan modul: Karena manual kurang memadai, implementasi dilakukan dengan menganalisis kode dan memahami strukturnya secara langsung.

👉 Ringkasan: Di tengah lingkungan CMS yang usang, Rhymix dipilih sebagai opsi yang realistis, dan melalui banyak trial and error serta kustomisasi, zod.kr berhasil dibangun secara stabil.

[jujumilk3]

Terima kasih banyak atas materi yang sangat berharga ini, mulai dari pengembangan situs nyata hingga operasionalnya. Saya sangat menikmati membacanya.

[nemorize]

Dari sudut pandang pengguna yang telah memakai XE1 sejak masa awal hingga Rhymix selama belasan tahun, ini adalah isi yang sangat mudah saya pahami.

Menurut saya, masalah terbesar adalah bahwa sebagian besar pasar yang ditargetkan Rhymix tidak cukup memiliki kemampuan untuk mengembangkan sendiri secara langsung.

Orang-orang yang memang mampu mengembangkan sendiri biasanya lebih memilih mengadopsi Laravel dan semacamnya, daripada harus menoleransi dokumentasi XE atau Rhymix yang kurang memadai, struktur yang ambigu, dan berbagai hal legacy.

Sama seperti penulis artikel asli, saya juga

1. halaman admin yang terasa familier bagi banyak orang
2. fitur-fitur sebagai CMS yang meski ada kekurangan kecil, tetap tidak terasa kurang
3. tim pengembang inti yang aktif mengakomodasi usulan-usulan baru
4. rasa kedekatan karena sudah lama menggunakannya
   Dan sebagainya, sehingga saya pun mengadopsi Rhymix di beberapa proyek baru, tetapi setiap kali saya tetap banyak berpikir apakah pilihan ini benar-benar pilihan yang tepat.

Saya pribadi juga sedang mencoba berbagai pendekatan untuk melengkapi bagian-bagian yang terasa kurang saat menggunakan Rhymix sebagai pengganti framework.
https://github.com/nemorize/rx-make (branch develop / proyek PoC, tidak direncanakan untuk produksi)

Saya mencoba berbagai hal, seperti menjadikan Rhymix secara utuh sebagai framework/library, meminimalkan akses ke API legacy, dan membangun ulang API yang lebih modern dengan kompatibilitas yang kira-kira tetap terjaga dengan versi legacy, tetapi... ini benar-benar membuat saya sangat banyak berpikir haha..

Saya belum pernah merapikan kegelisahan ini dengan jelas, jadi saya rasa ini kesempatan yang bagus untuk sekali mencoba menyusunnya dengan lebih terang.