Belajar Zellij - Sejarah, Latar Belakang & Mengapa Memilih Zellij

#Pendahuluan

Di episode 0, kalian sudah membangun fondasi yang kokoh: terminal modern dengan true color, Nerd Font, instalasi Zellij yang terverifikasi, dan sesi pertama yang berjalan tanpa hambatan. Sekarang saatnya mundur selangkah untuk memahami mengapa Zellij ada. Sebelum menghafal keybinding dan menulis layout, kalian perlu tahu masalah apa yang sebenarnya dipecahkan tools ini, dari mana ia lahir, dan kenapa memilih Zellij adalah keputusan yang masuk akal dibandingkan pendahulunya.

Zellij bukan tools pertama yang mencoba menyelesaikan keterbatasan terminal polos. GNU Screen lahir pada 1987 dan menjadi standar selama dua dekade; tmux datang pada 2007 dan menyempurnakan konsepnya. Namun keduanya dibangun di era yang berbeda — era di mana plugin belum terpikirkan, kolaborasi berarti berbagi layar secara fisik, dan bahasa pemrograman sistem belum seaman hari ini. Zellij hadir pada 2021 dengan filosofi segar: dibangun di Rust, mengadopsi mode system alih-alih prefix key, mendukung plugin WASM, serta menyediakan kolaborasi dan otomasi secara bawaan.

Episode 1 ini adalah jembatan pemahaman. Kalian akan menelusuri evolusi terminal workspace, kisah kelahiran Zellij, alasan Rust dipilih sebagai fondasi, timeline versi dari 0.30 hingga 0.44, masalah konkret yang diselesaikan, serta perbandingan awal kapan memakai Zellij, tmux, atau terminal polos. Setelah episode ini, posisi Zellij dalam ekosistem akan terasa jelas — dan itu membuat episode 2 tentang arsitektur jauh lebih mudah dicerna. Mari mulai.

#Evolusi Terminal Workspace

Sebelum Zellij ada, developer menghadapi keterbatasan yang sama selama puluhan tahun: satu jendela terminal hanya bisa menjalankan satu proses di satu layar. Ingin menjalankan dev server dan editor sekaligus? Kalian harus membuka banyak jendela, memecah fokus, dan kehilangan konteks. Ingin berpindah tugas tanpa menutup proses? Satu-satunya jalan adalah trik Ctrl+Z dan fg untuk menangguhkan job, yang terasa sangat primitif di era ketika multi-tasking sudah jadi kebutuhan harian.

Keterbatasan itulah yang dipecahkan oleh screen multiplexer. Konsepnya sederhana: satu proses server berjalan di latar belakang dan mengelola beberapa area layar virtual yang bisa kalian alihkan kapan saja. Proses yang berjalan di dalam area itu tidak peduli apakah area-nya sedang terlihat atau tidak — ia tetap hidup dan melanjutkan pekerjaannya. Terobosan ini sangat berharga di era ketika koneksi SSH sering terputus di tengah pekerjaan: pekerjaan yang berjalan di dalam session tidak ikut mati selama server multiplexer masih hidup.

GNU Screen adalah pelopornya. Dirilis pertama kali pada 1987, Screen memperkenalkan konsep yang sampai sekarang masih kita pakai: session, window, split, detach, dan attach. Kalian bisa memulai sebuah task, melepas diri (detach) dari session, lalu kembali lagi (attach) dari mana pun — asalkan server Screen masih berjalan. Selama lebih dari dua dekade, Screen adalah jawaban utama bagi administrator sistem yang menghabiskan hari di remote server. Namun Screen menua dengan buruk: konfigurasinya rumit dan penuh trik, tampilannya jadul, dan fitur-fiturnya tidak pernah benar-benar berkembang mengikuti zaman.

Celah itulah yang ditutup tmux pada 2007 oleh Nicholas Marriott. tmux mempertahankan semua konsep Screen — session, window, pane, detach, attach — tetapi dibangun ulang dengan arsitektur client-server yang lebih bersih, konfigurasi yang lebih masuk akal, dan status bar yang bisa dikustomisasi luas. Yang lebih penting, tmux memperkenalkan sesuatu yang menjadi ciri khasnya sampai hari ini: prefix key. Semua aksi dilakukan dengan menekan Ctrl+B terlebih dahulu, lalu diikuti tombol aksi.

Model prefix key inilah yang kemudian menjadi bahan perdebatan paling hangat di komunitas terminal. Di tmux, setiap aksi dimulai dengan menekan Ctrl+B, melepasnya, lalu menekan tombol aksi. Pendekatan ini bekerja, tetapi memiliki masalah klasik: kalian harus mengingat urutan dua sampai tiga tombol untuk setiap aksi, konflik dengan keybinding editor muncul terus-menerus, dan tidak ada petunjuk yang muncul di layar ketika kalian lupa. Zellij lahir sebagian besar karena ketidakpuasan terhadap model interaksi semacam ini.

#Kelahiran Zellij

Zellij dibuat oleh Aram Dreveckenius, yang dikenal di komunitas terminal dengan nama imsnif. Ia bukan orang asing dalam ekosistem ini: selama bertahun-tahun ia hidup di dalam terminal, menjadi maintainer termux.el (integrasi tmux untuk Emacs), dan berkontribusi pada berbagai project pengelola terminal. Frustrasinya terhadap tmux bukan soal fitur — tmux memang sangat powerful — melainkan soal pengalaman. Ia merasa sebuah multiplexer tidak perlu terasa sekompleks itu. Pane, tab, dan session adalah konsep yang mudah dipahami; yang membuatnya terasa sulit adalah cara mengoperasikannya.

Versi pertama Zellij dirilis pada 2021. Sejak awal, visinya sudah jelas: membangun terminal workspace yang keyboard-first dengan interaksi yang terasa alami, karena setiap mode menampilkan petunjuk langsung di layar. Tidak ada lagi menghafal kombinasi tombol yang tak terlihat. Kalian menekan satu tombol untuk masuk ke mode, dan Zellij langsung menampilkan semua aksi yang tersedia di status bar bagian bawah. Kalau lupa, tekan ? dan daftar keybinding lengkap muncul.

Filosofi yang diusung Zellij sejak hari pertama:

• All-in-one: session, tab, pane, floating pane, dan plugin UI tersedia dalam satu tools, tanpa perlu merakit komponen dari tools berbeda.
• Mode-based interaction: setiap kelompok aksi (pane, tab, resize, move, scroll, session) punya mode sendiri dengan petunjuk on-screen.
• Extensible by design: plugin berjalan sebagai modul WASM, bukan sekadar script yang disuntikkan ke dalam proses utama.
• Collaboration-first: berbagi session dengan rekan kerja, bukan sekadar fitur tambahan, melainkan bagian dari desain inti.

Perjalanan dari rilis pertama hingga hari ini tidak mulus — banyak keputusan desain yang berubah, termasuk migrasi dari renderer lama ke arsitektur baru. Namun satu hal tidak pernah berubah: obsesi untuk membuat terminal workspace yang terasa menyenangkan, bukan terasa sebagai beban.

#Mengapa Rust

Pilihan bahasa pemrograman adalah keputusan paling fundamental dalam sebuah project, dan Zellij memilih Rust. Ini bukan sekadar mengikuti tren — ada tiga alasan teknis yang kuat dan saling melengkapi.

Pertama, memory safety. Zellij adalah aplikasi yang berurusan dengan banyak proses bersamaan: satu server mengelola banyak session, banyak client terhubung sekaligus, dan ribuan event keyboard mengalir setiap menit. Dalam bahasa seperti C, kesalahan kecil dalam pengelolaan memori bisa menjadi crash atau bug yang hanya muncul dalam kondisi tertentu — paling berbahaya justru ketika dipakai di production server yang berjalan berhari-hari. Rust menjamin keamanan memori saat kompilasi, sehingga kelas bug yang paling sering menimpa tools sistem bisa dihilangkan sejak awal.

Kedua, performance. Terminal emulation adalah pekerjaan yang sangat intensif: Zellij harus merender grid karakter, memproses escape sequence, mengelola scrollback berukuran besar, dan memperbarui status bar — semuanya secara real-time tanpa membuat layar berkedip atau input terasa lambat. Rust menghasilkan binary native yang cepat dan hemat memori, sebuah keunggulan yang terasa jelas ketika kalian membuka banyak session atau bekerja di mesin dengan sumber daya terbatas.

Ketiga, ekosistem WASM. Inilah alasan yang paling strategis. Plugin Zellij dijalankan sebagai modul WebAssembly, dan Rust adalah bahasa dengan dukungan toolchain WASM terbaik di industri. Pilihan ini bukan kebetulan: dengan menulis plugin dalam WASM, Zellij mendapatkan isolasi proses (plugin yang crash tidak membawa session), portabilitas (plugin sama berjalan di semua platform), dan keamanan (plugin berjalan di sandbox). Bahasa lain yang populer di era 2007 tidak memiliki jalur ini, dan itulah mengapa tmux tidak pernah bisa menawarkan model plugin yang setara.

#Timeline Versi Stabil

Zellij merilis versi stabil secara konsisten sejak 2021, dan kecepatan rilisnya termasuk cepat untuk tools sekelas multiplexer. Memahami timeline ini berguna untuk dua hal: mengenali fitur yang tersedia di versi kalian, dan menghargai seberapa cepat tools ini berkembang. Berikut peta dari 0.30 hingga versi terbaru.

Versi yang dirujuk oleh seluruh series ini adalah Zellij 0.44.x. Sebagian besar contoh di episode berikutnya diuji pada seri versi ini. Jika kalian menjalankan versi yang jauh lebih tua, beberapa perintah mungkin tidak tersedia; jika kalian menjalankan versi yang lebih baru, sintaksnya hampir pasti tetap kompatibel karena Zellij menjaga stabilitas antarmuka dengan baik.

zellij --version

Perhatikan pola rilisnya: setiap versi minor membawa tema besar, bukan sekadar perbaikan bug. Dari perspektif pembelajaran, ini kabar baik — kalian bisa memetakan fitur ke versi dan membaca changelog resmi untuk memahami setiap keputusan desain. Ketika versi baru dirilis, biasakan memeriksa changelog sebelum update agar tahu apa yang berubah.

#Masalah yang Diselesaikan Zellij

Setelah memahami asal-usul dan teknologinya, mari fokus pada pertanyaan paling praktis: masalah konkret apa yang diselesaikan Zellij? Ada tiga masalah besar yang ia jawab secara bersamaan.

Masalah pertama adalah fragmentasi tools. Sebelum Zellij, developer harus merakit workspace dari banyak tools: tmux untuk multiplexing, tmux-resurrect untuk persistence, fzf untuk switching session, dan puluhan plugin yang saling bertabrakan. Zellij menyatukan semuanya dalam satu tools dengan session, tab, pane, floating pane, plugin UI, dan otomasi — tanpa perakitan manual. Kalian tidak perlu lagi menjadi tukang merakit tools hanya untuk mendapat terminal yang produktif.

Masalah kedua adalah interaksi keyboard yang tidak manusiawi. Model prefix key tmux memaksa kalian menghafal urutan kombinasi yang tidak tampil di layar, dan konflik dengan keybinding editor (terutama di terminal Vim dan Neovim) adalah peperangan yang tidak pernah berakhir. Zellij menggantinya dengan mode: Ctrl+p masuk ke Pane mode dan semua aksi pane tampil di status bar, Ctrl+t untuk Tab mode, dan seterusnya. Kalian tidak menghafal — kalian membaca petunjuk yang selalu hadir.

Masalah ketiga adalah kolaborasi dan otomasi yang tidak bawaan. Di tmux, berbagi session memerlukan pengaturan socket dan izin manual yang rumit; mengotomasi workspace memerlukan script tambahan. Zellij menjadikan keduanya fitur kelas satu: session bisa dibagikan dengan rekan kerja lewat mekanisme bawaan, dan pipes serta CLI actions memungkinkan kalian mengendalikan workspace dari script tanpa mengetik satu karakter pun di layar.

#Perbandingan Awal

Sebelum menutup episode ini, mari lakukan perbandingan awal untuk membantu kalian memutuskan kapan memakai tools yang mana. Tidak ada pilihan yang salah secara mutlak — semuanya tergantung konteks pekerjaan kalian.

Terminal polos tetap punya tempatnya. Jika kalian hanya menjalankan satu proses, membuka terminal langsung lebih cepat dan tanpa overhead. Namun begitu pekerjaan membutuhkan lebih dari satu proses yang hidup bersamaan — editor di satu sisi, dev server di sisi lain, log di sisi ketiga — multiplexer segera menjadi kebutuhan, dan Zellij menawarkan pengalaman paling modern di kelasnya.

Bagi kalian yang baru memulai, perbandingan di bawah memperlihatkan kemiripan sekaligus perbedaan model interaksi kedua tools sejak langkah pertama.

tmux new -s dev
tmux attach -t dev

zellij -s dev
zellij attach dev

Perhatikan polanya: perintah dasarnya hampir paralel, tetapi pengalaman di dalamnya sangat berbeda. Di episode 3 kalian akan merasakan langsung perbedaan itu, dan di episode 4 kita membedah mode system secara menyeluruh. Untuk sekarang, cukup pegang kesimpulan ini: Zellij mengambil semua ide baik dari pendahulunya dan membungkusnya dalam interaksi yang lebih ramah.

#Kesalahan Umum (Common Pitfalls)

1. Menganggap Zellij sebagai pengganti terminal. Zellij berjalan di atas terminal dan bergantung pada kemampuan terminal emulator kalian. Jika warna tampil rusak atau ikon tidak muncul, periksa dulu terminal dan font — bukan menyalahkan Zellij.
2. Mengharapkan prefix key ala tmux. Zellij memakai mode, bukan prefix. Kebiasaan menekan Ctrl+B dari tmux tidak akan bekerja; kalian perlu membangun ulang muscle memory. Ini normal dan hanya butuh waktu beberapa hari.
3. Membandingkan fitur secara dangkal. Perbandingan Zellij vs tmux yang hanya menghitung jumlah fitur sering menyesatkan, karena perbedaan utamanya ada di model interaksi, bukan daftar kemampuan. Bandingkan setelah mencoba keduanya secara nyata.
4. Mengabaikan versi. Fitur seperti pipes, web client, dan remote sessions baru ada di versi tertentu. Membaca panduan untuk versi lama lalu menjalankannya di Zellij 0.44 bisa membingungkan. Selalu cek zellij --version dan rujuk changelog.
5. Langsung migrasi total tanpa mencoba. Zellij adalah investasi yang layak, tetapi jangan melepas semua konfigurasi tmux dalam satu malam. Jalankan keduanya secara paralel untuk sementara, bandingkan rasanya, baru putuskan.

#Penutup

Episode 1 ini menempatkan Zellij pada peta sejarah yang jelas. Kalian telah melihat evolusi dari GNU Screen yang lahir pada 1987, tmux yang datang pada 2007 dengan model prefix key, hingga Zellij yang dirilis 2021 dengan mode-based interaction dan plugin WASM. Kalian juga memahami mengapa Rust menjadi fondasi — memory safety untuk server yang selalu berjalan, performance untuk terminal emulation real-time, dan ekosistem WASM untuk plugin system.

Poin yang harus kalian bawa:

• Terminal workspace berevolusi dari Screen, ke tmux, ke Zellij — dengan model interaksi yang makin ramah.
• Zellij lahir dari frustrasi terhadap prefix key tmux, bukan dari kekurangan fitur.
• Rust memberi Zellij keamanan memori, performa tinggi, dan jalur plugin WASM yang tidak dimiliki pendahulunya.
• Timeline 0.30 hingga 0.44 memperlihatkan laju perkembangan yang cepat: pipes, filepicker, plugin manager, web client, hingga remote sessions.
• Tiga masalah besar yang dipecahkan: fragmentasi tools, interaksi keyboard yang tidak ramah, dan kolaborasi yang tidak bawaan.
• Terminal polos dan tmux tetap relevan — pilih berdasarkan konteks, bukan tren.

Sekarang kalian tahu mengapa Zellij ada dan dari mana ia berasal. Langkah berikutnya adalah memahami bagaimana ia bekerja. Di episode 2 kita membedah arsitektur utama Zellij: model client-server, komponen inti yang ditulis dalam Rust, plugin system berbasis WASM, hierarki session, tab, pane, dan floating pane, mode input yang mengatur seluruh interaksi, serta layout system berbasis KDL. Sampai jumpa di episode 2!