Sự trở lại của TUI: Khi giao diện dòng lệnh lại lên ngôi
Giao diện người dùng dạng dòng lệnh (TUI) đang quay trở lại mạnh mẽ do sự bất nhất của các ứng dụng native và sự cồng kềnh của Electron. Bài viết phân tích xu hướng này và lý do tại sao các nhà phát triển lại tìm về sự tối giản.

Sự trở lại của TUI: Khi giao diện dòng lệnh lại lên ngôi
Giao diện người dùng trên thiết bị đầu cuối (TUI - Terminal User Interfaces) đang thực sự quay trở lại và trở thành một xu hướng đáng chú ý. David Heinemeier Hansson (DHH), cha đẻ của Ruby on Rails, đã minh chứng cho điều này thông qua bản phân phối Omarchy mới của mình. Omarchy là sự kết hợp của ba loại giao diện: TUI để có phản hồi tức thì và điểm số "geek", ứng dụng web vì nhu cầu kinh doanh SaaS của 37signals, và những ứng dụng native kiểu GNOME vốn không thực sự phù hợp với phong cách của distro này.
Omarchy distro
Mô hình này cũng từng xảy ra khoảng 10 năm trước trong thị trường trình soạn thảo code. Chúng ta chuyển từ các trình soạn thảo native như BBEdit, TextMate, Notepad++ và Sublime sang các ứng dụng dựa trên Electron như Atom, VSCode và các bản fork của nó. Tuy nhiên, nhóm lập trình viên "hardcore" lại chuyển sang Vim hoặc Emacs, chấp nhận đường cong học tập dốc đứng để đổi lấy phản hồi tức thì và khả năng tùy biến cao.
Sự sụp đổ của ứng dụng Native
Bài học ở đây rất rõ ràng: Các ứng dụng native đang dần thua cuộc.
Windows: Một mớ hỗn độn về API
Windows đang trở thành một trò đùa về việc chuẩn hóa thư viện GUI. Vì một API không thành công, họ lại tạo ra một cái khác, chỉ để cái đó cũng thất bại trong biển các lựa chọn thay thế. Từ MFC (1992), OLE, COM, ActiveX cho đến WinForms, WPF, Silverlight, WinUIs và MAUI... Microsoft liên tục thay đổi chiến lược. Việc tái tạo lại OS và UI API mỗi vài năm kết hợp với các nỗ lực sandboxing khiến mỗi lớp mới đều có những khoảng trống chức năng so với framework trước đó.
Linux: Sự phân mảnh
Sự không nhất quán về UI trên Linux là do thiết kế. Các đội ngũ khác nhau muốn kết quả khác nhau và họ có quyền tự do làm điều đó. GTK và Qt trở thành hai framework thống trị. Mặc dù cả hai đều hướng tới phát triển cross-platform, nhưng chúng chủ yếu chỉ phổ biến trên Linux. Do khó khăn trong việc kiểm tra hàng triệu kết hợp distros, môi trường desktop và phần cứng, hầu hết các công ty không bother với ứng dụng Linux native — họ dùng Electron hoặc để cộng đồng mã nguồn mở tự giải quyết.
macOS: Phá vỡ nguyên tắc
Apple từng là "tôn giáo một cuốn sách" với Human Interface Guidelines (HIG) nổi tiếng. Nhưng hiện tại, Apple đang cố gắng phá vỡ tất cả các nguyên tắc và sự nhất quán mà họ từng xây dựng. Việc bỏ qua Fitts’ law, làm cho việc thay đổi kích thước cửa sổ trở nên gần như không thể, và thêm biểu tượng vào mọi menu khiến macOS không còn là "thiên đường" an toàn cho các nhà thiết kế.
Vấn đề của Electron
Mọi người đều biết trải nghiệm người dùng của các ứng dụng Electron không tốt. Lời phàn nàn phổ biến nhất là tiêu thụ bộ nhớ, dù điều này đã giảm trong thập kỷ qua. Tuy nhiên, vấn đề chính là thiếu sự nhất quán về mặt hình ảnh và thiếu các quy trình làm việc dựa trên bàn phím (keyboard-driven workflows).
Hãy lấy ví dụ về Cursor (hay VSCode). Nếu bạn đang trong bảng điều khiển agent, bạn có thể chuyển sang danh sách agent ở thanh bên chỉ bằng bàn phím không? Bạn có thể lưu trữ nó không? Đây là những hành động nên giống nhau trên mọi ứng dụng macOS, nhưng các ứng dụng Electron thường quên thêm menu cho các chức năng này.
Terminal Interface
Tại sao TUI lại lên ngôi?
TUI nhanh, dễ tự động hóa và hoạt động khá tốt trên các hệ điều hành khác nhau. Bạn thậm chí có thể chạy chúng từ xa mà không đau đầu với việc chuyển tiếp X (X forwarding). Khi các bộ công cụ UI native thất bại, chúng ta quay lại những điều cơ bản. Claude và Codex đã rất thành công trên dòng lệnh: bạn tập trung vào tương tác và quên đi hệ điều hành xung quanh. Bạn có thể điều khiển code và ứng dụng trên máy chủ đám mây, hoặc truy cập từ xa vào máy có GPU từ iPad của mình.
TUI đang lấp đầy khoảng trống mà Apple và Microsoft để lại trong thế giới "hậu tận thế" nơi mọi ứng dụng trông khác nhau. Điều này tốt nếu bạn đang làm nghệ thuật (bao gồm cả trò chơi máy tính), nhưng không tốt nếu mục tiêu của bạn là lùi lại để người dùng làm việc của họ.
Chúng ta cần gì tiếp theo?
Một ô đánh dấu (checkbox) cũng là một phần của giao diện. Giao diện sẽ tốt hơn khi càng ít tư duy cần thiết: dù đó là vô lăng hay biểu mẫu trực tuyến, nếu bạn phải mất bất kỳ khoảng thời gian nào để tìm ra cách sử dụng, điều đó là tồi.
Chúng ta cần quay lại những điều cơ bản. Mọi nhà phát triển nên học lý thuyết về điều gì tạo nên một Giao diện người dùng tốt, như Nielsen, Norman hay Johnson, và ngừng coi Thiết kế người dùng là một kỹ năng mềm không quan trọng trong chương trình Kỹ thuật phần mềm. Trong bất kỳ khóa học nào, nếu UI không có ý nghĩa, dự án nên bị đánh rớt.
Lập trình đang được tự động hóa, nhưng việc hiểu rõ nhu cầu của người dùng để thiết kế giao diện hoàn hảo vẫn là công việc cần sự đầu tư nghiêm túc.


