Komponen GPUI Rust lintas platform

 (github.com/longbridge)
18 poin oleh GN⁺ 2025-10-28 | 1 komentar | Bagikan ke WhatsApp
  • Library komponen UI untuk membangun aplikasi desktop lintas platform dengan memanfaatkan framework GPUI berbasis Rust
  • Menyediakan lebih dari 60 komponen UI bergaya native, menggabungkan nuansa desain macOS·Windows dengan estetika modern shadcn/ui
  • Dilengkapi fitur kaya seperti tabel tervirtualisasi, editor kode berperforma tinggi, rendering Markdown/HTML, dan visualisasi chart
  • Dirancang dengan fokus pada ekstensibilitas dan kustomisasi seperti sistem tema, multibahasa (i18n), dan layout docking
  • Di ekosistem Rust, memiliki nilai pembeda dibanding Iced, egui, Qt, dan lainnya lewat gaya UI modern serta performa pemrosesan data skala besar

Gambaran proyek

  • gpui-component adalah kumpulan komponen UI desktop lintas platform yang ditulis dengan Rust dan berjalan di atas render engine GPUI
  • Lisensi Apache-2.0

Fitur utama

  • Susunan komponen yang kaya: mencakup lebih dari 60 elemen UI, termasuk tombol, daftar, tabel, chart, editor, dan berbagai komponen lain
  • Desain bernuansa native: menghadirkan antarmuka modern yang terinspirasi dari kontrol bawaan macOS dan Windows serta dipadukan dengan gaya shadcn/ui
  • Kemudahan penggunaan yang ringkas: struktur komponen RenderOnce tanpa state memungkinkan penulisan kode yang sederhana dan intuitif
  • Sistem tema dan warna: mendukung banyak tema serta konfigurasi berbasis variabel melalui Theme dan ThemeColor
  • Layout fleksibel: dengan Dock layout, panel dapat ditata, diubah ukurannya, dan disusun bebas dalam bentuk tiling
  • Rendering berperforma tinggi: Virtualized Table/List menampilkan data besar dengan mulus
  • Rendering konten: mendukung Markdown dan HTML sederhana secara native
  • Fitur chart: memungkinkan visualisasi data dengan chart bawaan
  • Editor kode: menyertakan editor kode berperforma tinggi berbasis LSP yang mendukung hingga 200 ribu baris
    • Mendukung fitur seperti diagnostic, autocomplete, hover, dan lainnya
    Iklan
  • Syntax highlighting: menggunakan Tree Sitter untuk menyediakan penyorotan sintaks baik di editor maupun Markdown

Tech stack dan statistik

  • Komposisi bahasa: Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
  • Metrik repositori: 5.4k stars, 223 forks, lebih dari 45 kontributor
  • Rilis terbaru: v0.3.1 (27 Oktober 2025)

Makna ringkas

  • gpui-component dinilai sebagai framework UI desktop baru di ekosistem Rust yang menggabungkan UI/UX modern dan rendering berperforma tinggi
  • Melengkapi keterbatasan framework GUI Rust yang sudah ada, serta menawarkan fitur yang ramah kebutuhan praktis seperti pemrosesan data skala besar, theming, dan integrasi Markdown
  • Ke depan, proyek ini mendapat perhatian sebagai calon lapisan UI terstandar untuk pengembangan aplikasi lintas platform berbasis Rust

Bacaan terkait

1 komentar

 
GN⁺ 2025-10-28
Opini Hacker News

  • Di ekosistem UI Rust, ini tampak seperti koleksi komponen yang paling matang yang pernah saya lihat sejauh ini
    Memang belum banyak contoh penggunaan, tetapi dokumentasinya makin rapi
    Contoh lain yang tingkat kematangannya mirip adalah fyrox-ui. Namun, hampir tidak dipakai di luar engine fyrox
    UI Rust makin matang, tetapi framework populer seperti iced, egui, dioxus, dan slint masih tampak kurang matang dari sisi kelengkapan komponen
    Sebagai pembaruan, proyek ini menunjukkan kemajuan besar di ekosistem UI Rust.
    Aplikasi galeri widget untuk melihat semua komponennya bisa dijalankan di sini — cukup dengan cargo run --release

    • gpui adalah proyek yang dipisahkan dari Zed Editor, jadi kemungkinan penggunaan nyatanya jauh lebih banyak daripada crate UI Rust lain
    • Fyrox adalah contoh yang membuat saya skeptis terhadap pengembangan game dengan Rust. Meski itu engine yang paling matang, hampir tidak ada yang memakainya. Sementara itu orang-orang justru antusias hanya pada ECS milik Bevy. Rasanya mereka tertarik pada sistemnya sendiri, bukan benar-benar ingin membuat game
    • Framework UI Rust masih berubah sangat cepat, jadi mungkin itu sebabnya terlihat kurang matang. Meski begitu, momentumnya jelas ada. Ini memang hanya pengalaman pribadi saya, tetapi saya sudah bisa membuat UI tingkat enterprise dengan Rust
    • Saya sempat memasang aplikasi Longbridge sendiri, dan memang berjalan natural seperti aplikasi native Mac. Jauh lebih mulus daripada Electron
    • Aplikasi galeri widget-nya mengesankan, tetapi saya agak khawatir karena ada lebih dari 900 dependensi. Saya kurang tahu apakah jumlah seperti ini umum untuk aplikasi GUI

  • Bahkan contoh paling sederhana pun punya lebih dari 1000 dependensi. Ia bergantung pada toolkit seperti GTK, GDK, dan pango. Struktur yang juga bergantung pada toolkit lain terasa agak aneh

    • GNOME tidak mengimplementasikan server-side decoration sehingga harus bergantung pada libadwaita. Sepertinya inilah penyebab semua dependensi terkait GTK ikut tertarik masuk
    • Di Linux, struktur seperti ini umum. Memakai GTK atau Qt untuk menggambar jendela tingkat atas atau menu adalah hal yang biasa
    • Menurut saya 1000 dependensi kecil yang bisa dikombinasikan lebih baik. Jauh lebih mudah diaudit dibanding satu codebase raksasa
    • Agak disayangkan proyek-proyek Rust belakangan makin membesar seperti ini

  • Agak pahit bahwa banyak teknologi fondasi open source dibuat oleh perusahaan trading dan kripto. Meski begitu, tetap positif bahwa mereka menyumbang sesuatu bagi masyarakat

    • gpui dikelola oleh tim Zed.dev, dan Longbridge tampaknya perusahaan broker biasa yang membuat aplikasi Longbridge Pro. Tidak terlihat ada masalah khusus di sini
    • Menurut saya semangat Bitcoin mirip dengan budaya hacker. Sikapnya seperti, “mari perbaiki hal yang rusak.” Rasa sakit jangka pendek kadang bisa membawa manfaat jangka panjang
    • Di beberapa ekosistem seperti Rust atau OCaml (Jane Street), kecenderungan itu memang ada, tetapi secara keseluruhan klaim seperti itu terasa berlebihan
    • Facebook yang membuat React juga terlibat dalam kasus seperti skandal Cambridge Analytica atau pembantaian Rohingya. Kalau dilihat dari sisi itu, kontribusi open source dari perusahaan trading/kripto justru mungkin lebih bisa diterima secara moral

  • Saya penasaran apakah toolkit UI yang “modern” belakangan ini tidak punya editor UI visual
    Qt dulu memungkinkan pembuatan UI hanya dengan drag-and-drop lewat alat seperti QtCreator atau QtDesigner
    Selain itu, beberapa item di tabel perbandingan terkait Qt juga salah — misalnya ukuran biner minimum atau penjelasan tentang QSyntaxHighlighter

    • Framework seperti Slint mendukung integrasi Figma, jadi bisa dipakai mirip Qt Design Studio. Rasanya sekarang orang kurang menyadari betapa kuatnya GUI designer native zaman dulu
    • Jika dibangun di atas library komponen yang matang, editor visual seperti itu juga bisa dibuat di Rust. Struktur berbasis XML/markup bisa dihubungkan dengan macro, lalu dibuat aplikasi pratinjau real-time agar bekerja seperti Glade atau XAML
    • Ukuran minimum Qt sebenarnya kurang dari 20MB, tetapi umumnya sekitar 30–40MB. Modul Core, Gui, QML, dan Widget masing-masing sekitar 8MB, jadi bahkan Hello World pun butuh 2–3 modul
    • Qt Designer lumayan untuk UI sederhana, tetapi begitu diberi custom styling, semuanya cepat berantakan. Karena itu saya akhirnya menulis file UI secara manual. Hasilnya jauh lebih bersih dan kecil
    • Klaim bahwa Qt6 tidak mendukung tema itu sepenuhnya salah

  • Sayangnya ini adalah sebuah framework. Artinya, ia harus memiliki event loop sendiri
    Di lingkungan yang sudah punya loop lain, integrasinya jadi sulit. Sebaliknya, egui hanyalah struktur berbentuk library yang dipanggil setiap frame

  • Saya penasaran apakah aksesibilitas screen reader untuk pengguna tunanetra berfungsi dengan baik

    • Saya belum menjalankannya sendiri, tetapi menurut dokumentasi resmi, ia mendukung spesifikasi ARIA. Tinggal menambahkan label dan deskripsi yang diperlukan
    • Namun Zed Editor sepenuhnya tidak terbaca oleh screen reader. Jadi saya tidak terlalu berharap besar
    • Setiap kali melihat framework UI baru, hal pertama yang saya tanyakan selalu soal aksesibilitas

  • Saya penasaran apakah yang dimaksud “native” itu sekadar bukan web, atau benar-benar memakai widget bawaan OS. Ekosistem Java juga dulu banyak bergulat dengan perbedaan ini

    • Hanya macOS yang benar-benar platform untuk membuat aplikasi native sejati. Linux terbelah antara GTK/Qt, sedangkan Windows bercampur dengan terlalu banyak framework sampai-sampai WebView pun bisa terlihat native
    • Native di sini berarti “bukan web”. Strukturnya menggambar langsung lewat API GPU
    • Jadi ini adalah berkas eksekusi native, bukan memakai widget OS
    • Tidak ada integrasi OS; semuanya menggunakan rendering buatan sendiri

  • Saya penasaran apakah framework ini sudah mengimplementasikan aksesibilitas (a11y). UI Rust sering kali tampak cantik, tetapi begitu ada kebutuhan aksesibilitas, semuanya harus ditulis ulang total

    • Jika aksesibilitas penting, Dioxus layak dipertimbangkan. Hanya saja, belum ada library komponen yang sematang ini
    • GPUI dibangun di atas fondasi buatan tim Zed, tetapi tetap tidak terbaca oleh screen reader. Kalau aksesibilitas penting, Slint atau Qt (cxx-qt) lebih baik, dan karena System76 mengadopsi Iced, sisi itu mungkin juga akan membaik
    • Aksesibilitas sudah diimplementasikan

  • Fitur daftar dan tabel tervirtualisasi benar-benar sangat bagus. Banyak framework UI memaksa kita mengimplementasikan ini sendiri, yang terasa merepotkan

  • Rust punya banyak toolkit GUI, tetapi kekurangan koleksi komponen yang bisa digunakan ulang
    Koleksi ini tampak berguna, tetapi sebagian besar mirip daftar komponen framework web. Unsur yang benar-benar khas native tampaknya hanya webview. Hal seperti dialog buka file tetap harus memakai library eksternal seperti rfd, sehingga konsistensi gaya jadi pecah

    • Justru pecahnya konsistensi gaya itu adalah hal yang baik. Pengguna menginginkan konsistensi antar aplikasi. Artinya, dialog native OS lebih familier. Perangkat lunak profesional seperti Blender atau Photoshop mungkin pengecualian, tetapi untuk aplikasi umum, native lebih baik menurut saya
    • Kebanyakan library UI juga tetap butuh minimal integrasi native. Hal-hal seperti shortcut, menu sistem, dialog file, dan menu konteks. Bagian seperti ini meningkatkan rasa familier bagi pengguna
    • Pemilih file seharusnya memang memakai dialog bawaan OS. Mengimplementasikannya sendiri bukan ide yang bagus