Anda Mungkin Tidak Benar-Benar Membutuhkan tmux: Cara Menggantikan tmux dalam Workflow Pengembangan

 (bower.sh)
17 poin oleh GN⁺ 2025-08-04 | 7 komentar | Bagikan ke WhatsApp
  • tmux telah digunakan dalam waktu lama, tetapi belakangan muncul keraguan terhadap kompleksitas dan keterbatasannya (kompatibilitas warna, scrollback, penyalinan dengan mouse, tidak mendukung protokol tertentu, dll.)
  • Fitur utama tmux seperti persistensi sesi (detach/attach) atau pembagian/pengelolaan jendela tidak harus selalu diwujudkan dengan tmux
  • Dengan memanfaatkan tool ringan berfilosofi Unix seperti dtach, abduco, shpool, kita bisa fokus pada pengelolaan sesi sambil tetap mendapatkan scrollback native dan kesederhanaan
  • Khususnya, melalui kombinasi shpool + ssh, dimungkinkan membangun lingkungan untuk mengelola beberapa sesi remote langsung dengan window manager, sambil tetap memakai fitur native (notifikasi, scroll, title, dll.) apa adanya
  • Meski tidak sempurna, menurut penulis pendekatan ini sepenuhnya bisa menggantikan tmux, dan menghadirkan workflow yang sederhana serta mudah dirawat

Kelebihan dan Kekurangan tmux

  • Fitur seperti mempertahankan sesi (detach/attach) dan pengelolaan jendela (tab, split) selama ini merupakan inti workflow yang disediakan tmux
  • Namun, tanpa pengaturan TERM yang benar, muncul masalah rendering warna, dan kompleksitas bertambah karena perlu mempertimbangkan interaksi antara terminal dan tmux
  • Penggunaan buffer scroll juga mengharuskan pengguna membiasakan diri dengan cara kerja tmux yang terpisah, dan penyalinan area dengan mouse juga terasa kurang nyaman di lingkungan splits
  • Dukungan terhadap fitur terminal baru seperti kitty graphics protocol juga kurang memadai, termasuk masalah tidak didukungnya protokol eksperimental
  • Ada juga kritik bahwa multiplexer, karena menafsirkan ulang escape code yang tumpang tindih serta menambahkan konsep sesi/jendela, menghambat perkembangan ekosistem terminal

Menjelajahi Cara Pengganti tmux

  • Persistensi sesi:
    • Solusi sederhana seperti ctrl-z + fg, nohup, disown memang ada, tetapi sulit menjadi pengganti penuh
    • Muncul berbagai tool yang memang bertujuan hanya mempertahankan sesi (dtach, abduco, shpool)
      • Menghubungkan daemon dan klien melalui kombinasi fork() dan UNIX socket
      • Berbeda dari tmux, tanpa split virtual sehingga mendukung scrollback native, dan sebagian juga menyediakan pemulihan buffer
    • Dari pengalaman penggunaan, sebagian besar tool pengganti masih kurang matang karena bug dan masalah seperti keybind detach yang tidak berfungsi di dalam nvim
    • Hanya shpool yang dinilai paling matang dari sisi perintah detach/attach dan kustomisasi keymap
  • Pengelolaan jendela:
    • Di lokal, pembagian dan penataan dikelola oleh window manager
    • Di lingkungan remote (SSH) pun, dengan menggabungkan ssh_config dan shpool, beberapa sesi dapat dipertahankan secara independen di jendela terpisah
    • Dikombinasikan dengan autossh, sesi tetap terjaga bahkan di lingkungan yang memerlukan reconnect jaringan

Workflow Baru

  • Secara pribadi, penulis mengelola jendela dengan ghostty (laptop) dan sway+foot (PC pribadi). Server berjalan di VM headless berbasis Proxmox, sehingga lingkungan pengembangan via SSH selalu aktif
  • Beberapa sesi shpool dihubungkan otomatis melalui shortcut ssh, lalu dikendalikan secara independen dari window manager lokal
    • Otomatisasi attach sesi shpool untuk tiap host di ssh_config
    • Memungkinkan akses terpisah ke banyak sesi seperti IRC, pengelolaan dotfiles, dan lingkungan neovim yang berbeda untuk tiap terminal
  • Fitur-fitur yang didukung tmux secara kurang stabil, seperti scroll native, notifikasi, dan title terminal, justru bekerja lebih alami
  • Tetap ada kekurangan: pemulihan status terminal saat reconnect ke vim bisa tertunda, dan ada masalah resize saat memakai nvim
    • Tidak mendukung multiplayer (konflik sesi saat autossh aktif bersamaan dari beberapa klien)
  • Namun, menurut standar pribadi penulis, ini merupakan keberhasilan penuh dalam menggantikan tmux

Kesimpulan

  • Meski tidak sepenuhnya identik, ada kemungkinan beralih ke workflow pengelolaan sesi yang lebih sederhana dan fleksibel, lepas dari kompleksitas serta keterbatasan tmux
  • Bergantung pada workflow masing-masing, tool alternatif seperti shpool layak dipertimbangkan

Bacaan terkait

7 komentar

 
egirlasm 2025-08-05

Sekarang orang-orang membuat hal seperti tmux dengan AI lalu langsung memakainya. Dengan Xterm.js + react + electron, dalam 3-4 jam saja bisa mencetak 100 hal seperti itu, lalu kalau perlu tinggal diperbaiki secara real-time sambil dipakai, rasanya seperti makan shabu-shabu? Tinggal masukkan apa yang ingin dimakan, lalu limpahkan banyak-banyak ke source.
 
barca105 2025-08-05

Saya menggunakannya dengan nyaman menggunakan wezterm.
 
iolothebard 2025-08-04

Screen paling mantap!
 
helio 2025-08-04

cargo install shpool...saya pakai tmux saja...setiap OS harus punya paket yang berbeda-beda!
 
mineboo 2025-08-04

Ada pendatang baru yang luar biasa bernama Zellij. Sangat direkomendasikan.
 
xguru 2025-08-05

Zellij - terminal untuk developer & ops

Ini juga ternyata pernah saya posting cukup lama yang lalu, haha
 
GN⁺ 2025-08-04
Komentar Hacker News

  • Tulisan ini memang ditujukan untuk pengguna Linux-on-the-Desktop, tetapi saya ingin menekankan bahwa tmux benar-benar bersinar saat dipakai bersama iTerm2 di MacBook
    Berkat integrasi tmux di iTerm2, tmux menyatu sepenuhnya secara alami ke dalam alur kerja saya
    Jika Anda menaruh konfigurasi seperti di bawah ini di ~/.ssh/config, Anda bisa dengan mudah mengakses server pengembangan jarak jauh melalui ssh tmux kapan saja, bahkan setelah menyalakan ulang MacBook atau berpindah jaringan
    Berkat integrasi iTerm2 dan tmux, tab tmux jarak jauh dan scroll buffer bekerja seperti tab lokal, dan sebenarnya Anda bahkan tidak perlu tahu perintah tmux untuk memakainya

    • Saya memakai Linux di semua perangkat pribadi saya, dan terutama memakai MacBook untuk bekerja, jadi tmux sangat berguna karena menghadirkan lingkungan yang sama secara lintas platform
      Di Linux saya memakai Alacritty, tetapi di macOS selalu ada sesuatu yang tidak langsung berjalan karena pengaturan yang pas atau perbedaan terkait jendela/scroll
      Saya tidak ingin menghabiskan waktu untuk perbedaan OS seperti ini, jadi kombinasi tmux dan iTerm2 bagus karena memberi pengalaman yang nyaris sama dengan Linux
      Fakta bahwa scrollback dalam sesi disediakan sepenuhnya terpisah juga merupakan kelebihan bagi saya
      Kritik terhadap tmux menurut saya justru lebih dekat ke isu para pengembang terminal
      Jika dukungannya kurang, tinggal pindah ke terminal yang memberi dukungan lebih baik

    • Saya memakai kombinasi mosh dan screen
      Bahkan jika server reboot, sesi bisa dipulihkan, dan saat berganti jaringan sesi tidak terputus
      Referensi: Immortal SSH Sessions

    • Saya sudah mencoba tmux puluhan kali, tetapi kurang cocok, jadi selalu kembali ke screen
      Namun setelah melihat tips ini, saya jadi ingin mencobanya sekali lagi

    • Dalam kombinasi vim, tmux, dan iTerm2, saya sering terbentur masalah warna dan font, dan akhirnya menyerah memakai tmux di lokal
      Keuntungan yang didapat, meski bisa bertahan dari update dan menjaga sesi tetap hidup, tidak terlalu besar
      Kalau masalah font saja bisa diatasi, saya bersedia mencobanya lagi, tetapi sekarang saya sedang kekurangan waktu

    • Saya penasaran apakah ada terminal Linux yang menyediakan integrasi dengan tmux seperti iTerm2
      Saya masih memakai GNU Screen, tetapi bersedia mencoba tmux sekali lagi

  • Melihat tulisan blog ini membuat saya sadar lagi kenapa saya memakai tmux
    Saat melihat orang harus melakukan banyak sekali pekerjaan untuk meniru alur kerja yang mirip tmux, rasanya jauh lebih baik langsung pakai tmux saja
    Kadang copy-paste memang agak merepotkan, tetapi saya tidak terlalu peduli
    Kritik bahwa 'multiplexer menimbulkan overhead yang tidak perlu' tidak perlu dipikirkan kecuali Anda adalah maintainer codebase

    • Masalah copy-paste bukan hanya masalah tmux
      Semua aplikasi yang menggambar seluruh terminal sendiri, seperti vim, bisa mengalaminya
      Ini bisa diselesaikan dengan mudah memakai terminal escape sequence OSC52
      Jika memakai skrip Python sederhana di bawah, hasil grep dan sebagainya juga bisa langsung dikirim ke clipboard sistem
      tmux dan nvim sudah mendukung OSC52, dan ini juga mudah dipakai di tempat lain

    • Sebagai catatan, saya pernah mengirim PR ke tmux, dan saya suka karena maintainer-nya, Nick Marriott, sangat enak diajak berkomunikasi
      Kodenya juga tertata rapi, dan tmux pun menjadi lebih baik

    • Saya lelah dengan diskusi yang terkesan memaksakan masalah yang sebenarnya tidak ada
      Alasan yang disampaikan penulis tidak terasa meyakinkan, dan malah membuat saya meragukan klaimnya tentang "pengalaman memakai tmux lebih dari 7 tahun"

  • Saya baru mengenal Tmux beberapa minggu lalu, dan langsung terpikat pada kemungkinan scripting untuk mengirim input tombol ke pane tertentu secara terprogram
    Terinspirasi dari sebuah forum Jepang, saya mulai bertanya-tanya apakah Claude Code (selanjutnya disebut CC) bisa berinteraksi langsung dengan skrip CLI yang memerlukan interaksi, dan saya memastikan hal itu bisa diwujudkan dengan Tmux
    Karena itu saya membuat alat kecil bernama claude-code-tools, agar agen CLI seperti CC bisa membuat pane Tmux, menjalankan skrip di dalamnya, dan bahkan berinteraksi secara real-time
    Rasanya seperti versi terminal dari Playwright atau Puppeteer
    Tautan GitHub claude-code-tools
    Dengan cara ini, CC bisa dipakai untuk menguji otomatis skrip CLI yang memerlukan interaksi, atau menampilkan UI di pane lain lalu menguji lewat browser dengan Puppeteer MCP, mengaktifkan debugger dan memasang breakpoint, menghubungkan multi-agent, dan banyak penerapan lain
    Saya penasaran apakah alat alternatif tmux juga bisa menghadirkan fleksibilitas seperti ini

    • Sebagai catatan, screen juga bisa mengirim input tombol ke pane secara terprogram lewat perintah "stuff"

    • Dengan pendekatan ini, Claude Code bisa mengendalikan berbagai instance CC seperti Gemini CLI dan OpenCode dalam mode interactive
      Ini memungkinkan bentuk integrasi yang berbeda dari sub-agent tradisional

    • Saya penasaran apakah wrapper tmux-cli benar-benar membantu meningkatkan hasil
      Saya cukup menyuruh Claude memakai perintah tmux yang sudah ada, dan itu bekerja dengan baik, jadi tanpa memakai Bash terpisah saya menjalankan semua perintah di dalam sesi tmux

    • Jika ingin melakukan hal seperti ini dengan lebih mudah di level terminal, fitur remote control milik Kitty juga keren
      Pengenalan Kitty Remote Control

    • Terminal pada dasarnya hanyalah file descriptor, jadi alat serupa seperti script(1), expect(1), dan chat(8) sudah ada sejak era 80-an
      Tidak harus tmux

  • Jika pengaturan TERM di tmux tidak dilakukan dengan benar, warna dan sebagainya memang tidak akan tampil sebagaimana mestinya, tetapi masalah yang sama juga terjadi di semua emulator/program terminal
    Di sistem Unix dan Linux, konsep TERM dan terminfo/termcap itu sendiri memang mendasar, jadi pengaturan yang benar itu wajib
    Ini bukan masalah yang khas tmux

    • Namun tetap disayangkan karena penulis menyalahkan tmux
      Soal scroll juga saya ragu itu memang masalah tmux sendiri, dan tmux memakai alternate screen buffer, yang diperkenalkan agar garis dasar viewport jelas sehingga pergerakan kursor lebih mudah
      Kebanyakan terminal modern mengizinkan scroll lokal bahkan saat alternate screen aktif, sehingga karakteristik ini tidak benar-benar dipatuhi

    • Kebanyakan program juga tidak akan berjalan sesuai maksud jika pengaturan default tidak benar
      Dalam kasus tmux, alasan 'kenapa'-nya memang tidak langsung terlihat sehingga terasa merepotkan, tetapi solusi apa yang tepat juga tidak jelas (misalnya: apakah default-nya sebaiknya 256colors?)

    • Itu benar, tetapi saat memakai tmux ada satu lapisan tambahan yang harus diperhatikan
      Di dalam tmux Anda harus memakai TERM khusus tmux, dan di luar tmux harus memakai TERM yang sesuai dengan terminal Anda sendiri
      Bahkan dari FAQ tmux saja terlihat bahwa sebagian besar masalah tampilan berasal dari TERM yang tidak diatur

  • Kritik bahwa "multiplexer memberi overhead yang tidak perlu" justru adalah alasan saya menyukai tmux
    Dalam situasi sekarang, ketika semakin banyak aplikasi meninggalkan dukungan termcap, keberadaan tmux membuat saya tetap bisa menjalankan aplikasi bahkan di terminal lama seperti VT520
    Saya tidak terlalu peduli terminal developer mana pun yang membenci tmux
    Pada akhirnya, dari sudut pandang pengguna, yang penting adalah semuanya bekerja dengan baik, bukan keanggunan arsitektur
    Sebagai catatan pribadi, saya rasa alacritty lebih baik (meski saya paling sering memakai Konsole)

    • Saya hanya ingin bilang saya iri Anda punya VT520
      Sudah lama saya mencari VT525, tetapi harganya mahal dan kebanyakan penjual ada di luar negeri
      Saya selalu penasaran apakah nosh realizer berjalan baik di genuine VT525
      Kalaupun tmux hilang, aplikasi dengan ketidakcocokan TERM yang halus masih bisa ditransliterasikan dengan cara lain

    • VT420 saya tidak mendukung hardware flow control, jadi saya harus memakai software flow control, dan metode ini kurang cocok dengan aplikasi terminal modern sekarang
      GNU Screen menjadi solusi yang sangat baik, selain juga punya berbagai fitur lain
      Saya banyak memakai tmux di emulator modern, tetapi di terminal lama sepertinya ia kurang pada fitur flow control penting ini
      Saya setuju bahwa tmux berguna untuk menangani aplikasi yang tidak mendukung termcap/terminfo

    • Saya penasaran kenapa Anda merasa alacritty lebih baik
      Di hardware lama startup-nya juga lambat, fitur praktis seperti tab pun kurang, dan bahkan hasil benchmark tertinggal dari kitty/ghostty/konsole/foot
      Meski begitu, menarik juga bahwa tetap ada orang yang memakai alacritty karena suatu alasan

  • Saya masih akan terus memakai tmux
    Saya menyukainya karena manajemen sesi antar banyak proyek dan pemulihan sesi setelah reboot jadi mudah
    mouse copy/paste sama sekali tidak bermasalah berkat tmux-yank
    Sudah bertahun-tahun saya memakai lingkungan yang sama
    Dengan fitur send-keys di tmux, saat merapikan dotfile saya membuat otomatisasi untuk memperbarui alias atau file konfigurasi sekaligus di banyak pane/sesi dan juga me-restart nvim dengan mudah
    Saya merangkum pengalaman ini di blog dan video

  • Bagi saya, "you might not need tmux" mirip dengan diskusi "you might not need browser tabs"
    Jika sesi terminal atau halaman web Anda hanya satu atau dua, mungkin memang tidak perlu, tetapi begitu harus menangani lebih dari itu, manajemen jendela jadi terlalu merepotkan dan akhirnya Anda mengulang implementasi fungsi yang sama

    • Akhir-akhir ini saya justru berusaha memaksimalkan fitur manajemen jendela dari window manager yang saya pakai
      Daripada browser tab, terminal tab, atau tmux, saya menyerahkan penataan jendela, manajemen tab, dan bookmark ke window manager, dan itu tidak terasa merepotkan

    • Saya makin merasa bahwa manajemen tab memang seharusnya menjadi urusan window manager, bukan aplikasi
      Window manager saya bisa menata jendela dalam bentuk tile, atau mengelompokkan jendela yang bertumpuk menjadi tab
      Tab-tab ini bisa dipakai tanpa peduli apakah aplikasinya sama atau berbeda

    • Browser tab bisa dengan mudah dipisah atau digabung menjadi jendela yang berbeda, tetapi tmux tab kurang fleksibel dalam hal ini
      Dengan window manager yang baik, tab dan jendela bisa disusun ulang dengan bebas

    • Di konfigurasi tmux saya ada tab yang bisa diklik

    • Manajemen banyak jendela di MS Windows (Alt Tab, Win Tab, dll.) sangat bagus
      Saya membedakan setiap terminal dengan ikon/warna latar yang berbeda, dan sistem operasi sendiri sudah menangani banyak hal dalam manajemen jendela
      Saya juga pernah memakai Mac, tetapi dalam hal ini rasanya tidak sememuaskan Windows

  • Hal-hal yang dikeluhkan tentang tmux, seperti buffer scrollback dan sebagainya, justru menjadi alasan saya memakainya
    Laptop kedua saya adalah terminal Debian lama khusus terminal, tanpa mouse, jadi copy/paste hanya bisa dilakukan lewat tmux
    Bagi saya tmux tidak tergantikan

    • Kombinasi tmux capture-pane - | vim - kadang terasa lebih nyaman daripada scroll wheel mouse

  • Kubu suckless mengambil pendekatan yang justru berlawanan: saat merancang terminal, mereka sengaja tidak mengimplementasikan fungsi seperti tmux
    Referensi: st.suckless.org/goals

    • Bisa dibilang suckless dan Kitty berada di dua kutub yang berlawanan dalam filosofi pengembangan

  • Saya berharap Kitty sukses karena terasa bisa memimpin masa depan emulator terminal
    Namun saya tidak bisa memakai Kitty untuk pekerjaan, dan tanpa tmux semua sesi, tata letak jendela, status, copy buffer, dan scrollback akan hilang, jadi saya benar-benar tidak bisa melepaskannya
    Sampai ada pengganti yang memadai di Windows, saya akan tetap memakai tmux untuk pekerjaan, meskipun di samping itu saya memakai Kitty

    • Saya juga sempat mencoba Kitty, dan terkesan karena saya bisa mereplikasi lingkungan yang mirip dengan konfigurasi tmux
      Namun pada akhirnya saya kembali ke kombinasi tmux dan terminal bawaan
      Karena bisa berjalan baik di mana saja, dan karena pendekatan menggabungkan beberapa alat cenderung lebih awet, tmux tetap yang terbaik bagi saya