Mengapa TUI Kembali Populer

• TUI kembali mendapat perhatian karena umpan balik yang instan, kemudahan otomatisasi, dan kemampuan berjalan lintas sistem operasi; alat seperti Claude dan Codex juga meraih sukses besar di command line
• GUI native di Windows, Linux, dan macOS masing-masing menambah beban bagi pengembang dan pengguna karena strategi API yang tidak stabil, fragmentasi toolkit dan lingkungan, serta melemahnya konsistensi terhadap pedoman lama
• Untuk aplikasi Electron, masalah yang lebih besar daripada penggunaan memori adalah kurangnya konsistensi visual dan celah dalam alur kerja yang berpusat pada keyboard; integrasi menu dan pintasannya juga melemah
• Ada upaya membuat stack UI baru seperti eksperimen Flutter UI dari Google dan GPUI milik Zed, tetapi renderer yang cepat saja tidak cukup jika integrasinya dengan sistem operasi kurang
• Antarmuka yang baik bertumpu pada konsistensi yang membuat pengguna tidak perlu banyak berpikir; pengembang serta pembuat sistem operasi dan toolkit perlu lebih banyak berinvestasi pada teori UI dan toolkit yang mudah diakses

---

Latar belakang TUI kembali mendapat perhatian

• Omarchy dari DHH disusun sebagai campuran TUI, web app, dan aplikasi native bergaya gnome, dengan TUI dipakai untuk umpan balik instan dan “geek points”
• Sekitar 10 tahun lalu, ada arus serupa pada editor kode
  • Terjadi perpindahan dari editor native seperti BBEdit, Textmate, Notepad++, dan Sublime ke aplikasi berbasis Electron seperti Atom, VSCode, dan turunannya
  • Pengguna dengan preferensi yang kuat beralih ke vim atau emacs, dan demi mendapatkan umpan balik instan serta kegunaan tinggi, mereka harus menerima kurva belajar yang sangat terjal

Mengapa GUI native melemah

• Windows

  • Windows gagal membangun strategi pustaka GUI yang konsisten, dan terus mengulang pola membuat API baru setiap kali satu API tidak berhasil
  • Dalam Microsoft hasn’t had a coherent GUI strategy since Petzold, Jeffrey Snover menggambarkan bahwa MFC, OLE, COM, dan ActiveX menyebarkan kompleksitas ke seluruh pengembangan Windows
  • Setelah itu Microsoft melewati WinForms, WPF, Silverlight, WinUI, dan MAUI, tetapi tidak berhasil; banyak aplikasi desktop enterprise maupun personal masih bergantung pada aplikasi Electron
  • Periode terakhir ketika seluruh Windows terasa terintegrasi secara visual dengan konsisten mungkin adalah era Windows 98 atau Windows 2000
  • Dalam Windows Native App Development Is a Mess, Domenic Denicola menilai biaya membangun ulang OS dan API UI setiap beberapa tahun sangat besar, dan ketika ini bertabrakan dengan upaya sandboxing serta penghentian fitur, setiap lapisan baru menimbulkan celah yang membuat hal-hal yang dulu bisa dilakukan di framework lama menjadi tidak bisa lagi

• Linux

  • Ketidakselarasan UI di Linux lebih merupakan hasil desain, karena tim-tim yang berbeda diberi kebebasan mengejar tujuan yang berbeda
  • GTK dan Qt menjadi framework utama, dan keduanya menargetkan pengembangan native lintas platform, meski area penggunaan terluasnya terutama di Linux
  • Aplikasi Linux yang dibuat dengan toolkit berbeda masih bisa terlihat cukup serasi saat diletakkan berdampingan, tetapi berbagai framework di Windows tidak mencapai tingkat harmoni seperti itu
  • Karena kombinasi distro, desktop environment, dan perangkat keras terlalu banyak, pengujian menjadi sulit sehingga banyak perusahaan tidak membuat aplikasi Linux native
  • Perusahaan biasanya mendukung Linux lewat Electron, atau membiarkan komunitas open source menyelesaikannya sendiri jika tersedia API publik

• macOS

  • Human Interface Guidelines dari Apple pernah menjadi standar kuat sampai dikutip dalam kelas-kelas antarmuka pengguna di seluruh dunia
  • Xerox PARC dan Apple sering disebut sebagai institusi perwakilan yang meneliti seperti apa antarmuka manusia yang baik
  • Belakangan ini Apple bergerak ke arah yang merusak konsistensi dengan pedoman masa lalunya
  • macOS bergerak ke arah mengabaikan Hukum Fitts, membuat pengubahan ukuran jendela nyaris mustahil, tetap bermasalah bahkan setelah mencoba memperbaikinya, dan menambahkan ikon ke semua menu
  • macOS tidak lagi mudah dipandang sebagai tempat aman bagi desainer untuk bekerja dengan tenang

Keterbatasan aplikasi Electron

• Masalah yang paling sering disebut adalah penggunaan memori, tetapi selama 10 tahun terakhir penggunaan memori justru cenderung menurun
• Masalah yang lebih besar adalah kurangnya konsistensi visual dan minimnya alur kerja yang berpusat pada keyboard
• Bahkan di lingkungan dengan MacBook Pro RAM 64GB, Dock tetap berisi 8 aplikasi native dan 6 aplikasi Electron berdampingan
  • Aplikasi native: TextMate dan utilitas sistem macOS
  • Aplikasi Electron: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
• Di aplikasi seperti Cursor dan VSCode, setelah meminta fitur di panel agen, berpindah hanya dengan keyboard ke daftar agen di panel samping atau mengarsipkannya tidak terasa alami
• Perilaku seperti ini seharusnya bisa dilakukan dengan cara yang sama di semua aplikasi macOS, tetapi bahkan jika ada shortcut, kadang ia tidak ditampilkan di menu
• Selama 10 tahun terakhir, pengembang cenderung melupakan penambahan ke menu untuk tindakan-tindakan yang tersedia di aplikasi, dan ini berkaitan dengan struktur implementasi aplikasi sebagai HTML di dalam sandbox
• Slack menangani hal-hal seperti ini lebih baik daripada aplikasi Electron lain, tetapi tetap belum sempurna

Upaya membangun ulang stack UI baru

• Google ingin membuat sistem operasi baru tanpa warisan Android beserta toolkit UI untuk perangkat baru, bersama Dart
• Google menginginkan toolkit UI baru bernama Flutter UI, tetapi proyek itu ditinggalkan sebelum produk nyatanya diluncurkan
• Upaya seperti ini hanya bisa berhasil jika ada posisi dominan atau pangsa pasar yang cukup besar
• Zed mengambil arah serupa dengan Rust dan membuat pustaka renderer GPU sendiri bernama GPUI, yang menargetkan lintas platform
• GPUI memang cepat, tetapi integrasinya dengan sistem operasi host tidak cukup memadai dengan sendirinya, sehingga pengembang harus menambahkan binding yang diperlukan secara manual
• Renderer yang lambat tetapi terintegrasi baik dengan sistem operasi lebih baik daripada renderer cepat

Celah yang diisi oleh TUI

• Dalam konteks yang mengingatkan pada kemunduran Apple Automator, TUI kembali penting sebagai antarmuka yang bisa diotomatisasi
• TUI juga relatif mudah dijalankan dari jarak jauh, tanpa harus bergantung pada X forwarding yang memicu banyak sakit kepala
• Ketika toolkit UI native gagal, orang kembali ke dasar, dan akibatnya TUI muncul sebagai pilihan
• Claude dan Codex meraih sukses besar di command line, dan pengguna bisa fokus pada interaksi itu sendiri alih-alih memikirkan sistem operasi di sekelilingnya
• Melalui TUI, pengguna bisa menangani kode dan aplikasi di mesin cloud, atau terhubung jarak jauh dari iPad ke mesin yang memiliki GPU
• TUI mengisi celah yang ditinggalkan Apple dan Microsoft di lingkungan tempat setiap aplikasi terlihat berbeda-beda
• Tampilan yang saling berbeda mungkin baik untuk seni atau game komputer, tetapi tidak cocok untuk tujuan ketika antarmuka seharusnya menyingkir agar pengguna bisa menyelesaikan pekerjaannya

Arah yang dibutuhkan ke depan

• Dalam Bring Back Idiomatic Design, John Loeber berpendapat bahwa bahkan checkbox adalah antarmuka untuk berinteraksi dengan sistem, dan antarmuka yang baik adalah yang membuat pengguna berpikir lebih sedikit
• Karena pengguna berinteraksi dengan banyak hal, mereka membutuhkan antarmuka yang homogen yang memberi pengalaman konsisten
• Jika Command+C adalah shortcut untuk menyalin, itu harus bekerja di mana pun; pendekatan yang memaksa pengguna mengingat CTRL+Shift+C atau klik kanan → salin dalam situasi tertentu terasa tidak nyaman
• Semua pengembang perlu mempelajari teori yang membuat bukan hanya software, tetapi antarmuka pengguna secara umum menjadi lebih baik
  • Nielsen
  • Norman
  • Johnson
• Sikap yang memperlakukan desain pengguna sebagai soft skill yang tidak penting dalam kurikulum rekayasa perangkat lunak harus dihentikan
• Dalam proses apa pun, jika UI tidak dipahami, proyek itu harus dianggap gagal; dalam mata kuliah HCI, targetnya harus berupa UI yang sempurna
• Pekerjaan membuat UI yang baik sebagian besar menghabiskan upaya untuk memahami kebutuhan, sementara pemrograman itu sendiri sudah makin terotomatisasi
• Pembuat sistem operasi dan toolkit perlu mendorong investasi untuk membuat toolkit yang mudah diakses dan ingin dipakai oleh pengembang, serta menurunkan hambatan masuk
• Ini bukan berarti harus selalu menuntut dukungan lintas platform, tetapi jika ada setidaknya satu solusi seperti itu, ketergantungan pada Electron dan TUI bisa dikurangi

[colus001]

Saya juga merasa begitu, tetapi menurut saya dunia developer terlalu sensitif terhadap tren. TUI pada dasarnya hanya didorong oleh perusahaan-perusahaan yang tidak punya kemampuan atau kemauan untuk membuat GUI dengan baik, dan saya tidak tahu sebenarnya ada berapa banyak orang yang memakai TUI.

[GN⁺]

Komentar Hacker News

• Jika melihat angkanya saja, alasan sebenarnya TUI populer adalah Claude Code, dan sisanya relatif hanya seperti noise latar
  Pertama kali saya ingin membuat TUI adalah karena konsep mendistribusikan aplikasi lewat SSH. Aplikasi SSH mirip browser dalam hal tidak memerlukan instalasi lokal
  Salah satu alasan besar saya senang bermain-main dengan https://pico.sh juga karena distribusi TUI sama sekali tidak membutuhkan campur tangan pengguna

  • Sepertinya bukan itu. Titik ketika program TUI baru mulai bertambah tampaknya terjadi sebelum Claude Code benar-benar naik daun
  • Memang benar Claude Code memperbesar tren itu sampai seratus kali lipat, tetapi sejak era go fzf, Rust ratatui, dan Python Rich, TUI sudah meningkat pesat
    Mungkin penyebabnya adalah keinginan untuk lepas dari UI berbasis browser yang berat, serta rasa penasaran untuk menguji batas rendering terminal
  • Saya paham gagasan mendistribusikan aplikasi lewat SSH, tetapi agak disayangkan emulator mesin tik port serial masih bertahan sampai sejauh ini
    Alih-alih membangun sistem baru dengan teknologi yang baru dan menarik, kita malah membuat emulator mesin tik berakselerasi GPU. Bentuk aneh dari campuran nostalgia dan kebutaan teknis
    Protokol apa pun bisa dialirkan lewat SSH. Saya malah ingin melihat arahnya menuju menggambar ke display bitmap jarak jauh
    X Window memang tidak didesain dengan sempurna, tetapi punya transparansi jaringan, dan devdraw milik Plan 9 adalah mesin rendering tempat program grafis jarak jauh mengunggah aset lalu mengirim perintah menggambar garis lewat RPC
  • Motivasi untuk tetap ingin memakai aplikasi TUI alih-alih CLI murni atau GUI masih tetap karena bisa dipakai lewat SSH
  • Saya penasaran apakah maksudnya alasan TUI populer adalah karena semua orang ingin meniru Claude Code, atau karena Claude Code membuat pengembangan TUI jadi lebih mudah

• Hal yang benar-benar sulit dalam vim cuma satu: untuk kembali ke mode perintah, yang merupakan inti editor modal, jari harus menjangkau Escape
  Alur idealnya adalah mengedit dengan cepat lalu langsung kembali ke mode perintah, jadi penggunaan Escape itu perlu disadari sebagai sisa sejarah
  Karena itu cukup remap CapsLock menjadi Escape secara global. Di Linux dan macOS ini bisa dilakukan hanya lewat pengaturan GUI, dan di Windows pun cukup membuat atau mengubah kunci registry, selesai dalam 1 menit
  Selain itu, dasar-dasarnya bisa dipelajari lewat vim-tutor, lalu tinggal cari saat muncul tugas yang memakan waktu, jadi saya kurang paham sebenarnya letak learning curve-nya di mana. Masalahnya justru kita terlalu cepat terbiasa dengan pengeditan modal sampai lingkungan yang tidak punya itu terasa seperti zaman batu

  • Kalau harus sering berpindah kerja antar banyak laptop, meremap CapsLock menjadi Escape jadi gesekan yang cukup besar. Muscle memory terus mengganggu
  • Saya belum pernah melihat orang yang sudah mengganti CapsLock menjadi Escape lalu kembali lagi. Rasanya benar-benar berbeda
    Belakangan ini saya merasa alasan vim masih butuh hjkl sebenarnya karena layout keyboard buruk untuk tombol panah. Mesin tik dulu tidak punya tombol panah, tetapi di komputer tombol panah itu inti
    Spacebar juga tidak perlu sebesar itu dan tidak ada alasan kedua ibu jari harus memakainya. Akan jauh lebih baik jika satu kelompok kecil tombol panah dipindahkan ke sebagian sisi kiri atau kanan spacebar
    Hack hjkl hanya berlaku di editor untuk hacker, tetapi di software umum pun kita sering perlu tombol panah, dan layout sekarang sangat buruk untuk tangan. Saya mulai mengalami peradangan karena berusaha menekan tombol panah dengan ibu jari tanpa memindahkan seluruh tangan
  • Anehya, Esc yang letaknya jauh justru saya suka bukan karena efisiensi melainkan secara ergonomis
    Itu memaksa tangan terangkat, keluar dari home position, lalu kembali lagi, sehingga mengurangi akumulasi poin RSI yang sebaliknya akan menumpuk
    Karena alasan yang sama, tangan satunya juga sering memakai tombol panah. Tentu saya juga cukup sering memakai hjkl
  • Kalau di Windows, PowerToys punya alat remap keyboard yang lumayan bagus
    https://github.com/microsoft/PowerToys
  • Karena jari sudah ada di home position, cukup map ke jj dan selesai
    Lalu Ctrl + [ adalah Esc dalam terminal/ASCII standar, jadi mungkin sedikit lebih nyaman daripada menjangkau Esc

• Reruntuhan sisa setelah vendor sistem operasi merusak kepentingan mereka sendiri kini terlihat seperti tren TUI
  Tidak ada satu pun UI umum yang benar-benar bagus. Browser yang paling mending dan cukup sukses, tetapi karena sandbox, ia tidak cocok atau menimbulkan gesekan besar untuk hal-hal yang perlu akses file lokal atau jaringan. Overhead-nya juga kelewat besar hanya untuk menjalankan sesuatu yang sederhana
  Akses jarak jauh lebih kacau lagi. Muncul masalah seperti apakah aplikasi yang berjalan di host Windows bisa diakses dari Mac, apakah bisa diteruskan lewat koneksi tunnel, dan semacamnya
  TUI adalah protokol umum yang sederhana dan melakukan hal yang dibutuhkan, dengan sifat remote sebagai bawaan. Apa yang dipakai lokal juga bekerja secara alami di atas koneksi SSH
  Ini juga semacam jari tengah besar untuk vendor sistem operasi yang mengira strategi terbaik adalah membuat semuanya tidak kompatibel atau mengunci pengguna ke dalam ekosistem

  • TUI mudah dipahami pengguna, efisien bukan hanya dari sisi sumber daya tetapi juga pengoperasian, dan di terminal yang bagus juga enak dilihat
    Notcurses dan Ratatui sangat membantu ncurses
  • Saya terus kembali ke lingkungan desktop minimalis seperti xfce4 karena lingkungan GUI modern yang absurd telah gagal
    Windows 11 adalah contoh yang sangat bagus, dan semua sensasi berlebihan itu benar-benar tidak perlu

• Saya berharap TUI tidak kembali populer. Kapan pun, saya akan memilih antarmuka web daripada TUI
  Tidak perlu memasang font yang kelewat pintar, tidak perlu mengutak-atik pengaturan terminal agar tampil benar, dan tidak perlu menebak shortcut navigasi yang dianggap terbaik oleh pembuatnya
  Ada juga pengeditan teks sungguhan dengan navigasi teks standar sistem operasi, integrasi yang lebih baik dengan password manager dan text expander, dan sebagainya
  Saya hidup di dalam CLI dan bisa membuka terminal dengan satu shortcut, tetapi teknologi sudah berkembang jauh sejak masa terminal adalah satu-satunya pilihan, dan sekarang ada banyak opsi yang lebih baik untuk membuat UI

  • Antarmuka web juga tidak lebih baik. Ia dirancang demi estetika ketimbang fungsi, dan masing-masing punya idiom UI unik yang harus dipelajari
  • Saya sudah memakai vim dan Emacs selama puluhan tahun, tetapi sejak pindah ke GUI beberapa tahun lalu saya sama sekali tidak ingin kembali
    Seluruh tren TUI ini menurut saya cuma tren mode

• Karena tidak ada yang berinvestasi dalam pengembangan UI native. Electron adalah bukti bahwa jika ada stack GUI yang mudah dipakai, perusahaan akan mengadopsinya

  • Tulisannya mengatakan Google menyerah sebelum merilis produk nyata, tetapi menurut saya pekerjaan pada Flutter masih terus berjalan dan adopsinya juga meningkat
  • Saat membuat utilitas kecil, misalnya alat untuk mencari file dengan regex, di situlah paling buruk
    Kalau aplikasinya besar, waktu untuk packaging dan distribusi adalah bagian kecil dari keseluruhan dan ukuran file juga tidak terlalu dipikirkan, tetapi aplikasi kecil tidak begitu
    Aplikasi Windows mudah: biner kecil membuka form, bisa dijalankan dengan double-click, dan tidak perlu instalasi
    Untuk melakukan hal yang sama di Linux, tidak ada jaminan GTK atau Qt terpasang, jadi untuk membuatnya stand-alone pada praktiknya harus mengirim hampir seluruh OS bersama aplikasinya. Akibatnya ukuran file membengkak
    Python juga merepotkan untuk pengguna Windows karena mereka harus punya Python atau interpreter-nya harus ikut dibundel
    Alternatif yang agak mungkin adalah model seperti Java dengan satu file .jar yang bisa dijalankan di sistem mana pun, tetapi Oracle mengubah lisensinya dan JavaFX tidak lagi disertakan dalam Java. Swing masih disertakan
    Saya cuma ingin menampilkan menubar dengan shortcut keyboard, tetapi saya tidak mengerti kenapa tidak ada semacam VM menubar yang memberi akses ke menubar di semua sistem operasi
    Mengirim seluruh browser dengan Electron itu konyol. Seharusnya pengguna memasang platform seperti versi desktop dari aplikasi Flash, lalu semua aplikasi memakainya
    Mungkin malah lebih mudah mendistribusikan game DOS daripada aplikasi desktop. Orang yang ingin menjalankan game DOS kemungkinan sudah memasang emulator DOS
  • Bukan kurang investasi, melainkan lebih dekat ke tidak ada yang membuat sesuatu yang layak
    Yang dibutuhkan adalah framework yang mudah dipakai, lintas platform, open source, dan kalau bisa bisa dipakai dari bahasa pemrograman pilihan
  • Zed benar-benar melakukan itu. Memang ada penggemarnya, tetapi mengingat besarnya upaya untuk membangun sistem GUI dari nol, adopsinya tampaknya tidak meledak
  • wxWidgets dan Qt bukannya lumayan ya. GTK 2 dan 3 juga lumayan, meski 4 ke atas agak kurang. Ada banyak aplikasi yang memakai salah satunya, dan pemakaian lewat binding Python juga umum
    Masalah yang lebih besar adalah tenaga kerja. Karena orang yang paham pengembangan web jauh lebih banyak, perusahaan ingin memakai tenaga itu juga untuk desktop, dan kalau desktop-nya JavaScript lewat Electron itu jauh lebih mudah

• Saya kurang paham terminal UI yang berusaha membangun ulang fitur seperti GUI. Bukankah antarmuka komputer seharusnya makin baik
  Sekarang kita tidak perlu lagi dibatasi kisi karakter hanya untuk pura-pura menggambar garis dan bentuk. Tanpa terminal nonstandar seperti Kitty atau iTerm, bahkan menampilkan gambar pun tidak bisa
  Sangat disayangkan tidak ada sistem UI streaming lintas platform yang benar-benar bagus. Web lumayan hebat dengan caranya sendiri, tetapi jelas seharusnya ada sesuatu yang lebih baik untuk tujuan ini. Flutter lumayan, tetapi kurang on-demand dan terlalu terikat pada Dart

  • Ini karena kegagalan lingkungan GUI modern
    Orang sebenarnya menginginkan GUI, tetapi akhirnya harus memutar lewat sesuatu yang mirip GUI di dalam TUI
    Mereka ingin sesuatu yang portabel, bisa dijalankan jarak jauh, lebih aman dijalankan tanpa mengekspos socket, dan tidak perlu mengangkat seluruh desktop
    Window tanpa root pada dasarnya sudah mati, dan yang tersisa hanya antarmuka web beserta semua masalahnya, atau TUI yang cukup butuh koneksi SSH yang semua orang sudah punya
    Dulu kita bisa asal bikin pakai Tcl/Tk lalu memunculkan jendela lewat X Window, tetapi sekarang tidak semudah itu dan tidak ada yang memakai remote X lagi
    Lowest common denominator-nya adalah SSH, jadi yang bertahan hanya hal-hal yang cocok dengannya
  • Soal menampilkan gambar, Sixel didukung banyak terminal[0]
    Beberapa terminal yang disebut tidak mendukung juga berbasis GNOME VTE, dan dukungan di sana sedang dikerjakan; jika melihat bug tracker, sepertinya hampir selesai
    Bahkan xterm, yang paling dekat dengan terminal standar di X11, juga termasuk di sini
    [0] https://www.arewesixelyet.com/
  • TUI itu mudah untuk menuntaskan pekerjaan. Begitu membuat GUI yang benar, codebase tiba-tiba jadi jauh lebih rumit
    Tidak ada toolkit GUI yang benar-benar kokoh dan bisa diandalkan, semuanya penuh bug dan hal-hal yang perlu diwaspadai, masing-masing berbeda
    Flutter memang katanya lumayan, tetapi itu mengabaikan kenyataan bahwa proses build aplikasi Flutter sendiri adalah mimpi buruk. Flutter sendiri juga tidak terasa dirancang agar siapa pun bisa mengompilasikannya; pada praktiknya distribusilah yang menutupi masalah itu
  • Sistem UI streaming lintas platform bisa saja disebut web/Jupyter
    Dan UI berbasis web juga tidak harus berat. HN contohnya tidak begitu
  • Di atas SSH, teks lebih cepat. Menggambar ulang grafik seperti RDP atau VNC dalam jangka panjang lebih lambat dan lebih merepotkan

• Walaupun saya selalu membuka terminal, mengotomatisasi hidup dengan skrip Bash, dan memakai VIM/TMUX, kebanyakan TUI tetap tertinggal dua langkah dari GUI yang bagus
  Navigasi dan shortcut yang semaunya sendiri, copy-paste yang rusak, dan integrasi lingkungan yang buruk adalah contoh utamanya
  Masalah intinya adalah tidak ada platform GUI lintas platform yang bagus yang terintegrasi dengan baik ke bahasa pemrograman atau menjadi bagian dari standard library
  Swing kurang dalam akses ke elemen browser native, Tk kurang komponen browser dan drag-and-drop, wxWidgets komunitasnya kecil dan binding-nya tampaknya pernah harus dihidupkan kembali lebih dari sekali
  Qt sewaktu-waktu bisa dirusak demi mencari lebih banyak uang, saya juga tidak menganggap KDE sedemikian penting, dan saya ragu komunitas KDE bisa menanggung fork dalam jangka panjang
  Yang tersisa adalah Electron atau turunan yang menumpuk JavaScript/CSS di atas komponen browser dan menempelkan callback server lokal; selain overhead memori dan runtime yang besar bahkan untuk aplikasi sepele, model pemrogramannya sendiri juga buruk
  Untuk membuat toolkit GUI lintas platform yang layak dibutuhkan banyak uang dan orang untuk usability, accessibility, desain, dokumentasi, dan pengujian. Komunitas open source gagal mewujudkannya, GTK praktis menjadi Linux-only, dan tidak ada kandidat modern untuk menggantikan Qt atau Swing
  TUI bukan solusi untuk masalah inti itu, tetapi melihat alternatif yang ada, saya paham kenapa pengembang memilih TUI untuk UI lintas platform. Mungkin sekitar 80% kebutuhan GUI sebenarnya sudah cukup dengan toolkit GUI yang punya renderer TUI

  • Ini seharusnya disediakan sebagai C API, bukan bahasa pemrograman
    Dengan begitu bisa menyediakan API dan ABI yang stabil, dan binding ke banyak bahasa lain bisa dilakukan tanpa jalan memutar yang rumit. Ini terutama lebih penting untuk bahasa terkompilasi
    Mengikat Qt ke Python mungkin mudah, tetapi untuk bahasa seperti Free Pascal perlu library C++ perantara yang mengekspos C API, dan aplikasi harus ikut mendistribusikan library itu
    Sayangnya kebanyakan toolkit GUI ditulis bukan dalam C melainkan C++ atau bahasa lain, sehingga menyakitkan dipakai kalau itu bukan bahasa yang disukai pengembang. Hampir satu-satunya yang arus utama dan ditulis dalam C adalah GTK, tetapi GTK nyaris tidak peduli pada kompatibilitas mundur yang layak
    Kita bisa saja berpikir library boleh ditulis dalam bahasa apa pun asal hanya mengekspos C API, tetapi untuk sesuatu yang tidak tersebar luas, kita mungkin ingin static linking. Di luar C/C++, ini jadi masalah
    Misalnya saya pernah mencoba membuat backend FLTK untuk Lazarus[0], karena FLTK adalah library C++ dan menganjurkan static linking sehingga tampak mungkin membuat biner GUI mandiri
    Tetapi saya harus lebih dulu membuat wrapper C, dan di Linux, melakukan static link library C++ dari bahasa non-C/C++ tanpa magic flag yang diteruskan g++ ke linker itu menyakitkan, sedangkan di Windows atau setidaknya msys2, itu tidak mungkin, jadi saya menyerah
    [0] https://i.imgur.com/W6XbLkr.png
  • Sebagian besar saya setuju. Terutama wxWidgets, benar-benar disayangkan
    Di macOS dan Windows tampilannya sangat dekat dengan native, dan jauh lebih mudah diprogram daripada Qt. Baik sebagai pengguna maupun kadang sebagai programmer, untuk GUI multi-platform saya paling suka wxWidgets
    Sebaliknya, kombinasi Electron atau komponen browser dengan JavaScript/CSS dan callback server lokal benar-benar saya benci sebagai pengguna. Bahkan kalau harus mengorbankan fitur dan kembali ke command line pun saya ingin menghindari aplikasi seperti itu
    Shortcut keyboard standar sering tidak didukung, tampilannya aneh dan menonjol, dan kadang lag di tempat yang tak terduga
    Di antara framework TUI, ada beberapa yang hampir sampai ke level itu. Menyenangkan juga bahwa itu bisa dipakai lewat SSH dan semacamnya tanpa banyak usaha, tetapi rasanya mereka memecahkan masalah yang salah
    Daripada membuat semuanya terlihat atau bekerja seperti IDE, saya lebih ingin CLI yang lebih terfokus dan composable, bersama sesuatu seperti tmux untuk pengelolaan jendela dan persistensi yang tidak seburuk sekarang
    Kalau membuat REPL sederhana dengan readline, kita mendapat perilaku yang standar dan bisa diprediksi
    Meski begitu, saya suka bahwa tren ini mendorong perbaikan emulator terminal

• TUI yang saya lihat kebanyakan tampaknya bergantung pada NPM
  Rasanya aneh, seolah para agen bahkan tidak punya waktu untuk menulis ulang dirinya sendiri menjadi sesuatu yang bukan kebakaran ban keamanan
  Seluruh tren bahwa semua agen ini akan menguasai sesuatu pada akhirnya membuat saya berpikir ini cuma dibuat oleh orang startup sampah-masuk-sampah-keluar yang hasil terburuknya pun tidak perlu dikhawatirkan selain karena tidak cukup cepat

  • 99% software di sekitar LLM tetap berupa sampah web yang goyah dan rusak
    Misalnya OpenCode sampai sekarang bahkan belum bisa melakukan hal paling dasar, yaitu mempertahankan semua log pesan dan mengirim log itu ke endpoint SSE dalam urutan yang sama untuk mendapatkan respons berikutnya, dan bahkan saat context pruning dimatikan pun prompt cache miss masih sering terjadi
  • Go + Lipgloss + Bubbletea adalah stack yang paling kokoh dan berperforma baik untuk membuat atau menghasilkan TUI yang terlihat bagus dan bisa dipakai
    Developer experience-nya juga hebat dan tidak perlu npm
  • Ah, masa damai keamanan ketika semuanya berjalan lewat curl | bash
  • Benar. Orang-orang yang bersemangat memasukkan AI ke segala hal hampir semuanya pengembang JavaScript/TypeScript, biasanya bekerja di startup, dan sering memang di bidang AI juga

• Aneh bahwa perancang antarmuka pengguna dibiarkan menjadi software developer
  Mereka tampaknya tidak mampu membuat antarmuka pengguna yang bukan teks. Ibarat tukang ledeng mendesain rumah lalu memiringkan semua lantai ke bawah agar pipa lebih mudah dipasang
  Kalau harus memindahkan dan mengubah ukuran banyak jendela, mereka membuat jendela teks; kalau harus cepat memilih opsi, mereka membuat kotak teks; kalau harus cepat menulis dokumen dengan gaya dan format, mereka malah membuat orang menulis lebih banyak teks demi pemformatan
  Tetapi mereka justru tidak membuat aplikasi yang memudahkan melihat teks itu dalam keadaan sudah terformat

  • Dibiarkan bagaimana, kebanyakan proyek TUI open source seperti ini dimulai oleh individu atau tim kecil yang sedang mencoba menyelesaikan masalah mereka sendiri
    Mereka bebas melakukannya, dan kalau tidak suka ya tidak usah dipakai
  • Di ujung sebaliknya ada Material dan sampai batas tertentu Adwaita
    Terlihat cantik, tetapi hampir tidak berguna untuk pekerjaan yang rumit melampaui pengembangan gaya aplikasi atau sekadar file manager
  • Saya tidak mengerti maksudnya. Beri developer design system yang layak dan mereka bisa membuat sesuatu yang cukup baik

• TUI bagus bagi orang yang hidup di dalam terminal
  Tidak ada gangguan dari konten visual, sangat efisien dengan keyboard, dan sekarang AI bisa membuatnya dengan cepat. Dulu ini benar-benar menyakitkan

  • Fakta bahwa AI bisa membuatnya dengan cepat adalah alasan terbesar, bahkan bisa dibilang satu-satunya alasan
  • Konsekuensinya adalah makin banyak orang terbiasa hidup di dalam terminal
    Karena audiens TUI bertambah, TUI juga jadi lebih umum
  • TUI tidak punya ruang untuk padding tanpa akhir demi tampilan yang halus dan modern
    Dalam teks 80 kolom, hampir tidak ada juga yang bisa “disederhanakan” oleh manajer produk

[savvykang]

Bukankah ada yang salah dengan situasi ketika tak satu pun big tech meninggalkan browser?

[GN⁺]

Komentar Lobste.rs

• Aku lebih berharap orang-orang membuat aplikasi native saja. TUI terlihat seperti gabungan kelemahan antarmuka baris perintah dan GUI sungguhan
  Semua program TUI harus mengimplementasikan ulang scrolling sendiri, jadi meskipun terminal mendukung scrolling per piksel, program TUI tetap hanya mendukung scrolling per baris dan perilakunya pun berbeda-beda. Scrollback di senpai berbeda dari program lain yang kupakai, jadi aku sering kehilangan arah
  Juga tidak ada cara untuk memberi tahu terminal bahwa antarmukanya lebih dari satu panel teks tunggal, jadi pemilihan teks sering rusak. Bisa saja dengan mencegat event mouse, tapi itu juga tidak terlalu bagus. Di klien IRC TUI, aku harus menekan shortcut untuk menyembunyikan panel-panel samping yang tidak relevan hanya agar bisa memilih teks, dan itu terasa seperti prosedur yang cukup bodoh
  Batasan harus mengikuti grid sangat membatasi kemungkinan tata letak dan desain. Aku jadi teringat gaya yang dibuat agar tampak seperti tombol yang bisa diklik, atau hal-hal seperti menu konteks. Dulu aku juga pernah mengeluhkan masalah ini
  Menurutku bertambahnya TUI adalah akibat yang disayangkan dari buruknya kondisi framework GUI tradisional. Framework TUI relatif stabil, dan bahkan yang sangat tua pun tidak terlalu mengganggu untuk dipakai. Program ncurses masih sering kupakai sampai sekarang, tetapi sulit membayangkan orang masih memakai program Motif
  Sebaliknya, framework GUI tidak punya banyak pilihan dan butuh pemeliharaan yang jauh lebih besar. Lingkungan desktop berubah, dan ekspektasi terhadap GUI juga terus naik. Menurutku aksesibilitas TUI benar-benar buruk, walau aku tidak sepenuhnya yakin. Perubahannya juga terlalu cepat: bikin dengan GTK2 lalu dinyatakan usang, naik ke GTK3 lalu disuruh pindah ke GTK4, dan pola itu terus berulang
  Kalau dilihat sinis, ada faktor lain juga pada hal seperti Omarchy. GUI biasa seperti xfce4-taskmanager itu membosankan, tetapi TUI seperti btop terlihat sangat hacker banget. Orang suka estetika terminal (lihat /r/unixporn), dan tampaknya rela mengorbankan kegunaan demi vibes. Lihat saja btop yang benar-benar membuat daftar proses memudar

  • Setelah lama berkutat di pengembangan web, aku ingin mencoba pengembangan aplikasi native. Aku sempat melihat-lihat untuk membuat aplikasi GNOME, tetapi cukup kecewa karena terasa sangat berpusat pada C++
    Aku berharap sekarang hambatan masuknya sudah lebih rendah. Dalam situasi ketika kebanyakan developer dilatih dengan bahasa tingkat tinggi, itu terasa kurang meyakinkan, dan kompleksitas C++ tampaknya memang membuatku ciut
  • Sedikit menyimpang, tapi aku tidak mengerti kenapa banyak klien chat membuat riwayat jadi berantakan saat disalin-tempel. Di Discord, misalnya, hasilnya jadi seperti ini
    [
    20:41
    ]
    username1
    :
    message1
    [
    20:42
    ]
    username2
    :
    message2
    Klien Matrix Nheko bahkan tidak mengizinkan memilih lebih dari satu baris sekaligus
    Sementara klien IRC biasanya memberikan format seperti ini secara default
    20:41 <username1> message1
    20:42 <username2> message2
  • Aku suka antarmuka baris perintah, tapi aku juga kurang suka TUI. Ada tempatnya, tetapi pada dasarnya lebih mirip GUI yang kasar dan jelek, dan sering membuang ruang terminal
    Kadang memang masuk akal, tetapi idealnya sebaiknya dipakai hanya untuk aplikasi yang kecil dan dipakai sebentar atau pengecualian seperti editor teks
  • Kurasa TUI memang agak lemah, tetapi dibanding toolkit UI seperti gtk, ini tetap pilihan yang tidak terlalu buruk. Aplikasi TUI yang kusukai punya ekstensibilitas bagus, responsif, dan terintegrasi baik dengan baris perintah Linux
    Misalnya lf, tig, kakoune cocok sekali dengan shell script, jadi skrip yang sama bisa dipakai ulang dan fungsinya bisa diperluas di ketiga aplikasi itu. Karena semuanya berjalan di alacritty, aku juga bisa membuat hyperlink yang bekerja di ketiga aplikasi itu dan di seluruh shell
    Kalau boleh berandai-andai, aku ingin ada toolkit GUI minimalis monokrom yang memungkinkan integrasi ala Emacs atau acme
  • Secara umum aku setuju, tetapi aku ingin menekankan bahwa Tk diam-diam tetap berjalan dan masih berguna sampai sekarang. gitk adalah salah satu contohnya

• Aku tidak paham bagaimana TUI disebut “mudah diotomatisasi”. Bukankah itu pada dasarnya GUI yang ditampilkan di konsol?

  • Banyak TUI menyediakan flag yang bertindak seperti bahasa skrip saat program dibuka. Selain itu, bagi LLM, berinteraksi dengan antarmuka berbasis teks lebih mudah dan lebih murah daripada dengan GUI native yang benar atau aplikasi Electron bergaya JavaScript

• Tulisan ini melewatkan alasan utama TUI “kembali”. Klaim itu sendiri juga meragukan, tetapi memang tampaknya popularitasnya belakangan naik karena agen coding seperti Claude dipakai untuk vibe coding dalam jumlah besar
  Developer menyukai pilihan yang mudah. Membuat TUI lintas platform lebih mudah daripada membuat GUI
  Alasan aplikasi web menjadi populer juga sama. Karena lebih mudah membuat aplikasi lintas platform dengan alat browser, dan alasan Electron naik daun juga masih dalam konteks yang sama, hanya tanpa beban dukungan lintas browser. Membuat UI responsif, merender UI lintas platform, dan menangani input pengguna terutama dengan mempertimbangkan aksesibilitas, semuanya sulit. Jadi developer langsung tertarik pada apa pun yang membuat hal-hal itu jadi mudah
  Belakangan ini juga ada perubahan yang membuat pembuatan TUI lebih mudah. Dukungan lintas platform untuk fitur-fitur canggih membaik, muncul library populer yang mengabstraksikan detail-detail rumit, dan semua itu tampaknya mendorong renaisans TUI belakangan ini
  Di luar itu, beberapa poin tulisan ini agak meragukan. Misalnya, penulis menyebut konsistensi sebagai kelemahan aplikasi Electron, tetapi pada TUI populer pun hampir tidak ada konsistensi selain konvensi. Agen coding memang mengadopsi shortcut yang mirip, tetapi kebanyakan karena meniru sumber yang sama, yaitu Claude. Shortcut itu tidak banyak meluas ke luar agen coding, dan sebagian besar TUI yang kupakai punya shortcut serta bahasa visual yang sangat berbeda

  • Aku kurang paham maksud “membuat UI responsif itu sulit”. Kedengarannya seperti pembicaraan soal web; beberapa ide dari web mungkin relevan, tetapi untuk GUI native rasanya agak melenceng dari topik. Maksudnya hanya “membuat UI yang bagus” atau “membuat toolkit UI”?
    Aku juga ragu dengan pernyataan “sulit merender UI secara lintas platform”. Memang perlu lapisan kompatibilitas dan implementasi sebanyak jumlah platform, tetapi itu tidak terlihat jauh lebih sulit daripada hanya mendukung satu platform. Tentu akan berbeda jika cara rendering platform-platform target terlalu berbeda sehingga sulit merancang API bersama, tetapi pada level menggambar piksel ke layar rasanya tidak seperti itu. Hal-hal seperti scaling memang perlu ditangani, tetapi selebihnya seharusnya cukup lurus, atau ya pakai SDL juga bisa
    Mungkin yang dimaksud adalah membuat UI terlihat “native” di semua platform. Itu bisa berarti harus memakai toolkit GUI native yang disukai tiap platform, dan itu bukan saja sangat berbeda satu sama lain, tetapi juga bisa jauh lebih besar dan kurang stabil dibanding API rendering tingkat rendah. Untuk yang seperti itu, hidup terlalu singkat. Aku mungkin akan memberi ruang untuk mengubah tema warna atau sebagian gaya grafis, tetapi akan kujadikan pengaturan tingkat aplikasi. Aku tidak ingin membuang waktu membaca pengaturan grafis tiap sistem operasi
    Pernyataan “sulit menangani input pengguna, terutama aksesibilitas” juga terasa aneh. Mendengarkan event keyboard dan mouse itu hal sepele. Dari sisi aksesibilitas, memang perlu navigasi keyboard yang baik dan itu juga penting untuk kegunaan secara umum, plus dukungan shortcut standar dan kustom, tetapi secara keseluruhan itu tampak jauh lebih mudah dibanding sisanya
    Dukungan screen reader bisa saja sulit tergantung API platform terkait dan perbedaan antarplatform, tetapi itu lebih dekat ke masalah rendering daripada masalah input

• TUI ini bukan semacam “comeback”, melainkan lebih seperti hilangnya pengetahuan pemrograman GUI native, sehingga orang hanya berusaha semaksimal mungkin dengan alat yang ada. Ini hasil dari kurangnya pengembangan dan investasi yang konsisten
  Kecuali beberapa pengecualian cerah seperti Qt, peradaban UI telah runtuh dan kita terasa hidup di dunia pasca-kiamat
  Rasanya selaras dengan ceramah Preventing the Collapse of Civilization, dan sekarang ketika AI menulis banyak kode, aku khawatir keruntuhan pengetahuan ini akan menyebar lebih jauh

  • Setiap kali topik ini muncul di lobste.rs, aku selalu ikut nimbrung, jadi kurasa kali ini juga harus. Semua “kekaisaran” GUI runtuh di depan mata kita. Windows, macOS, GTK, produk-produk Mozilla, semuanya begitu
    Rasanya kita butuh versi ilmu komputer dari After Virtue, dan mungkin kehadiran online Blow sedikit banyak memainkan peran itu. Bagaimanapun, aku merindukan masa ketika antarmuka komputer menunjukkan konsistensi, menghormati pengguna, dan memberi imbalan pada pembelajaran serta ketelatenan

• Tulisan ini rasanya tidak punya banyak isi nyata, selain sekadar mengatakan bahwa penulis menganggap semua hal lain payah
  Satu hal yang akan kukatakan adalah bahwa Emacs merupakan platform hebat untuk antarmuka teks, keyboard, tombol, dan media kaya

• Kemungkinan besar karena orang mulai memakai library TUI non-ncurses dengan Go, Rust, dan sekarang Zig. Setidaknya itu menyelesaikan masalah portabilitas mengerikan yang dulu membuat ncurses diperlukan
  Setelah itu, orang mulai membuat terminal baru dan ikut mendorong teknologi di sisi itu juga. Sebagian karena sekarang mereka bisa membuatnya dengan Go, Rust, atau Zig, bukan C
  Kalau kamu memberi orang pilihan yang bagus, lebih menyenangkan, dan tidak terlalu menjengkelkan dibanding C dan C++, tentu mereka akan mulai menulis kode yang lebih baru dan lebih berguna

• Alasan sebenarnya TUI kembali adalah karena pada 2026, untuk mendistribusikan GUI yang ditandatangani dan dinotariskan, kamu harus membayar Apple, dan untuk Windows kamu juga harus membayar otoritas sertifikat

  • Bukankah binary TUI native juga punya masalah yang sama?

• Koreksi kecil: library UI berakselerasi GPU milik Zed adalah gpui, bukan API lintas platform wgpu

• Aku tidak yakin tulisan ini benar-benar membuktikan argumennya, tetapi sebagai orang yang mengalami era MS-DOS dan selalu menyukai TUI, aku ingin ikut menimpali. Kalau pernah memakai afl-fuzz, mungkin kamu akan paham
  Secara teori TUI seharusnya jauh lebih sukses di Linux. Ada basis pengguna teknis yang menyukai estetika berbasis teks, dan juga “keuntungan” berupa lingkungan GUI yang kikuk dan tidak konsisten. Bahkan pernah ada masa ketika membuat kartu video bekerja dengan benar di X server saja sudah jadi masalah
  Pada saat yang sama, selama puluhan tahun para pengembang perangkat lunak *nix merasa punya kewajiban mendukung jenis terminal tua dan eksotis sekalipun. Seolah-olah akan jadi bencana jika aplikasi tidak dirender dengan benar di DECwriter, dan di bawah batasan seperti itu memang sulit membuat TUI yang bagus
  Di era MS-DOS, perusahaan seperti Microsoft, Borland, dan Norton berhasil menyempurnakan antarmuka berbasis teks yang fungsional dan responsif. Di Linux, untuk waktu yang lama “puncak” desain TUI adalah monster bernama menuconfig, dan kalau memicingkan mata, vim pun mungkin bisa disebut TUI. Saat orang masih benar-benar memakai konsol mode teks, satu-satunya TUI Linux bagus yang kuingat mungkin adalah manajer file Midnight Commander yang terinspirasi Norton Commander