2 poin oleh GN⁺ 2026-01-06 | 1 komentar | Bagikan ke WhatsApp
  • JeffGeerling.com, yang sejak 2009 berjalan dengan basis Drupal, beralih ke static site generator (SSG) Hugo demi efisiensi blog pribadi
  • Banyaknya upgrade dan beban pemeliharaan dari Drupal 6 hingga 10 menjadi pemicu utama perpindahan ini
  • Hugo mendukung penulisan berbasis Markdown, sehingga menyederhanakan proses publikasi yang sebelumnya rumit, dan memungkinkan proses tulis-publikasi-deploy dijalankan dengan satu baris perintah
  • Dalam proses migrasi, beberapa masalah seperti tautan gambar rusak dan URL yang hilang dapat terjadi, dan fitur komentar serta pencarian direncanakan dipulihkan pada tahap berikutnya
  • Ini menjadi contoh yang menunjukkan manfaat nyata perpindahan ke situs statis dengan menghadirkan workflow yang ringkas dan efisiensi pemeliharaan bagi pengembang individu

Latar belakang perpindahan dari Drupal ke Hugo

  • Situs ini dimulai pada 2009 dengan Drupal 6, lalu mengalami upgrade bertahap ke 7, 8, 9, dan 10
    • CMS yang telah digunakan secara profesional selama lebih dari 10 tahun itu juga diterapkan pada blog pribadi
  • Setelah melalui proses upgrade yang rumit dari Drupal 7 ke 8, kelelahan karena mempertahankan Digital Experience Platform (DXP) kelas enterprise untuk blog pribadi pun menumpuk
  • Blog digunakan sebagai proyek pribadi dan ruang pendukung untuk konten YouTube, sehingga keputusan migrasi diambil agar bisa lebih fokus menulis daripada memelihara CMS

Alasan memilih Hugo

  • Sebelumnya sudah ada pengalaman memindahkan situs hobi ke hosting statis, dan sebagian di antaranya dikonversi ke Jekyll atau Hugo
  • Jekyll cocok untuk GitHub Pages, tetapi sebagai nonspesialis Ruby, ia lebih menyukai konfigurasi Hugo yang sederhana dan performanya yang cepat
  • Hugo mendukung Markdown secara bawaan, sehingga terhubung secara alami dengan cara menulis yang sudah ada

Proses migrasi dan masalah yang muncul

  • Pekerjaan migrasi sedang berlangsung di GitHub issue #158
  • Karena ada lebih dari 3.500 postingan dan data selama 20 tahun, ada kemungkinan sebagian gambar rusak, tautan error, dan redirect terlewat
  • Upaya terus dilakukan untuk sebisa mungkin mempertahankan struktur URL lama atau menambahkan redirect

Peningkatan workflow berbasis Markdown

  • Sejak 2020, semua postingan ditulis dalam Markdown
    • Sebelumnya, tulisan dibuat dalam Markdown di Sublime Text, lalu dikonversi ke HTML dan diunggah secara manual ke Drupal
  • Di Drupal, proses membuat postingan memerlukan beberapa langkah
    • Menempel isi, mengunggah dan menyisipkan gambar satu per satu, mengubah tanggal publikasi, membersihkan cache, dan sebagainya
    • Proses ini juga mencakup pengelolaan cache Cloudflare untuk menghadapi DDoS, sehingga alurnya menjadi rumit
  • Di Hugo, setelah menulis file Markdown, publikasi bisa dilakukan seketika dengan perintah hugo && git commit && git push
  • Beban pengelolaan server seperti Composer, Drush, PHP, MariaDB, dan Nginx pun hilang, sehingga efisiensi pemeliharaan meningkat

Rencana ke depan (TODO)

  • Fitur komentar akan dipulihkan pada tahap kedua melalui sistem komentar statis self-hosted
  • Fitur pencarian situs sebelumnya berbasis Apache Solr, tetapi saat ini dinonaktifkan
    • Cara mengimplementasikan pencarian di Hugo sedang ditinjau di issue #168
  • Pada tahap awal migrasi, komentar dinonaktifkan, dan pekerjaan pemindahan lama diperkirakan akan memakan waktu

Makna perpindahan ini

  • Keluar dari struktur penulisan dan pengelolaan konten Drupal yang kompleks, lalu beralih ke model operasional situs statis yang lebih sederhana dan efisien
  • Menjadi contoh nyata yang memberi pengurangan beban pemeliharaan dan ruang untuk fokus berkarya bagi pengembang individu
  • Perpindahan berbasis Hugo dinilai sebagai langkah yang meningkatkan keberlanjutan pengelolaan blog pribadi

1 komentar

 
GN⁺ 2026-01-06
Komentar Hacker News
  • Beberapa tahun lalu, saya memindahkan situs pribadi saya ke generator situs statis berbasis Common Lisp buatan sendiri
    Awalnya sekitar 850 baris, sekarang tumbuh menjadi sekitar 1500 baris, dan hampir semuanya dirender secara statis, termasuk posting blog, buku tamu, halaman komentar, feed RSS per tag, dan lain-lain
    Karena semua kode serta HTML dan CSS saya tulis sendiri secara manual, saya bisa mempertahankan kendali estetika dan menambahkan fitur baru dengan cepat
    Misalnya, untuk menambahkan halaman ‘backlink’, saya hanya butuh sekitar 40 baris kode CL dan 15 menit
    Sekarang sistemnya sangat stabil sehingga hampir tidak perlu disentuh lagi, dan saya bisa fokus hanya pada menulis

    • Dengan kepribadian seperti saya, blog self-hosted justru menjadi masalah
      Saya menghabiskan semua waktu untuk mengutak-atik mesin blog dan akhirnya malah tidak menulis
      Jadi saya sengaja kembali ke solusi hosting dengan kontrol yang lebih sedikit. Sekarang saya bisa fokus hanya pada menulis
    • Saya juga menyukai kebebasan dan stabilitas dari generator situs statis untuk satu tujuan
      Dulu saya mengelola proyek publik bernama Tclssg, dan berkat masukan pengguna saya sempat menulis dokumentasi serta menambahkan banyak fitur
      Tapi karena itu proyek publik, sulit untuk mengubah strukturnya sesuka hati
      Sekarang saya memakai generator khusus untuk situs saya sendiri yang terdiri dari Python (900 baris) + Pandoc Lua (700 baris)
      Riwayat evolusi teknisnya saya rangkum di situs saya
    • Saya juga merasakan hal yang sama. Saya mem-porting situs saya taoofmac.com ke Hy lalu menulis ulang lagi dalam Python
      Sekarang saya sedang membuatnya lagi dengan TypeScript/Bun, dan masih ada unsur bergaya LISP yang tersisa
      Saya sedang mencari dialek LISP/Scheme ringan yang punya SQLite dan parsing HTML bawaan serta bisa dikompilasi secara native
      Info terkait saya rangkum di sini
    • Saya juga melakukan hal serupa, membuat generator situs dalam Go
      Bahkan setelah bertahun-tahun, seluruh situs masih bisa dibangun dalam waktu kurang dari 1 detik
      Saya juga menambahkan sendiri fitur feed RSS dan code highlighting, memakai Chroma dan Blackfriday
      Saya sempat mencoba Hugo, tapi terlalu rumit sehingga akhirnya saya buat sendiri
    • Saya penasaran bagaimana komentar ditangani di blog statis
  • Dulu saya pindah dari svbtle ke Hugo, tapi jujur saya menyesal
    Saya mem-fork tema, tapi Hugo sering rusak sehingga terlalu banyak waktu habis untuk pemeliharaan
    Sekarang situsnya bahkan tidak bisa dibangun sama sekali
    Saran saya, sebaiknya simpan juga versi biner yang dipakai untuk membangun situs di source control

    • Saya sadar bahwa beberapa perangkat lunak memang tidak perlu di-update
      Generator situs statis hampir tidak punya isu keamanan, jadi kalau tidak butuh fitur baru, pakai saja versi lama
      Selama sistem operasi atau CPU tidak berubah besar, biasanya tidak masalah
    • Cukup tetapkan versinya di konfigurasi CI
      Saya juga mengunci versi dengan mengacu pada konfigurasi ini
      Saat mencari versi yang masih berfungsi, paling efisien memakai binary search
    • Saya menyelesaikannya dengan image Docker kustom
      Karena lokal dan CI sama-sama memakai versi Hugo yang sama, masalah seperti itu jadi tidak muncul
    • Saat memakai biner off-the-shelf, simpan saja di ${project}/bin/, tambahkan ke .gitignore, lalu catat checksumnya di file SHA256SUMS
      Caranya mirip versi sederhana dari Git LFS
    • Saya juga mengalami masalah serupa di Jekyll
      Saat pindah ke komputer baru, mencocokkan versinya terasa menakutkan, dan akhirnya saya sedang mem-porting-nya ke PHP meski belum selesai
  • Kalau Anda menulis dalam Markdown, pindah ke Hugo adalah pilihan yang masuk akal
    Saya juga memindahkan lebih dari 500 posting Jekyll ke Hugo, dan sintaks template adalah bagian yang paling sulit
    Tapi secara keseluruhan tetap menguntungkan
    Proses migrasi dan skrip konversi otomatisnya saya tulis di posting blog

    • Saya penasaran kenapa pindah dari Jekyll ke Hugo. Saya sendiri sudah cukup puas dengan Jekyll
  • SSG bagus untuk situs statis, tapi kalau butuh interaksi, tetap perlu server
    Kalau pada akhirnya tetap menjalankan server, merender Markdown secara dinamis terasa lebih sederhana
    Pada akhirnya SSG hanya menambah dependensi dan hal-hal yang bisa rusak
    Saya rasa Jeff nanti akan menyesal kalau ingin menambahkan fitur seperti komentar
    Secara pribadi saya merasa server sederhana berbasis SSR adalah solusi yang lebih realistis

    • Tapi kalau pengunjung atau bot mulai banyak, server bisa kewalahan
      Hal seperti ini tidak terjadi pada halaman statis, dan sebagian besar trafik memang hanya untuk membaca
      Jeff juga tampaknya ingin mengimplementasikan sendiri fitur komentar lewat issue
    • Saya juga menjalankan sendiri alat analitik self-hosted dan sistem komentar
      Dibanding era Drupal, ukuran kodenya jauh lebih kecil dan lebih sederhana
    • Generator situs statis justru bergerak ke arah mengurangi dependensi
    • Saya membuat halaman statis dengan SSG, dan komentar ditangani oleh server Common Lisp + Hunchentoot
    • Saya juga mengubah situs saya ke SSG dan sama sekali tidak menyesal. Justru semakin sederhana semakin baik
  • Saya penasaran dengan proses pengambilan keputusan saat memilih SSG
    Ada banyak alat utama seperti Hugo, Eleventy, Jekyll, dan Hugo khususnya cukup sering mengalami breaking change
    Kalau ini proyek lama, menurut saya seharusnya sekarang sudah menjamin stabilitas

    • Memang benar, Hugo melakukan perombakan total sistem template di v0.146
      Akibatnya build blog saya rusak, dan dokumentasinya juga belum sepenuhnya diperbarui
      Perubahannya sendiri tidak masalah, yang jadi masalah adalah dokumentasinya tidak mengikuti
  • Saya penasaran bagaimana kondisi Pelican belakangan ini. Di ekosistem Python, rasanya Hugo dan Pelican adalah dua nama terbesar
    Dibanding RSS, integrasi ActivityPub juga terlihat lebih menarik

    • Saya memakai Pelican dan puas
      Dulu saya memakai Nikola, tapi dependensinya terlalu banyak dan ada masalah ketidaksesuaian incremental build
      Saya suka Pelican karena tetap sederhana
    • Saya juga sudah beberapa tahun memakai Pelican
      Dokumentasinya terasa baru sekitar 90% lengkap, jadi detail-detail kecil masih kurang, tapi kalau hanya memakai fitur dasar, hasilnya sangat bagus
    • Saya menggunakan Pelican dengan beberapa plugin buatan sendiri
      Ada commit setiap bulan, jadi proyeknya masih hidup
    • Kalau Anda paham Python, Pelican adalah pilihan yang paling alami
  • Sekarang saya sedang mencoba pindah dari Hugo ke Zola
    Konfigurasi dan template Zola terasa jauh lebih intuitif

    • Saya juga pindah dari Jekyll ke Zola dan sama sekali tidak menyesal
      Build dan deployment saya otomatisasi dengan GitHub Actions
    • Kalau kebutuhan Anda tidak banyak, kombinasi Zola + gist itu sederhana dan cocok sekali
  • Saya sudah 3 tahun memakai Hugo
    Pelajaran yang saya dapat adalah tema sebaiknya di-fork dan dikelola sendiri
    Hindari submodule, dan lakukan update secara perlahan
    Fitur komentar masih tampak rumit

    • Betul. Pada akhirnya tema memang berbeda untuk tiap situs
      Saya juga sempat mencoba memindahkan tema Drupal tapi akhirnya menyerah
      Menurut saya, dibanding submodule, lebih baik langsung sertakan lalu override hanya bagian yang dibutuhkan
  • Tahun lalu saya memulai blog dengan Hugo, dan 3/4 dari 18 posting membuat saya menderita karena error build
    Saya kecewa karena terlalu tidak stabil

    • Saya juga pindah dari Hugo ke SSG Python buatan sendiri
      Daripada membiasakan diri dengan cara kerja Hugo, jauh lebih nyaman membuatnya cepat dalam bahasa yang saya kuasai
  • Dulu saya pernah membuat SSG sederhana sendiri, lalu belakangan mencari sesuatu yang lebih terstruktur dan mencoba 11ty
    Tapi template Liquid terasa sangat tidak nyaman
    Saya ingin memakai template berbasis JSX, tapi 11ty membuat itu sulit
    SSG NextJS memang kaya fitur, tapi terlalu kompleks dan terasa berlebihan
    Saya juga sedang mempertimbangkan membuat SSG kustom di atas framework seperti Tempest

    • Eleventy juga mendukung bahasa template klasik seperti Mustache
      Saya juga memindahkan situs berbasis Punch ke Eleventy, dan selama kecepatan build-nya memadai, rasanya lebih baik daripada Hugo
      Sekarang saya membangun ulang dengan Astro
    • Kami memindahkan situs marketing startup kami dari NextJS ke Astro dan sangat puas
      Pendekatannya berfokus pada statis, tapi tetap bisa memakai logika backend saat diperlukan
      NextJS terasa terlalu rumit untuk situs yang sederhana