Component GPUI đa nền tảng bằng Rust

• Thư viện component UI giúp xây dựng ứng dụng desktop đa nền tảng bằng framework GPUI dựa trên Rust
• Cung cấp hơn 60 component UI theo phong cách native, kết hợp cảm quan thiết kế của macOS·Windows với thẩm mỹ hiện đại của shadcn/ui
• Tích hợp sẵn nhiều tính năng phong phú như bảng ảo hóa, trình soạn thảo mã hiệu năng cao, render Markdown/HTML, trực quan hóa biểu đồ
• Thiết kế chú trọng khả năng mở rộng và tùy biến với hệ thống theme, đa ngôn ngữ (i18n), dock layout
• Trong hệ sinh thái Rust, dự án mang ý nghĩa khác biệt khi so với Iced, egui, Qt ở phong cách UI hiện đại và hiệu năng xử lý dữ liệu quy mô lớn

---

Tổng quan dự án

• gpui-component là bộ component UI desktop đa nền tảng được viết bằng Rust, hoạt động dựa trên GPUI render engine
  • Mục tiêu là giúp xây dựng “fantastic desktop applications” theo cách nhanh chóng và nhất quán
  • Trang chính thức: longbridge.github.io/gpui-component
• Giấy phép Apache-2.0

Tính năng chính

• Bộ component phong phú: bao gồm hơn 60 phần tử UI, cung cấp nhiều thành phần như button, list, table, chart, editor
• Thiết kế đậm chất native: lấy cảm hứng từ các control mặc định của macOS và Windows, kết hợp phong cách shadcn/ui để tạo ra giao diện hiện đại
• Tính dễ dùng gọn gàng: cấu trúc component RenderOnce không trạng thái giúp viết mã đơn giản và trực quan
• Hệ thống theme và màu sắc: hỗ trợ nhiều theme và cấu hình dựa trên biến thông qua Theme và ThemeColor
• Layout linh hoạt: với Dock layout, có thể sắp xếp panel, thay đổi kích thước và tạo bố cục dạng tile tự do
• Render hiệu năng cao: Virtualized Table/List hiển thị mượt mà cả dữ liệu quy mô lớn
• Render nội dung: hỗ trợ native cho Markdown và HTML đơn giản
• Tính năng biểu đồ: có thể trực quan hóa dữ liệu bằng chart tích hợp sẵn
• Trình soạn thảo mã: tích hợp trình chỉnh sửa mã hiệu năng cao dựa trên LSP hỗ trợ tối đa 200.000 dòng
  • Hỗ trợ các tính năng như chẩn đoán, tự động hoàn thành, hover
• Tô sáng cú pháp: dùng Tree Sitter để cung cấp syntax highlighting cho cả editor và Markdown

Tech stack và thống kê

• Cấu hình ngôn ngữ: Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
• Chỉ số repository: 5.4k stars, 223 forks, hơn 45 người đóng góp
• Bản phát hành mới nhất: v0.3.1 (27 tháng 10, 2025)

Ý nghĩa tổng quát

• gpui-component được đánh giá là một framework UI desktop mới trong hệ sinh thái Rust, kết hợp UI/UX hiện đại và render hiệu năng cao
• Bù đắp những giới hạn của các framework GUI Rust hiện có, đồng thời cung cấp các tính năng thân thiện với thực tế triển khai như xử lý dữ liệu lớn·theme hóa·tích hợp Markdown
• Là dự án đang được chú ý như ứng viên cho lớp UI tiêu chuẩn trong phát triển ứng dụng đa nền tảng dựa trên Rust trong tương lai

[GN⁺]

Ý kiến trên Hacker News

• Trong hệ sinh thái UI của Rust, đây có vẻ là bộ sưu tập component hoàn thiện nhất mà tôi từng thấy
  Dù hiện vẫn gần như chưa có nhiều trường hợp sử dụng, tài liệu đang dần được hoàn thiện tốt hơn
  Một ví dụ khác có độ hoàn thiện tương tự là fyrox-ui. Tuy vậy, nó hầu như không được dùng bên ngoài engine fyrox
  UI của Rust đang dần trưởng thành, nhưng các framework phổ biến như iced, egui, dioxus, slint vẫn có vẻ còn thiếu về độ hoàn thiện của component
  Cập nhật thêm thì dự án này cho thấy bước tiến lớn trong hệ sinh thái UI của Rust.
  Có thể chạy tại đây ứng dụng thư viện widget để xem toàn bộ component — chỉ cần cargo run --release

  • gpui là dự án được tách ra từ Zed Editor, nên có lẽ mức sử dụng thực tế lớn hơn nhiều so với các crate UI Rust khác
  • Fyrox là một ví dụ khiến người ta hoài nghi về phát triển game bằng Rust. Đây là engine trưởng thành nhất nhưng chẳng ai dùng. Trong khi đó, mọi người lại chỉ phát cuồng vì ECS của Bevy. Cuối cùng có vẻ họ chỉ hứng thú với bản thân hệ thống, chứ không thực sự muốn làm game
  • Có lẽ các framework UI Rust trông kém hoàn thiện vì chúng vẫn đang thay đổi rất nhanh. Dù vậy, đà phát triển là rất rõ ràng. Đây chỉ là trải nghiệm cá nhân, nhưng tôi đã có thể làm UI cấp doanh nghiệp bằng Rust
  • Tôi đã tự cài ứng dụng Longbridge và nó thực sự hoạt động tự nhiên như một ứng dụng Mac native. Chạy mượt hơn Electron rất nhiều
  • Ứng dụng thư viện widget thì ấn tượng thật, nhưng việc nó có hơn 900 dependency khiến tôi hơi lo. Tôi không rõ với ứng dụng GUI thì mức này có bình thường không

• Ngay cả ví dụ đơn giản nhất cũng có hơn 1000 dependency. Nó phụ thuộc vào các toolkit như GTK, GDK, pango. Cấu trúc lại còn phụ thuộc thêm vào các toolkit khác nên cảm giác hơi kỳ

  • GNOME không triển khai server-side decoration nên phải phụ thuộc vào libadwaita. Có vẻ đó là nguyên nhân kéo theo toàn bộ dependency liên quan đến GTK
  • Trên Linux thì kiểu cấu trúc này khá phổ biến. Dùng GTK hoặc Qt để vẽ cửa sổ cấp cao hay menu là chuyện bình thường
  • Tôi nghĩ 1000 dependency nhỏ, có thể kết hợp còn tốt hơn một codebase khổng lồ duy nhất. Việc audit cũng dễ hơn nhiều
  • Hơi tiếc là các dự án Rust dạo này ngày càng phình to theo kiểu đó

• Thật chua chát khi nhiều công nghệ nền tảng của mã nguồn mở lại được tạo ra bởi các công ty trading·crypto. Dù vậy, việc họ vẫn đóng góp điều gì đó cho xã hội là điểm tích cực

  • gpui do đội Zed.dev duy trì, còn Longbridge có vẻ là một công ty môi giới thông thường làm ứng dụng Longbridge Pro. Có vẻ không có gì đặc biệt đáng lo
  • Tôi nghĩ tinh thần Bitcoin khá giống văn hóa hacker. Kiểu thái độ “hãy sửa cái gì đang hỏng”. Nỗi đau ngắn hạn đôi khi có thể dẫn tới lợi ích dài hạn
  • Trong một số hệ sinh thái như Rust hay OCaml (Jane Street) thì đúng là có xu hướng đó, nhưng xét tổng thể thì có vẻ là nhận định hơi phóng đại
  • Facebook, công ty tạo ra React, từng dính tới những vụ như bê bối Cambridge Analytica hay thảm sát người Rohingya. Xét theo góc đó, việc các công ty trading/crypto đóng góp cho mã nguồn mở thậm chí còn có thể là điều tốt hơn về mặt đạo đức

• Tôi tự hỏi các toolkit UI “modern” hiện nay có còn thiếu trình biên tập UI trực quan hay không
  Qt từng cho phép tạo UI chỉ bằng kéo thả với các công cụ như QtCreator hay QtDesigner
  Ngoài ra, một số mục trong bảng so sánh liên quan đến Qt là sai — ví dụ như kích thước nhị phân tối thiểu hay phần mô tả QSyntaxHighlighter

  • Các framework như Slint hỗ trợ tích hợp Figma nên có thể dùng theo kiểu Qt Design Studio. Có vẻ ngày nay nhiều người không còn biết các trình thiết kế GUI native trước đây mạnh đến mức nào
  • Nếu dựa trên một thư viện component hoàn thiện, thì cũng có thể xây dựng trình biên tập trực quan kiểu này bằng Rust. Có thể nối cấu trúc XML/markup bằng macro rồi tạo ứng dụng xem trước thời gian thực để hoạt động như Glade hay XAML
  • Kích thước tối thiểu của Qt thực tế nhỏ hơn 20MB, nhưng thông thường là khoảng 30~40MB. Các module Core, Gui, QML, Widget mỗi cái khoảng 8MB nên ngay cả Hello World cũng cần 2~3 module
  • Qt Designer ổn với UI đơn giản, nhưng khi áp dụng custom styling thì rất nhanh bị hỏng. Vì vậy cuối cùng tôi đã tự viết file UI bằng tay. Gọn hơn và nhỏ hơn nhiều
  • Nói Qt6 không hỗ trợ theme là nhận định hoàn toàn sai

• Tiếc là đây là một framework. Nghĩa là nó phải có event loop riêng
  Trong môi trường đã có loop khác thì sẽ khó tích hợp. Trong khi egui chỉ là cấu trúc dạng thư viện được gọi mỗi frame

• Tôi tò mò không biết khả năng truy cập cho screen reader dành cho người khiếm thị có hoạt động tốt không

  • Tôi chưa tự chạy thử, nhưng theo tài liệu chính thức thì nó hỗ trợ chuẩn ARIA. Chỉ cần thêm label và mô tả cần thiết là được
  • Nhưng Zed Editor thì hoàn toàn mù mờ với screen reader. Vì vậy tôi không kỳ vọng nhiều
  • Mỗi khi nhìn thấy một framework UI mới, điều đầu tiên tôi hỏi luôn là khả năng truy cập

• Tôi thắc mắc “native” ở đây có nghĩa là không phải web, hay là dùng widget mặc định của OS. Hệ Java cũng từng gặp khác biệt này rất lớn

  • Chỉ macOS mới là nền tảng có thể làm ứng dụng native đúng nghĩa. Linux thì chia giữa GTK/Qt, còn Windows thì có quá nhiều framework lẫn lộn nên ngay cả WebView cũng có thể trông giống native
  • Ở đây native có nghĩa là “không phải web”. Nó là cấu trúc tự vẽ trực tiếp bằng GPU API
  • Tức là file thực thi native, chứ không phải dùng widget của OS
  • Không có tích hợp với OS, mà là cách render hoàn toàn tự thân

• Tôi tò mò framework này đã triển khai accessibility (a11y) chưa. UI Rust thường trông đẹp, nhưng khi phát sinh yêu cầu accessibility thì phải viết lại từ đầu

  • Nếu coi trọng accessibility thì có thể cân nhắc Dioxus. Tuy nhiên vẫn chưa có thư viện component nào hoàn thiện tới mức này
  • GPUI được xây trên nền của đội Zed, nhưng với screen reader thì vẫn còn mù mờ. Nếu accessibility quan trọng thì Slint hoặc Qt (cxx-qt) sẽ phù hợp hơn, và vì System76 đã chọn Iced nên có lẽ phía đó cũng sẽ cải thiện
  • Accessibility đã được triển khai

• Tính năng danh sách và bảng được ảo hóa thực sự rất xuất sắc. Nhiều framework UI bắt người dùng phải tự triển khai phần này nên rất bất tiện

• Rust có nhiều GUI toolkit, nhưng lại thiếu bộ sưu tập component có thể tái sử dụng
  Bộ sưu tập này có vẻ hữu ích, nhưng phần lớn danh sách component trông giống các framework web. Yếu tố đặc thù native dường như chỉ có webview. Những thứ như hộp thoại mở file lại phải dùng thư viện ngoài như rfd, nên làm mất tính nhất quán về phong cách

  • Việc mất nhất quán về phong cách thực ra lại là điều tốt. Người dùng muốn sự nhất quán giữa các ứng dụng. Tức là hộp thoại native của OS sẽ quen thuộc hơn. Phần mềm chuyên nghiệp như Blender hay Photoshop là ngoại lệ, nhưng với ứng dụng thông thường thì native vẫn tốt hơn
  • Hầu hết thư viện UI cũng cần ít nhất một mức độ tích hợp native tối thiểu. Như phím tắt, menu hệ thống, hộp thoại file, menu ngữ cảnh. Những phần đó giúp người dùng cảm thấy quen thuộc hơn
  • Trình chọn file nhất định phải dùng hộp thoại mặc định của OS. Tự triển khai là không nên