Vì sao TUI quay trở lại

 (wiki.alcidesfonseca.com)
1 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • TUI đang được chú ý trở lại nhờ phản hồi tức thì, dễ tự động hóa và khả năng hoạt động xuyên hệ điều hành; các công cụ như Claude và Codex cũng đã rất thành công trên dòng lệnh
  • GUI native trên Windows, Linux và macOS lần lượt làm tăng gánh nặng cho cả nhà phát triển lẫn người dùng vì chiến lược API thiếu ổn định, hệ toolkit/môi trường bị phân mảnh và sự suy yếu về tính nhất quán với các nguyên tắc trước đây
  • Với ứng dụng Electron, vấn đề lớn hơn cả mức dùng bộ nhớ là sự thiếu nhất quán về mặt thị giác và những khoảng trống trong quy trình làm việc ưu tiên bàn phím; việc tích hợp menu và phím tắt cũng yếu đi
  • Đã có những nỗ lực tạo ra stack UI mới như thử nghiệm Flutter UI của Google hay GPUI của Zed, nhưng nếu thiếu tích hợp với hệ điều hành thì chỉ có trình dựng nhanh thôi là chưa đủ
  • Một giao diện tốt lấy tính nhất quán làm cốt lõi để người dùng phải suy nghĩ ít hơn; các nhà phát triển và những bên làm hệ điều hành·toolkit cần đầu tư nhiều hơn vào lý thuyết UI và các toolkit dễ tiếp cận

Bối cảnh khiến TUI снова được chú ý

  • Omarchy của DHH được cấu thành từ sự pha trộn giữa TUI, ứng dụng web và ứng dụng native kiểu gnome; TUI được dùng để có phản hồi tức thì và “geek points”
  • Khoảng 10 năm trước cũng từng có một xu hướng tương tự trong các trình biên tập mã
    • Đã có sự dịch chuyển từ các trình biên tập native như BBEdit, Textmate, Notepad++, Sublime sang các ứng dụng dựa trên Electron như Atom, VSCode và các ứng dụng phái sinh của chúng
    • Những người dùng có sở thích rất mạnh thì chuyển sang vim hoặc emacs, đổi lại phản hồi tức thì và khả năng sử dụng cao nhưng phải chấp nhận đường cong học tập rất dốc

Vì sao GUI native suy yếu

  • Windows

    • Windows chưa từng xây dựng được một chiến lược thư viện GUI nhất quán, và cứ lặp lại mô hình: một API không thành công thì lại làm thêm API khác
    • Jeffrey Snover trong bài Microsoft hasn’t had a coherent GUI strategy since Petzold nhận xét rằng MFC, OLE, COM và ActiveX đã làm lan rộng độ phức tạp khắp hoạt động phát triển trên Windows
    • Sau đó Microsoft đi qua WinForms, WPF, Silverlight, WinUI và MAUI nhưng đều không thành công; nhiều ứng dụng desktop cho doanh nghiệp lẫn cá nhân vẫn phụ thuộc vào Electron
    • Giai đoạn cuối cùng mà toàn bộ Windows còn được tích hợp nhất quán về mặt thị giác có lẽ là Windows 98 hoặc Windows 2000
    • Domenic Denicola trong Windows Native App Development Is a Mess cho rằng chi phí tái tạo lại OS và API UI vài năm một lần là rất lớn; thêm vào đó là sandboxing và các nỗ lực loại bỏ tính năng, khiến mỗi lớp mới đều xuất hiện những khoảng trống không làm được những việc mà framework trước đó từng làm được

  • Linux

    • Sự thiếu nhất quán trong UI của Linux gần như là kết quả sinh ra từ chính thiết kế của nó, khi các nhóm khác nhau có tự do theo đuổi các mục tiêu khác nhau
    • GTK và Qt trở thành hai framework chủ đạo; cả hai đều hướng đến phát triển native đa nền tảng, nhưng phạm vi được dùng rộng rãi chủ yếu vẫn là Linux
    • Các ứng dụng Linux làm bằng những toolkit khác nhau, dù đặt cạnh nhau, vẫn có thể trông tương đối ổn; trong khi nhiều framework trên Windows lại không đạt được mức hài hòa đó
    • Có quá nhiều tổ hợp bản phân phối, môi trường desktop và phần cứng nên việc kiểm thử trở nên khó khăn; vì vậy nhiều công ty không làm ứng dụng Linux native
    • Các công ty thường hỗ trợ Linux bằng Electron, hoặc nếu có API công khai thì để cộng đồng mã nguồn mở tự giải quyết

  • macOS

Giới hạn của ứng dụng Electron

  • Vấn đề được nhắc đến nhiều nhất là mức dùng bộ nhớ, nhưng trong 10 năm qua mức dùng bộ nhớ thực ra có xu hướng giảm
  • Vấn đề lớn hơn là sự thiếu nhất quán về mặt thị giác và sự thiếu hụt trong quy trình làm việc lấy bàn phím làm trung tâm
  • Ngay cả trong môi trường dùng MacBook Pro 64GB RAM, trên Dock vẫn có 8 ứng dụng native và 6 ứng dụng Electron cùng tồn tại
    • Ứng dụng native: TextMate và các tiện ích hệ thống của macOS
    • Ứng dụng Electron: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
  • Trong các ứng dụng như Cursor và VSCode, sau khi yêu cầu một tính năng từ agent panel thì việc chỉ dùng bàn phím để chuyển sang danh sách agent ở thanh bên hoặc lưu trữ lại không hề tự nhiên
  • Những thao tác như vậy lẽ ra phải thực hiện được theo cùng một cách trên mọi ứng dụng macOS, nhưng có trường hợp dù có phím tắt thì nó lại không hiển thị trong menu
  • Trong 10 năm qua, các nhà phát triển có xu hướng quên thêm vào menu những thao tác mà ứng dụng có thể làm; điều này liên quan đến cấu trúc mà ứng dụng được triển khai như HTML bên trong sandbox
  • Slack xử lý những điểm này tốt hơn các ứng dụng Electron khác, nhưng vẫn chưa hoàn hảo

Nỗ lực xây lại stack UI mới

  • Google từng muốn cùng với Dart tạo ra một toolkit UI cho hệ điều hành mới và thiết bị mới không mang di sản của Android
  • Google muốn có một toolkit mới là Flutter UI, nhưng đã từ bỏ dự án trước khi sản phẩm thực tế được phát hành
  • Những nỗ lực như vậy chỉ có thể thành công khi có vị thế độc quyền hoặc thị phần đủ lớn
  • Zed chọn hướng đi tương tự bằng Rust, tạo ra thư viện renderer GPU riêng là GPUI, và thư viện này hướng đến đa nền tảng
  • GPUI nhanh, nhưng bản thân nó không đủ tích hợp với hệ điều hành chủ, nên nhà phát triển phải tự thêm các binding cần thiết
  • Một renderer chậm nhưng tích hợp tốt với hệ điều hành còn tốt hơn một renderer nhanh

Khoảng trống mà TUI lấp vào

  • Trong bối cảnh gợi nhớ đến sự suy tàn của Apple Automator, TUI lại trở nên quan trọng như một giao diện có thể tự động hóa
  • TUI cũng tương đối dễ chạy từ xa, và không cần phụ thuộc vào X forwarding vốn dễ gây đau đầu
  • Khi các toolkit UI native thất bại, người ta sẽ quay về với những thứ cơ bản, và kết quả là TUI nổi lên như một lựa chọn
  • Claude và Codex đã rất thành công trên dòng lệnh, và người dùng có thể tập trung vào chính tương tác thay vì phải bận tâm đến hệ điều hành xung quanh
  • Thông qua TUI, có thể xử lý mã và ứng dụng trên máy cloud, hoặc truy cập từ xa từ iPad vào một máy có GPU
  • TUI đang lấp vào khoảng trống mà Apple và Microsoft để lại trong một môi trường nơi mọi ứng dụng đều trông khác nhau
  • Ngoại hình khác biệt có thể phù hợp với nghệ thuật hay trò chơi máy tính, nhưng không phù hợp với mục tiêu để giao diện lùi xuống phía sau và người dùng tập trung làm việc của mình

Hướng đi cần thiết trong tương lai

  • John Loeber trong Bring Back Idiomatic Design cho rằng ngay cả checkbox cũng là một giao diện để tương tác với hệ thống, và một giao diện tốt là giao diện khiến người dùng phải suy nghĩ ít hơn
  • Người dùng tương tác với rất nhiều thứ, nên cần những giao diện đồng nhất mang lại trải nghiệm nhất quán
  • Nếu Command+C là phím tắt để sao chép thì nó phải hoạt động ở mọi nơi; kiểu phải nhớ riêng CTRL+Shift+C hoặc nhấp chuột phải → sao chép trong những tình huống cụ thể là bất tiện
  • Mọi nhà phát triển nên học không chỉ về phần mềm mà còn cả lý thuyết làm cho giao diện người dùng nói chung trở nên tốt hơn
  • Cần chấm dứt thái độ coi thiết kế cho người dùng như một kỹ năng mềm không quan trọng trong chương trình đào tạo kỹ sư phần mềm
  • Ở bất kỳ chương trình nào, nếu UI không được hiểu đúng thì dự án phải bị xem là thất bại; trong các khóa học HCI cần lấy UI hoàn hảo làm mục tiêu
  • Phần lớn nỗ lực để tạo ra UI tốt nằm ở việc hiểu nhu cầu; còn bản thân việc lập trình thì đã và đang được tự động hóa
  • Những bên làm hệ điều hành và toolkit cần thúc đẩy đầu tư để tạo ra các toolkit dễ tiếp cận mà nhà phát triển thực sự muốn dùng, đồng thời hạ thấp rào cản gia nhập
  • Không nhất thiết phải khăng khăng đòi hỗ trợ đa nền tảng, nhưng chỉ cần có dù một lời giải như vậy thôi cũng có thể giúp giảm sự phụ thuộc vào Electron và TUI

Bài viết liên quan

1 bình luận

 
GN⁺ 1 giờ trước
Ý kiến trên Lobste.rs

  • Tôi ước gì người ta cứ làm ứng dụng native thì hơn. TUI trông như kiểu kết hợp nhược điểm của giao diện dòng lệnh và GUI thực thụ
    Mọi chương trình TUI đều phải tự triển khai lại việc cuộn, nên dù terminal có hỗ trợ cuộn theo pixel thì chương trình TUI vẫn thường chỉ cuộn theo dòng và cách hoạt động cũng mỗi cái một kiểu. Scrollback của senpai khác với các chương trình khác tôi dùng nên tôi cứ bị lạc hướng
    Cũng không có cách nào để bộc lộ cho terminal biết rằng giao diện có nhiều hơn một bảng văn bản đơn lẻ, nên việc chọn văn bản rất hay bị hỏng. Có thể làm được nếu chặn sự kiện chuột, nhưng cái đó cũng dở theo kiểu khác. Trong một client IRC dạng TUI, tôi từng phải bấm phím tắt để ẩn các panel linh tinh hai bên chỉ để chọn văn bản, một quy trình khá ngớ ngẩn
    Ràng buộc phải khớp theo lưới làm hạn chế rất nhiều khả năng bố cục và thiết kế. Tôi nghĩ đến kiểu tạo style cho thứ gì đó trông như nút bấm có thể click, hay các menu ngữ cảnh. Tôi từng than phiền về vấn đề này trước đây
    Theo tôi, việc TUI ngày càng nhiều là hệ quả đáng tiếc của tình trạng tệ hại của các framework GUI truyền thống. Framework TUI tương đối ổn định, và kể cả dùng đồ rất cũ cũng không quá khó chịu. Chương trình ncurses đến giờ vẫn được dùng thường xuyên, nhưng khó mà hình dung việc dùng chương trình Motif ngày nay
    Ngược lại, framework GUI không có nhiều lựa chọn và cần bảo trì nhiều hơn hẳn. Môi trường desktop thay đổi, và kỳ vọng đối với GUI cũng tăng lên. Tôi nghĩ khả năng tiếp cận của TUI thực sự rất tệ, dù không dám khẳng định chắc. Mọi thứ lại thay đổi liên tục: làm bằng GTK2 thì bị tuyên bố sắp bỏ, nâng lên GTK3 rồi lại bị bảo chuyển sang GTK4
    Nếu nhìn một cách cay nghiệt thì các thứ như Omarchy còn có yếu tố khác nữa. GUI thông thường như xfce4-taskmanager thì buồn tẻ, còn TUI như btop lại trông cực kỳ kiểu hacker. Mọi người thích thẩm mỹ terminal (/r/unixporn là ví dụ), và có vẻ sẵn sàng hy sinh tính tiện dụng để lấy không khí. Chỉ cần nhìn btop thật sự làm mờ dần danh sách tiến trình là thấy

    • Tôi làm web lâu rồi nên muốn thử phát triển ứng dụng native. Tôi có tìm hiểu để làm ứng dụng GNOME, nhưng thấy nó xoay quanh C++ nên khá nản
      Tôi đã hy vọng giờ rào cản gia nhập thấp hơn. Trong bối cảnh phần lớn lập trình viên được đào tạo bằng ngôn ngữ bậc cao, chuyện đó có vẻ không mấy thuyết phục, và sự phức tạp của C++ dường như cũng làm tôi chùn bước
    • Ngoài lề một chút, tôi không hiểu vì sao nhiều client chat lại làm cho việc copy-paste lịch sử bị vỡ định dạng kinh khủng. Ví dụ trong Discord nó ra thế này
      [
      20:41
      ]
      username1
      :
      message1
      [
      20:42
      ]
      username2
      :
      message2
      Client Matrix là Nheko thì thậm chí không cho chọn quá một dòng cùng lúc
      Trong khi đó các client IRC mặc định lại cho dạng như sau
      20:41 <username1> message1
      20:42 <username2> message2
    • Tôi thích giao diện dòng lệnh, nhưng TUI thì tôi cũng không thích lắm. Nó có chỗ để dùng, nhưng thực tế gần như là một GUI thô kệch và xấu xí, lại còn hay lãng phí không gian terminal
      Đôi khi nó hợp lý, nhưng lý tưởng nhất thì tôi nghĩ chỉ nên dùng cho các ứng dụng nhỏ, dùng ngắn hạn, hoặc các ngoại lệ như biên tập văn bản
    • Tôi cũng thấy TUI hơi kém, nhưng so với mấy bộ công cụ UI kiểu gtk thì vẫn là lựa chọn đỡ tệ hơn. Những ứng dụng TUI tôi thích có khả năng mở rộng tốt, nhanh nhạy, và tích hợp tốt với dòng lệnh Linux
      Ví dụ lf, tig, kakoune rất hợp với shell script, nên có thể tái sử dụng cùng một script và mở rộng chức năng trong cả ba ứng dụng. Vì cả ba đều chạy trong alacritty, tôi cũng có thể tạo hyperlink hoạt động xuyên suốt cả ba ứng dụng và toàn bộ shell
      Nếu được mơ, tôi muốn có một bộ công cụ GUI tối giản, đơn sắc cho phép kiểu tích hợp theo phong cách Emacs hay acme
    • Tôi nhìn chung đồng ý, nhưng cũng muốn nhắc rằng Tk vẫn âm thầm tiếp tục hoạt động và đến nay vẫn hữu ích. Có thể kể đến các ví dụ như gitk

  • Tôi không hiểu TUI thì “dễ tự động hóa” ở chỗ nào. Chẳng phải nó giống GUI hiển thị trong console sao?

    • Nhiều TUI cung cấp các cờ hoạt động như ngôn ngữ script khi mở chương trình. Ngoài ra, với LLM thì tương tác với giao diện dựa trên văn bản dễ hơn và rẻ hơn so với GUI native tử tế hoặc ứng dụng Electron nặng về JavaScript

  • Bài này bỏ lỡ lý do cốt lõi khiến TUI “quay trở lại”. Bản thân lập luận đó cũng đáng nghi, nhưng đúng là nó có vẻ đã nổi lên gần đây khi các coding agent như Claude được vibe coding hàng loạt
    Lập trình viên thích con đường dễ dàng. Làm TUI đa nền tảng dễ hơn làm GUI
    Đây cũng là lý do ứng dụng web trở nên phổ biến. Dùng công cụ trình duyệt thì dễ làm ứng dụng đa nền tảng hơn, và Electron nổi lên cũng cùng logic đó nhưng bỏ được gánh nặng hỗ trợ đa trình duyệt. Làm UI phản hồi tốt, render UI theo kiểu đa nền tảng, xử lý input người dùng, đặc biệt là có tính đến accessibility, đều là việc khó. Vì thế lập trình viên sẽ lao ngay vào bất cứ thứ gì giúp làm những việc đó dễ hơn
    Gần đây cũng có những thay đổi khiến việc làm TUI dễ hơn. Hỗ trợ đa nền tảng cho các tính năng nâng cao đã tốt hơn, xuất hiện các thư viện nổi tiếng giúp trừu tượng hóa chi tiết phức tạp, và có lẽ những điều đó đã dẫn tới cuộc phục hưng TUI gần đây
    Ngoài ra, các luận điểm khác của bài viết cũng hơi đáng nghi. Ví dụ tác giả chê ứng dụng Electron vì thiếu nhất quán, nhưng ngay cả các TUI phổ biến cũng hầu như chẳng có tính nhất quán nào ngoài vài quy ước. Các coding agent có dùng phím tắt tương tự nhau, nhưng chủ yếu vì chúng đều bắt chước Claude. Những phím tắt đó không mở rộng tốt ra ngoài phạm vi coding agent, và phần lớn TUI tôi dùng có phím tắt lẫn ngôn ngữ thị giác khá khác nhau

    • Tôi không rõ ý câu “làm UI phản hồi tốt là khó” là gì. Nghe giống đang nói về web, mà dù một vài ý tưởng từ web có thể liên quan, trong ngữ cảnh GUI native thì có vẻ lạc đề. Ý là “làm UI tốt” hay “làm bộ công cụ UI” chăng?
      Câu “render UI theo cách đa nền tảng là khó” cũng đáng nghi. Đúng là cần một lớp tương thích và cần số lượng implementation tương ứng với số nền tảng, nhưng có vẻ không khó hơn quá nhiều so với chỉ hỗ trợ một nền tảng. Trừ khi cách render của các nền tảng mục tiêu khác biệt đến mức khó thiết kế một API chung, còn ở mức vẽ pixel lên màn hình thì có lẽ không đến mức đó. Tất nhiên phải xử lý những thứ như scaling, nhưng ngoài ra đáng ra khá thẳng, hoặc không thì đã có SDL
      Có lẽ ý họ là làm cho UI trông “giống native” trên mọi nền tảng. Cái đó có thể buộc phải dùng bộ công cụ GUI native được ưa chuộng của từng nền tảng, mà chúng không chỉ rất khác nhau với nhau mà còn có thể lớn hơn và kém ổn định hơn nhiều so với API render mức thấp. Mấy chuyện đó thì đời người quá ngắn. Tôi sẽ để chỗ cho việc đổi theme màu hay một vài phong cách đồ họa, nhưng ở mức thiết lập của ứng dụng thôi. Tôi không muốn phí thời gian đọc các thiết lập đồ họa của từng hệ điều hành
      Câu “xử lý input người dùng, đặc biệt là accessibility, là khó” cũng lạ. Lắng nghe sự kiện bàn phím và chuột là chuyện vặt. Về mặt accessibility thì đúng là cần điều hướng bằng bàn phím cho tử tế và điều đó cũng quan trọng với khả năng sử dụng nói chung, rồi còn hỗ trợ phím tắt chuẩn lẫn tùy chỉnh, nhưng nhìn chung vẫn có vẻ dễ hơn nhiều so với những phần còn lại
      Hỗ trợ screen reader có thể khó tùy theo API của từng nền tảng và khác biệt giữa chúng, nhưng đó gần với vấn đề render hơn là vấn đề input

  • TUI không hẳn là “comeback”, mà giống như việc chúng ta đã đánh mất tri thức lập trình GUI native nên đành tận dụng những công cụ mình còn có. Đó là hệ quả của việc thiếu phát triển và đầu tư nhất quán
    Ngoại trừ vài ngoại lệ sáng sủa như Qt, nền văn minh UI đã sụp đổ và chúng ta đang sống trong thời hậu tận thế
    Nó gợi nhịp điệu giống bài nói Preventing the Collapse of Civilization, và giờ AI đang viết rất nhiều code nên tôi còn lo sự sụp đổ tri thức này sẽ lan rộng hơn nữa

    • Mỗi lần chủ đề này xuất hiện trên lobste.rs là tôi lại xen vào, nên ở đây chắc cũng phải xen vào. Mọi “đế chế” GUI đều đang sụp đổ ngay trước mắt. Windows, macOS, GTK, các sản phẩm của Mozilla, tất cả đều thế
      Cảm giác như ta cần một phiên bản After Virtue cho khoa học máy tính, và có lẽ sự hiện diện trực tuyến của Blow phần nào đang đóng vai đó. Dù sao thì tôi cũng nhớ thời các giao diện máy tính thể hiện tính nhất quán, tôn trọng người dùng, và đền đáp cho việc học hỏi lẫn sự chăm chút

  • Bài này có vẻ không có nhiều nội dung thực chất, chỉ như đang nói rằng tác giả cho rằng mọi thứ khác đều tệ
    Nếu phải nói một điều thì Emacs là một nền tảng tuyệt vời cho giao diện văn bản, bàn phím, nút bấm và rich media

  • Khả năng lớn là vì người ta bắt đầu dùng các thư viện TUI bằng Go, Rust, giờ thì cả Zig, thay vì ncurses. Dù sao chúng cũng giải quyết được những vấn đề tương thích kinh khủng từng khiến ncurses trở nên cần thiết
    Rồi sau đó người ta bắt đầu làm terminal mới và cũng thúc đẩy công nghệ ở phía đó. Một phần vì giờ có thể làm bằng Go, Rust, Zig thay vì C
    Khi cho người ta lựa chọn tốt, vui hơn và ít bực mình hơn C và C++, dĩ nhiên họ sẽ bắt đầu viết ra code mới mẻ và hữu dụng hơn

  • Lý do thật sự khiến TUI quay lại là vì đến năm 2026, để phân phối GUI đã ký và công chứng thì bạn phải trả tiền cho Apple, còn với Windows thì cũng phải trả tiền cho nhà cung cấp chứng chỉ

    • Chẳng phải binary TUI native cũng gặp cùng vấn đề đó sao?

  • Đính chính nhỏ: thư viện UI tăng tốc bằng GPU của Zed là gpui, không phải API đa nền tảng wgpu

  • Tôi không chắc bài viết đã chứng minh được luận điểm của nó chưa, nhưng với tư cách người từng sống qua thời MS-DOS và luôn thích TUI, tôi xin góp vài lời. Nếu từng dùng afl-fuzz thì có lẽ bạn sẽ hiểu
    Về lý thuyết, trên Linux TUI đáng ra phải thành công hơn nhiều. Đã có một nhóm người dùng kỹ thuật thích thẩm mỹ dựa trên văn bản, và còn có “lợi thế” là môi trường GUI thô ráp, thiếu nhất quán. Đã từng có thời chỉ riêng việc làm cho card đồ họa hoạt động đúng với X server cũng đã là một vấn đề
    Đồng thời, suốt hàng chục năm các nhà phát triển phần mềm *nix cảm thấy có nghĩa vụ phải hỗ trợ cả những loại terminal cũ kỹ và kỳ lạ. Cứ như thể ứng dụng mà không render đúng trên DECwriter thì sẽ có chuyện nghiêm trọng xảy ra vậy, và dưới những ràng buộc như thế thì rất khó làm ra TUI tốt
    Ở thời MS-DOS, những công ty như Microsoft, Borland, Norton đã hoàn thiện các giao diện dựa trên văn bản vừa đầy đủ chức năng vừa phản hồi nhanh. Trên Linux, trong thời gian dài “đỉnh cao” của thiết kế TUI lại là con quái vật menuconfig, và nếu nheo mắt thì có lẽ còn gọi vim là TUI được. Hồi người ta còn thực sự dùng console chế độ văn bản, TUI Linux tốt duy nhất tôi nhớ được có lẽ là trình quản lý tệp Midnight Commander, lấy cảm hứng từ Norton Commander