Kelelahan dalam Mengelola Dependensi: Mengapa Saya Meninggalkan React dan Memilih Go+HTMX+Templ

• Tahun ini, setelah mengerjakan proyek pribadi menggunakan Go, HTMX, dan Templ, saya memutuskan untuk berhenti memakai React
  • Di situs resmi HTMX, ada banyak argumen meyakinkan tentang meninggalkan React dan memilih HTMX, tetapi saya merasa tidak banyak orang yang membicarakan soal kelelahan dalam mengelola dependensi
• Apa itu "kelelahan dalam mengelola dependensi"?
  • Dalam proyek pribadi terakhir saya yang menggunakan React (kamus bahasa Katalan interaktif), saya menyadari bahwa saya menghabiskan terlalu banyak waktu terutama untuk memperbarui dependensi paket React
  • Ketika paket diperbarui ke rilis terbaru, ada perubahan besar pada API sehingga saya harus meluangkan waktu untuk melakukan refactoring kode
  • Karena webapp tersebut dideploy sebagai layanan publik di instance EC2, saya ingin terus menjaga pembaruan dependensinya
• Apakah rilis major version baru benar-benar diperlukan?
  • Paket seperti wouter (paket router React) dan TanStackQuery (digunakan untuk mengambil data dari backend, melakukan caching, dan mengelola state) membuat webapp rusak parah akibat pembaruan major version.
  • Saat pembaruan major version pertama merusak aplikasi, saya melakukan refactoring kode tanpa banyak bertanya, tetapi ketika hal itu terjadi untuk kedua kalinya, saya mulai mempertanyakannya.
  • Saya mulai bertanya-tanya manfaat nyata apa yang sebenarnya didapat webapp dari rilis major version, selain patch keamanan.
  • Saya juga mempertanyakan apakah perlu sampai mematahkan API komponen utama sebanyak lima kali.
  • Saya memikirkan berapa banyak waktu yang hilang, padahal waktu itu bisa dipakai untuk merilis fitur baru atau meluncurkan produk lain.
• Masalah kekurangan waktu
  • Karena saya tidak punya banyak waktu untuk dialokasikan ke proyek coding pribadi, saya tidak ingin membuang waktu untuk refactoring kode setelah pembaruan major version dependensi.
  • Jika Anda membangun produk untuk klien dan berencana menagih biaya untuk pekerjaan pemeliharaan di masa depan, tidak masalah menggunakan banyak dependensi yang tidak stabil.
  • Namun, jika Anda ingin membuat produk yang membutuhkan pemeliharaan seminimal mungkin, saya akan menjauh dari ekosistem JS.
• Menggunakan Go+HTMX+Templ
  • Alasan utama saya menggunakan Go+HTMX+Templ dalam proyek pribadi adalah karena proyek Go memungkinkan saya tetap fokus pada peluncuran fitur, sambil tetap tidak mengabaikan pembaruan dependensi/keamanan yang umum
  • Bahasa Go sendiri mempertahankan standard library dan spesifikasi bahasa yang stabil.

[bbulbum]

HTMX tampaknya mendapat banyak ulasan positif.
Saya jadi berpikir apakah banyak orang mencari HTMX sebagai pelengkap untuk aplikasi berbasis SSR.
Sepertinya saya juga harus mencobanya sekali di proyek sampingan.

[savvykang]

Saya tidak memilih library TanStack karena terlalu kompleks melebihi kebutuhan dan kualitas dokumentasinya menurun dalam beberapa tahun terakhir. Selain itu, siklus pergantian paket npm terlalu singkat, jadi saya juga bertanya-tanya apakah memang perlu selalu bersikeras memakai versi terbaru.

Namun, sepertinya saat bekerja di perusahaan saya tidak bisa meninggalkan React. Kalau proyek pribadi, pakai apa pun rasanya tidak masalah.

[dohyun682]

Bukankah selama tidak melakukan pembaruan versi mayor, biasanya tidak ada masalah ketergantungan yang terlalu besar...?

[aer0700]

Belum lama ini saya melihat salah satu job terjadwal yang berjalan secara internal di perusahaan masih memakai Python 2, dan rasanya sesak.
Setelah dipikir-pikir, untuk sekarang saya memutuskan membiarkannya dulu karena masih berjalan dengan baik. Tapi tentu tidak mungkin terus bertahan selamanya tanpa update.

[aer0700]

Kelelahan mengelola dependensi VS kebosanan karena harus menemukan kembali roda
Ini perdebatan lama. Memang benar lebih baik tidak memakai roda yang tidak diperlukan, tetapi kalau hari ini tidak perlu, apakah besok juga tetap tidak perlu...
Saya sendiri belum pernah memakai Go, tetapi belakangan ini saya sering melihat banyak server yang dibuat dengan Go. Meski tidak akan langsung memakainya sekarang, rasanya saya tetap perlu mencoba menanganinya sekali.

[clickin]

HTMX mungkin sedang jadi yang terdepan di antara teknologi yang sedang naik daun, jadi banyak orang yang mencobanya, tetapi saya jadi berpikir bagaimana kalau arahnya malah ke go + vecty + gox.

[GN⁺]

Komentar Hacker News

• Berbagi pengalaman meninggalkan library seperti React dan mengembangkan aplikasi web dengan Actix, Tera, dan HTMX. Stack ini dinilai sangat mudah dirawat dan populer di kalangan pengguna

  • Menjelaskan pengalaman membangun aplikasi web baru dengan cepat lalu mendistribusikannya ke pengguna uji
  • Karena tidak ada "kelelahan mengelola dependensi", ia bisa memperoleh pemahaman yang lebih mendalam tentang alat yang digunakan

• Library buatan Tanner dinilai kaya fitur, tetapi desain API-nya kurang baik

  • React Table dan React Query memang kuat, tetapi batas tanggung jawabnya ditetapkan dengan buruk sehingga menimbulkan masalah
  • Kelebihan React adalah bahwa ia bukan framework, dan berhenti pada batas yang dirancang dengan baik
  • Ia berusaha hanya mengadopsi library yang memenuhi kriteria tersebut

• Ia merasa contoh-contoh HTMX hanya memindahkan kompleksitas ke bagian lain, dan menjelaskan bahwa JSX adalah cara yang elegan untuk menghindari template

  • Masih ada banyak masalah yang tetap harus diselesaikan, seperti routing, manajemen state, dan autentikasi

• Ia merasa aneh mengatakan "meninggalkan React", dan berargumen bahwa masalahnya bukan pada React melainkan pada dependensi lain

  • Pilihan untuk menulis backend dengan Go sebenarnya selalu ada

• Ia menekankan agar tidak lupa bahwa perubahan memang sudah diperkirakan saat memperbarui ke versi mayor berikutnya dari sebuah paket

  • Dengan contoh Remix, ia menjelaskan cara menerapkan perubahan secara bertahap
  • Ia berpendapat bahwa paket yang baik memang memerlukan upaya besar

• Berbagi pengalaman memigrasikan proyek SPA ke Django dan HTMX, serta menjelaskan bahwa dependensi JavaScript berkurang drastis

  • Ia menggambarkan SPA sebagai bom waktu

• Ia berargumen bahwa React tidak bertanggung jawab atas paket pihak ketiga yang dirawat dengan buruk

  • Ia menjelaskan bahwa alat manajemen state seperti router atau Redux tidak benar-benar diperlukan

• Ia merasa react-query v5 seharusnya kompatibel dengan API v3, tetapi menjelaskan bahwa migrasinya mudah dan tidak wajib dilakukan

  • Ia merasa "kelelahan mengelola dependensi" dibesar-besarkan, dan menyarankan untuk menjaga jumlah dependensi tetap masuk akal

• Ia mempertanyakan alasan melakukan upgrade meskipun aplikasi web tersebut tidak memperoleh manfaat tambahan

  • Ia menjelaskan bahwa upgrade ke versi terbaru tidak selalu memberikan keuntungan

• Ia menjelaskan bahwa setelah meninggalkan React dan nextjs lalu beralih ke stack lain, tingkat stresnya berkurang dan pembaruan tidak lagi memicu depresi