Alasan Memilih Elixir Phoenix daripada Rails, Laravel, dan Next.js

 (akarshc.com)
7 poin oleh GN⁺ 2025-10-18 | 3 komentar | Bagikan ke WhatsApp
  • Phoenix LiveView memberikan efisiensi tinggi baik dalam kecepatan aplikasi maupun kecepatan pengembangan
  • Keunggulannya adalah kita bisa menangani semuanya secara monolitik dengan satu bahasa, tanpa perlu memelihara frontend dan backend secara terpisah
  • Rails Hotwire dan Laravel Livewire juga sempat dipertimbangkan, tetapi untuk implementasi fitur real-time dan pekerjaan latar belakang, keduanya membutuhkan konfigurasi yang lebih banyak
  • Framework Phoenix dari Elixir mempertahankan keanggunan Ruby on Rails sambil menawarkan performa yang jauh lebih baik, memiliki pekerjaan latar belakang melalui Oban yang sudah terintegrasi, serta mendukung sintaks yang familier dan rapi
  • LiveView menyediakan pembaruan dua arah real-time berbasis WebSocket, menyeimbangkan render sisi server tradisional dengan framework yang berpusat pada frontend, dan bila perlu dapat menggunakan Alpine.js atau pustaka JavaScript melalui hook
  • Faktor penentu terakhir adalah kecepatan pengembangan yang tinggi, kemampuan menangani konkurensi tinggi, sebagian besar dapat ditulis dengan satu bahasa, pencegahan bug lebih awal melalui compiler, serta arsitektur toleran gangguan berbasis Elixir/Erlang

Mengapa Memilih Phoenix LiveView

  • Tujuan menulis kode adalah menyelesaikan masalah dengan cara yang paling optimal, dan faktor yang paling penting bagi penulis adalah kecepatan aplikasi dan efisiensi pengembangan
  • Jika menggunakan React atau Next.js bersama Laravel, atau menggunakan Inertia.js bersama Laravel, maka harus memelihara stack frontend dan backend sekaligus
  • Sebagai solo developer, tidak ada waktu untuk mengelola state di dua tempat berbeda, sehingga dibutuhkan solusi monolitik yang kuat yang bisa menangani semuanya bersama-sama

  • Perbandingan Alternatif: Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire dan Rails Hotwire adalah alat yang sangat baik untuk menyederhanakan pekerjaan frontend tanpa terlalu bergantung pada JavaScript
    • Full JavaScript stack dengan Next.js sempat dipertimbangkan, tetapi penggunaan JavaScript di backend bukan pilihan yang disukai
    • Rails Hotwire sangat menarik terutama karena kemampuannya membangun MVP dengan cepat menggunakan Rails
    • Namun, dibutuhkan pekerjaan latar belakang, pembaruan real-time, dan komunikasi dua arah, yang memang mungkin dilakukan di Rails maupun Laravel, tetapi membutuhkan lebih banyak usaha dalam konfigurasi

  • Keunggulan Penentu dari Elixir, Phoenix, dan LiveView

    • Elixir dan Phoenix mempertahankan keanggunan Ruby on Rails sambil memberikan performa yang jauh lebih tinggi
    • Background job bawaan melalui Oban, sintaks yang familier dan mudah dibaca, serta komunikasi dua arah real-time dari LiveView menjadi kekuatan utamanya
    • LiveView menghadirkan keseimbangan ideal antara pendekatan server rendering dan framework yang berat di sisi frontend
    • Pembaruan real-time melalui WebSocket serta integrasi dengan pustaka JavaScript (misalnya Alpine.js) juga dimungkinkan
    • Phoenix memudahkan deklarasi background job dan pemulihan otomatis berkat Oban yang terintegrasi

  • Kelebihan Elixir/Erlang

    • Elixir adalah bahasa hasil kompilasi yang dibangun di atas Erlang, fondasi bagi sistem konkurensi berskala besar seperti WhatsApp dan Discord
    • Menawarkan konkurensi tinggi, toleransi kesalahan, serta pemulihan otomatis saat terjadi gangguan

Alasan di Balik Pilihan Akhir

  • Pengembangan cepat dan dukungan konkurensi tinggi
  • Hampir semua hal bisa diimplementasikan dengan satu bahasa
  • Dapat menulis kode yang mudah dibaca
  • Compiler menangkap sebagian besar bug sebelum mencapai production
  • Arsitektur toleran gangguan membuat aplikasi hampir tidak pernah down sehingga stabilitas aplikasi lebih terjamin

Kesimpulan dan Saran

  • Phoenix tidak otomatis lebih unggul daripada Rails, Laravel, atau Next.js
  • Semua framework tersebut sangat baik, dan penulis memiliki pengalaman menggunakannya untuk berbagai proyek
  • Untuk situasi dan proyek tertentu milik penulis (Hyperzoned.com), Phoenix adalah pilihan yang paling cocok
  • Jika berani menjelajah melampaui apa yang sudah diketahui, kita bisa menemukan cara yang lebih baik dan lebih efisien untuk menyelesaikan masalah berikutnya
  • Jangan berhenti belajar

Bacaan terkait

3 komentar

 
clastneo 2025-10-23

Seperti JSP, rasanya begitu melewati tingkat tertentu jadi tidak bisa dipakai lagi.
 
GN⁺ 2025-10-18
Opini Hacker News

  • Saya pernah mengintegrasikan CKEditor langsung untuk Rails, Livewire, Phoenix, dan React. Dari semuanya, pengalaman pengembang di Phoenix paling mengesankan. Framework-nya dirancang dengan sangat baik sehingga pekerjaan integrasinya benar-benar sederhana. Di Rails dan React, terutama Next.js, saya sama sekali tidak merasakan kepuasan seperti itu. Next.js terlalu sering mengubah router, selalu berubah tiap saat, jadi sulit dipercaya. Livewire terasa mirip Phoenix, tetapi relatif kurang intuitif dan fiturnya lebih sedikit. Misalnya, Livewire tidak mendukung component slot, sedangkan Phoenix menanganinya tanpa masalah. Tanpa slot, struktur template jadi berantakan dan kode juga menjadi rumit tanpa perlu. Kalau ada yang penasaran, silakan lihat github ckeditor5-phoenix

    • Kombinasi PHP(Laravel) dan JQuery juga masih layak dipakai sampai 2025. Namun, secara pribadi saya tidak ingin memakai Livewire. Node.js bisa kurang produktif, tetapi berguna saat butuh fitur yang lebih kuat. Ada dukungan untuk async/await, socket.io, dan TypeScript. Next.js memang berguna jika membutuhkan SEO dan UI interaktif sekaligus, tetapi sebenarnya berapa banyak situs yang benar-benar memerlukan semua itu secara bersamaan? Mungkin hanya layanan seperti LinkedIn

    • Saya tidak menganggap Livewire sebagai salinan Phoenix. Dari namanya memang terdengar begitu, tetapi setahu saya kedua proyek itu dimulai hampir bersamaan dan Livewire justru proyek yang lebih lama. Hotwire muncul paling belakangan di antara semuanya. Kedua proyek itu mengambil pendekatan yang berbeda, dan PHP serta Elixir punya karakteristik yang sangat berbeda. Menurut saya Livewire juga cukup berguna. Karena tidak mudah memakai websocket di PHP, ia lebih berfokus pada HTTP, dan untuk kebanyakan situasi itu sudah cukup. Bahkan websocket di Liveview bisa terasa berlebihan

    • Saya penasaran secara spesifik tentang masalah yang Anda alami di Rails. Ingin dengar bagian mana yang terasa sulit

    • Saya penasaran bagian apa yang sulit saat menggunakan Rails

    • Di Livewire 4, dukungan component slot direncanakan akan hadir. Tapi masih tinggal beberapa minggu lagi. Katanya versi baru juga membawa peningkatan performa dan kemudahan pengembangan

  • Tulisan ini terasa seperti penulis sedang membela framework yang ia pilih sendiri, sambil sengaja mengabaikan fitur framework lain. Hal-hal yang disebut sebagai keunggulan Phoenix semuanya juga ada di Rails. Selain itu, tulisannya memberi nuansa seolah Rails tidak mendukung komunikasi frontend dan websocket, padahal bagi siapa pun yang membuat aplikasi dengan Rails dalam 3 tahun terakhir, itu jelas salah total. Tentu saja Phoenix dan LiveView juga alat yang bagus, tetapi alasan saya tetap memakai Rails adalah karena Hotwire Native. Saya bisa membuat aplikasi mobile dan web sendirian dalam waktu singkat, dan itu keunggulan produktivitas yang sangat besar

    • Saya belum banyak memakai Ruby, tetapi selain komunitasnya saya penasaran apa yang membuat Ruby on Rails lebih unggul daripada Elixir & Phoenix. Berkat platform BEAM, saya merasa Phoenix secara teori jauh lebih baik untuk soft real-time system, toleransi kegagalan, NIFs, actor model, banyak sekali proses ringan, concurrency yang mudah dipahami, functional programming, OTP, GC yang tidak menghentikan sistem, dan sebagainya. Tentu saja pakai saja yang disukai, dan saya juga berencana mencoba Hotwire Native

    • Jelas bahwa Rails juga bisa berkomunikasi dengan frontend lewat websocket. Bahkan saya sendiri adalah developer Rails, tetapi jika membutuhkan koneksi socket yang besar dan terus-menerus, saya akan memilih Phoenix. Dengan layanan seperti Gigalixir, Phoenix bisa menangani 100 ribu koneksi socket dengan jauh lebih murah dan mudah. Kalau Anda mengelola infrastrukturnya sendiri, ceritanya bisa berbeda. Tetapi dengan Heroku, bahkan beberapa ribu koneksi pun sulit dan biayanya memberatkan

    • Saya penasaran bagian mana dari tulisannya yang mengatakan Rails tidak mendukung komunikasi websocket dengan frontend. Di teks aslinya hanya tertulis, "Ini bisa dilakukan baik di Rails maupun Laravel, hanya saja butuh sedikit lebih banyak waktu untuk setup." Itu nuansanya sama sekali berbeda

    • Kombinasi Rails + Hotwire juga sangat kuat, dan akan lebih baik lagi jika ditambah Hotwire Native. Inti tulisan ini bukan bahwa Phoenix dan LiveView lebih baik, melainkan bahwa struktur LiveView (state yang dikendalikan server, pemisahan proses, channel ringan, dan sebagainya) cocok untuk situasi tertentu. Kedua ekosistem ini menyelesaikan masalah serupa dengan cara yang berbeda. Rails mendekatinya dengan convention dan progressive enhancement, sementara Phoenix dengan concurrency dan toleransi kegagalan dari BEAM. Pada akhirnya yang penting adalah struktur mana yang lebih cocok untuk produk yang sedang Anda bangun

    • Saya pernah dengar tentang Hotwire Native dulu, tetapi setelah itu rasanya sepi kabar. Saya penasaran dengan pengalaman memakainya di aplikasi mobile sungguhan, dukungan atau dokumentasinya, dan tingkat kematangan implementasinya

  • Saya juga punya perasaan positif terhadap Elixir, mungkin hampir sama besarnya dengan penulis, tetapi sebagai CTO yang memakainya selama 3 tahun di lingkungan produksi, semakin besar skala sistem, semakin terasa kekurangannya. BEAM (concurrency, toleransi kegagalan) benar-benar memenuhi janjinya, dan Ecto, Oban, iex jarak jauh, hingga kumpulan talenta juga sangat baik. Namun, developer experience (DX) lama-lama menjadi bottleneck. Di proyek besar dengan 300 ribu baris kode, ada masalah seperti berikut:

    • Waktu kompilasi: mengubah satu baris kode saja bisa memicu kompilasi lebih dari 10 detik di lingkungan pengembangan, sehingga fokus kerja terus terputus
    • Tooling: autocomplete ElixirLS tidak bisa diandalkan, sehingga banyak waktu habis untuk mencari nama fungsi atau field schema
    • LiveView: kurang cocok untuk UI yang kompleks sehingga kami terpaksa mengadopsi frontend React, dan akhirnya kompleksitas seperti GraphQL dan pemisahan stack kembali lagi
      Jika Anda sedang mempertimbangkan stack jangka panjang, membaca Retrospektif 3 tahun mungkin akan membantu

    • Saya sangat terkejut mendengar bahwa satu kali kompilasi di lingkungan pengembangan Elixir bisa memakan waktu lebih dari 10 detik. Saya selalu hanya mendengar bahwa Elixir memberi lebih banyak keuntungan dibanding Rails, jadi saya penasaran apakah kasus seperti ini umum terjadi di dunia kerja nyata

    • Saya juga mengalami hal serupa saat belajar Elixir. Saya menyukai bahasanya, tetapi saat bekerja di Windows lewat WSL, LSP sering rusak dan itu merepotkan. LSP resmi kabarnya akan segera dirilis, jadi saya berharap bagian ini akan membaik drastis

    • Kalau frontend seperti LiveView atau React tidak dikelola dengan baik, aplikasi besar akan cepat jadi berantakan. Semakin banyak orang di tim, code review dan pembersihan logic yang tidak perlu jadi mutlak diperlukan. Menurut saya ini berlaku untuk semua framework. Ke depannya memang masih banyak ruang untuk perbaikan

  • Ada klaim bahwa "dukungan ringan untuk background job, update real-time, dan komunikasi dua arah semuanya bisa dilakukan juga di Rails dan Laravel hanya dengan sedikit tambahan konfigurasi", tetapi Rails secara bawaan sudah mendukung Solid Queue (job) dan Solid Cable (pesan real-time)

    • Dari sudut pandang seseorang yang baru pindah ke Rails, SolidQueue benar-benar sederhana dan bisa langsung dipakai hanya dengan setup default. Jika ditambah Solid Queue Dashboard, Anda juga bisa melihat keseluruhan situasinya sekilas

    • Kalau hanya bicara soal pesan real-time, saya merasa konfigurasi Solid Cable lebih merepotkan dibanding LiveView. LiveView bahkan menangani rendering untuk Anda, jadi menurut saya ia jauh lebih maju daripada pengembangan SolidCable di Rails

    • Semua fitur itu juga bisa dilakukan di Rails. Ini framework yang sangat indah, dan dengan Phoenix semuanya terasa lebih mudah dan nyaman. Saya sangat menyarankan untuk mencobanya setidaknya sekali

    • Dari sudut pandang seseorang yang telah memakai Rails dan Elixir di pekerjaan nyata, kedua sistem itu sama sekali tidak setara. Oban jelas cara pakainya, dan untuk menjalankan ulang pekerjaan cukup memperbarui kolom DB lalu supervisor Oban akan menanganinya dengan baik. Solid Queue tidak punya cara mudah untuk menjalankan ulang job yang sudah sukses. Jumlah tabelnya juga terlalu banyak sehingga sulit dikelola. Oban cukup mengelola dua tabel saja dan bekerja secara alami di aplikasi yang sama, sementara Solid Queue perlu mengubah nilai konfigurasi sambil merujuk ke beberapa blog agar bisa berjalan dengan benar. Konfigurasi default-nya kurang memadai. Berkat sifat Erlang/Elixir, Oban bisa dibuat sangat sederhana namun tetap bekerja luar biasa, dan itu menyenangkan sebagai developer. Saya memakai Solid Queue karena terpaksa

  • Saya sudah lama mengembangkan dengan Rails, tetapi akhir-akhir ini Phoenix/Elixir menjadi stack utama saya. Rails masih benar-benar yang terbaik untuk cepat membuat aplikasi CRUD, dan dalam hal itu jelas unggul. Tetapi saat kompleksitas bertambah dan waktu berlalu, Phoenix/Elixir secara keseluruhan menjadi alat yang lebih baik

    • Sejak munculnya LLM, aplikasi sederhana seperti ini bisa dibuat hanya dalam beberapa menit. Namun, untuk bagian-bagian penting yang benar-benar perlu diperhatikan, Phoenix terasa memberi lebih banyak kontrol

    • Saya ingin dengar lebih spesifik bagian mana yang terasa lebih cocok, dan apa yang membuatnya tampak lebih unggul

  • Kalimat "kita menulis kode untuk menyelesaikan masalah dengan cara yang paling optimal" membuat saya bisa merasakan semangat penulisnya. Saya sendiri cenderung cukup puas asal masalahnya selesai, jadi mungkin tetap bertahan di Rails lebih cocok untuk saya

    • Saya tertawa saat membaca kalimat itu. Secara realistis, kalau menulis kode sambil hanya memikirkan optimasi, pekerjaan akhirnya justru berjalan lambat. Bagi saya coding juga merupakan cara mencari nafkah, dan kadang juga sekadar untuk bersenang-senang

  • Orang sering bilang komunitas Elixir itu kecil, tetapi mereka tetap menantang level tinggi dengan library mutakhir. Itu mengingatkan saya pada ucapan seorang developer lama, "semakin sedikit, semakin baik." Ada juga banyak open source bagus seperti elixir-dbvisor/sql

    • Sebaliknya, ekosistem JS terasa melelahkan karena terlalu besar. Ada 10 library berbeda yang semuanya berdiri sendiri, dan tidak ada yang mengikuti standar. Rasanya seperti memilih menu di supermarket besar di Amerika, atau dipaksa memilih di jaringan restoran Vercel

  • Kalau ingin benar-benar merasakan kehebatan Elixir, saya sarankan menonton semua video presentasi Saša Jurić

    • Saša Jurić adalah penulis buku 'Elixir in Action', dan bukunya juga sangat bagus

  • Tulisan ini lebih berfokus pada Phoenix LiveView daripada keseluruhan framework. Secara pribadi saya tidak suka bahwa bahkan jika LiveView dikecualikan dari opsi generator di Phoenix, kode dasar LV masih tertinggal di sana-sini

    • Saya juga setuju bahwa LiveView sangat opinionated dan punya banyak boilerplate. Saya menyukai keringkasan dan daya ekspresif Elixir, tetapi LiveView justru terasa kebalikannya

  • Satu-satunya alasan saya dulu tidak memilih Elixir adalah karena tidak adanya type checker. Saya penasaran apakah sekarang ada perubahan
 
colus001 2025-10-18

Memang benar Livewire itu menyenangkan, tetapi begitu UI menjadi sedikit lebih kompleks, semuanya berubah menjadi neraka. Sejak momen itu, Phoenix langsung kehilangan banyak keunggulannya. Karena makin sulit seiring siklus yang makin panjang, saya pribadi kurang bisa merekomendasikannya.