Vì sao TUI quay trở lại
(wiki.alcidesfonseca.com)- 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
- Human Interface Guidelines của Apple từng là chuẩn mực mạnh đến mức được trích dẫn trong các lớp học về giao diện người dùng trên khắp thế giới
- Xerox PARC và Apple được xem là những tổ chức tiêu biểu đã nghiên cứu thế nào là một giao diện cho con người tốt
- Gần đây Apple đang đi theo hướng phá vỡ tính nhất quán với các nguyên tắc trước đây
- macOS đang phớt lờ định luật Fitts, khiến việc thay đổi kích thước cửa sổ gần như bất khả thi, và vấn đề vẫn tiếp diễn ngay cả sau khi cố sửa, đồng thời thêm biểu tượng vào mọi menu
- macOS không còn dễ được xem là vùng an toàn để các nhà thiết kế có thể làm việc một cách yên ổn nữa
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
4 bình luận
Tôi cũng nghĩ vậy, nhưng tôi cho rằng giới phát triển đang quá nhạy cảm với xu hướng. TUI chỉ đơn giản là đang được dẫn dắt bởi những công ty không có đủ năng lực hoặc ý chí để làm GUI cho ra hồn; tôi cũng không rõ thực sự có bao nhiêu người đang dùng TUI.
Ý kiến trên Hacker News
Nếu chỉ nhìn vào con số thì lý do thực sự khiến TUI phổ biến là Claude Code, còn mọi thứ khác so ra chỉ như nhiễu nền
Ban đầu thứ khiến tôi muốn làm TUI là ý tưởng phân phối ứng dụng qua SSH. Ứng dụng SSH giống trình duyệt ở chỗ không cần cài đặt cục bộ
Một phần lớn lý do tôi thích nghịch https://pico.sh cũng là vì triển khai TUI không cần bất kỳ sự can thiệp nào từ người dùng
Có lẽ nguyên nhân là mong muốn thoát khỏi các UI nền web nặng nề, cùng với sự tò mò muốn thử giới hạn của việc render trong terminal
Thay vì xây hệ thống mới bằng công nghệ mới mẻ và thú vị, chúng ta lại đi làm trình giả lập máy chữ tăng tốc bằng GPU. Đó là một dạng kỳ lạ pha trộn giữa hoài niệm và sự mù quáng kỹ thuật
Trên SSH có thể truyền bất kỳ giao thức nào. Thà tiến tới kiểu vẽ lên màn hình bitmap từ xa còn hơn
X Window không phải thiết kế hoàn hảo, nhưng nó có tính trong suốt mạng; còn devdraw của Plan 9 là một engine render nơi chương trình đồ họa từ xa tải tài nguyên lên rồi gửi lệnh vẽ đường bằng RPC
Điều thực sự khó ở vim chỉ là trong một trình soạn thảo theo chế độ, động tác cốt lõi nhất là quay về command mode lại đòi phải với ngón tay tới phím Escape
Luồng lý tưởng là chỉnh sửa thật nhanh rồi lập tức quay về command mode, nên việc dùng Escape là tàn dư lịch sử cần phải nói rõ
Vì thế chỉ cần remap CapsLock thành Escape trên toàn hệ thống. Linux và macOS làm được chỉ bằng thiết lập GUI, còn Windows cũng xong trong 1 phút nếu tạo hoặc sửa khóa registry
Ngoài ra thì chỉ cần học căn bản với vim-tutor, rồi khi gặp tác vụ tốn thời gian thì tra thêm, nên tôi không rõ cái gọi là đường cong học tập nằm ở đâu. Vấn đề là bạn sẽ quen với modal editing quá nhanh đến mức môi trường không có nó sẽ giống như thời đồ đá
Giờ tôi nghĩ lý do vim cần hjkl thực ra là vì bố cục bàn phím quá tệ cho phím mũi tên. Máy chữ thì không có mũi tên, nhưng với máy tính thì mũi tên là cốt lõi
Phím cách cũng chẳng cần to đến thế, càng không cần để cả hai ngón cái cùng dùng. Nếu chuyển một cụm mũi tên nhỏ vào một phần bên trái hoặc bên phải của phím cách thì sẽ tốt hơn nhiều
Mẹo hjkl chỉ hiệu quả trong các trình soạn thảo dành cho hacker, nhưng ngay cả phần mềm phổ thông cũng phải dùng mũi tên rất nhiều, và bố cục hiện tại rất hại tay. Tôi bắt đầu bị viêm khi cố bấm mũi tên bằng ngón cái mà không di chuyển cả bàn tay
Nó buộc bạn phải nhấc tay ra khỏi home row rồi đặt lại, nhờ đó giảm bớt các điểm RSI có thể âm thầm tích tụ
Cũng vì lý do đó mà tay còn lại của tôi cũng dùng phím mũi tên khá thường xuyên. Dĩ nhiên tôi vẫn dùng hjkl khá nhiều
https://github.com/microsoft/PowerToys
jjlà xongNgoài ra
Ctrl + [là Esc trong terminal/ASCII chuẩn, nên có thể tiện hơn một chút so với việc với tay tới EscĐống tro tàn còn lại sau khi lợi ích riêng của các hãng hệ điều hành sụp đổ trông giống như cơn sốt TUI
Không hề có một UI phổ dụng tử tế nào. Trình duyệt là thứ đỡ tệ nhất và khá thành công, nhưng do sandbox nên nó không phù hợp hoặc gây nhiều ma sát cho các việc cần truy cập tệp cục bộ hay mạng. Ngay cả việc chạy thứ đơn giản cũng có overhead vô lý
Truy cập từ xa còn tệ hơn. Sẽ phát sinh các câu hỏi như liệu một ứng dụng đang chạy trên máy chủ Windows có thể được truy cập từ Mac hay không, hay có thể forward qua kết nối tunnel hay không
TUI là một giao thức phổ dụng đơn giản làm được điều cần làm, và tính từ xa là mặc định. Thứ dùng ở máy cục bộ cũng hoạt động tự nhiên trên kết nối SSH
Nó cũng là một cú giơ ngón giữa rất lớn gửi tới các hãng hệ điều hành từng nghĩ rằng chiến lược thắng cuộc là làm cho mọi thứ không tương thích hoặc trói người dùng vào hệ sinh thái
Notcurses và Ratatui đã giúp ncurses rất nhiều
Windows 11 là một ví dụ rất điển hình, và thật sự không cần tất cả sự phô trương đó
Tôi ước TUI đừng quay lại. Ngày nào tôi cũng sẽ chọn giao diện web thay vì TUI
Không cần cài mấy font quá thông minh, không cần vọc thiết lập terminal để hiển thị cho đúng, không cần đoán các phím tắt điều hướng mà người làm ra nó cho là tối ưu nhất
Bạn còn có chỉnh sửa văn bản thật sự với điều hướng văn bản chuẩn của hệ điều hành, tích hợp tốt hơn với trình quản lý mật khẩu, công cụ mở rộng văn bản, v.v.
Tôi sống trong CLI và mở terminal chỉ bằng một phím tắt, nhưng công nghệ đã tiến xa rất nhiều kể từ thời terminal là lựa chọn duy nhất, và hiện có nhiều cách tốt hơn để làm UI
Cả làn sóng TUI này với tôi chỉ giống một xu hướng thời trang
Vì chẳng ai đầu tư vào phát triển UI native. Electron là bằng chứng cho thấy nếu có một stack GUI dễ dùng thì các công ty sẽ chọn nó
Với ứng dụng lớn thì thời gian đóng gói và phân phối chỉ là một phần nhỏ của tổng thể, và kích thước tệp cũng không quá đáng ngại, nhưng ứng dụng nhỏ thì không như vậy
Ứng dụng cho Windows thì dễ, một binary nhỏ mở form, chạy bằng double-click và không cần cài đặt
Để làm điều tương tự trên Linux, không có gì đảm bảo GTK hay Qt đã được cài sẵn, nên nếu muốn làm bản chạy độc lập thì về cơ bản phải gửi kèm gần như cả hệ điều hành. Kết quả là tệp trở nên cồng kềnh
Python cũng bất tiện vì người dùng Windows либо phải có Python sẵn, hoặc bạn phải gửi kèm interpreter
Phương án thay thế khả dĩ nhất là kiểu Java: chạy một tệp
.jarduy nhất trên bất kỳ hệ thống nào, nhưng Oracle đã đổi giấy phép và JavaFX không còn đi kèm Java nữa. Swing vẫn còn đi kèmTôi chỉ muốn hiện một thanh menu có phím tắt bàn phím, vậy mà không hiểu vì sao lại không có kiểu VM cho menu bar giúp truy cập menu bar trên mọi hệ điều hành
Việc gửi nguyên cả trình duyệt bằng Electron là ngớ ngẩn. Đúng ra người dùng nên cài một nền tảng kiểu phiên bản desktop của ứng dụng Flash, rồi mọi ứng dụng dùng chung nó
Có khi phân phối game DOS còn dễ hơn ứng dụng desktop, vì ai muốn chạy game DOS hẳn đã cài sẵn trình giả lập DOS rồi
Điều cần có là một framework dễ dùng, đa nền tảng, mã nguồn mở, và nếu có thể thì dùng được từ ngôn ngữ lập trình mà bạn chọn
Vấn đề lớn hơn là nhân lực. Có rất nhiều người biết phát triển web, nên người ta muốn dùng chính lực lượng đó cho desktop, và nếu desktop dùng JavaScript như Electron thì điều đó dễ hơn nhiều
Tôi không thật sự hiểu các terminal UI cố tái tạo tính năng kiểu GUI. Giao diện máy tính chẳng phải nên tốt hơn lên sao
Giờ đâu còn cần phải bị giới hạn trong lưới ký tự chỉ để giả vờ vẽ đường và hình nữa. Thậm chí muốn hiển thị ảnh cũng không thể nếu không có các terminal phi chuẩn như Kitty hay iTerm
Điều đáng tiếc là không có một hệ thống streaming UI đa nền tảng thật sự xuất sắc. Web tự nó đã khá tốt, nhưng rõ ràng phải có thứ tốt hơn cho mục đích này. Flutter cũng ổn, nhưng thiếu tính on-demand và bị ràng buộc với Dart quá nhiều
Mọi người muốn GUI, nhưng cuối cùng lại phải đi đường vòng bằng thứ giống GUI bên trong TUI
Họ muốn một thứ di động, chạy từ xa được, an toàn hơn vì không phải phơi socket ra ngoài, và không cần dựng cả desktop lên
Các cửa sổ không gốc gần như đã chết, thứ còn lại là giao diện web cùng mọi vấn đề của nó, hoặc TUI chỉ cần một kết nối SSH mà ai cũng đã có
Trước đây có thể ráp nhanh bằng Tcl/Tk rồi mở cửa sổ qua X Window, nhưng ngày nay không còn dễ nữa và cũng chẳng ai dùng X từ xa
Mẫu số chung nhỏ nhất là SSH, và chỉ những gì phù hợp với nó mới sống sót
Nhiều terminal bị nói là không hỗ trợ cũng dựa trên GNOME VTE, và hỗ trợ bên đó đang được triển khai; nhìn bug tracker thì có vẻ gần xong rồi
Ngay cả xterm, thứ gần với terminal chuẩn nhất trên X11, cũng nằm trong số đó
[0] https://www.arewesixelyet.com/
Cũng chẳng có bộ công cụ GUI nào thật sự chắc chắn và đáng tin, mà cái nào cũng đầy lỗi và lưu ý riêng
Flutter nghe thì ổn, nhưng phải bỏ qua chuyện quá trình build ứng dụng Flutter bản thân nó là cơn ác mộng. Ngay cả Flutter cũng không cho cảm giác được thiết kế để ai cũng có thể biên dịch; trên thực tế chỉ là distro đang che giấu vấn đề đó mà thôi
Và UI nền web cũng không nhất thiết phải nặng nề. HN là ví dụ như vậy
Dù tôi luôn mở terminal, tự động hóa cuộc sống bằng script Bash, và dùng VIM/TMUX, thì phần lớn TUI vẫn kém một GUI tốt tới hai bậc
Điều hướng và phím tắt tùy hứng, copy-paste hỏng hóc, thiếu tích hợp với môi trường là những ví dụ điển hình
Vấn đề cốt lõi là không có một nền tảng GUI đa nền tảng tử tế nào được tích hợp đúng nghĩa với ngôn ngữ lập trình hoặc là một phần của thư viện chuẩn
Swing thiếu khả năng truy cập các thành phần trình duyệt native, Tk thiếu component trình duyệt và kéo-thả, wxWidgets có cộng đồng nhỏ và các binding có vẻ đã phải hồi sinh hơn một lần
Qt thì lúc nào cũng có nguy cơ tự phá vì muốn kiếm thêm tiền, bản thân tôi cũng không coi KDE là quan trọng đến thế, và nghi ngờ liệu cộng đồng KDE có thể gánh nổi một bản fork trong dài hạn hay không
Còn lại là Electron hoặc các biến thể chồng JavaScript/CSS lên component trình duyệt rồi gắn callback máy chủ cục bộ; bỏ qua chuyện overhead bộ nhớ và runtime lớn ngay cả với app nhỏ, thì mô hình lập trình đó vốn đã tệ
Để làm ra một GUI toolkit đa nền tảng tử tế cần rất nhiều tiền và con người cho khả năng sử dụng, khả năng tiếp cận, thiết kế, tài liệu, kiểm thử. Cộng đồng mã nguồn mở đã không làm được điều đó, GTK về thực chất đã trở thành Linux-only, và cũng không có ứng viên hiện đại nào thay thế Qt hay Swing
TUI không phải lời giải cho vấn đề cốt lõi, nhưng nhìn vào các lựa chọn khác thì tôi hiểu vì sao các lập trình viên lại chọn TUI cho UI đa nền tảng. Có lẽ khoảng 80% nhu cầu GUI cũng có thể được đáp ứng bằng GUI toolkit có renderer TUI
Như vậy mới cung cấp được API và ABI ổn định, đồng thời cho phép binding từ nhiều ngôn ngữ khác mà không cần vòng vo phức tạp. Điều này đặc biệt quan trọng với các ngôn ngữ biên dịch
Việc bind Qt vào Python có thể dễ, nhưng nếu gắn vào ngôn ngữ như Free Pascal thì cần một thư viện C++ trung gian phơi ra C API, và ứng dụng còn phải phân phối cả thư viện đó
Đáng tiếc là đa số GUI toolkit được viết bằng C++ hoặc ngôn ngữ khác chứ không phải C, khiến việc dùng chúng trở nên đau đớn nếu ngôn ngữ yêu thích của nhà phát triển không phải là ngôn ngữ đó. Trong số các lựa chọn chính thống, gần như thứ duy nhất viết bằng C là GTK, nhưng GTK lại hầu như không quan tâm tới khả năng tương thích ngược đúng nghĩa
Có thể nghĩ rằng thư viện viết bằng ngôn ngữ nào cũng được miễn là chỉ lộ ra C API, nhưng nếu nó không được phân phối rộng rãi thì bạn có thể sẽ muốn static link. Và ngoài C/C++ thì đây lại thành vấn đề
Ví dụ, tôi từng muốn làm backend FLTK cho Lazarus[0]; FLTK là thư viện C++ và khuyến nghị static link, nên tưởng như có thể tạo ra binary GUI độc lập
Nhưng tôi phải tự làm C wrapper trước, rồi trên Linux việc static link một thư viện C++ từ ngôn ngữ không phải C/C++ mà không có các cờ ma thuật do g++ truyền cho linker là cực hình; còn trên Windows, hay ít nhất là với msys2, thì không thể làm được nên tôi bỏ cuộc
[0] https://i.imgur.com/W6XbLkr.png
Nó có giao diện rất gần native trên macOS và Windows, và lập trình dễ hơn Qt rất nhiều. Với tư cách người dùng, và đôi khi là lập trình viên, thì trong số GUI đa nền tảng tôi thích wxWidgets nhất
Ngược lại, với tư cách người dùng tôi thực sự ghét tổ hợp Electron hoặc component trình duyệt + JavaScript/CSS + callback máy chủ cục bộ. Dù phải từ bỏ tính năng và quay lại dòng lệnh thì tôi cũng muốn tránh các app kiểu này
Chúng không hỗ trợ cả các phím tắt bàn phím chuẩn, trông thì lệch tông kỳ cục, và hay khựng ở những chỗ không ngờ tới
Trong các framework TUI cũng có vài cái gần đạt đến mức đó. Điểm tốt là có thể dùng qua SSH v.v. mà không phải tốn nhiều công sức, nhưng vẫn có cảm giác chúng đang giải sai bài toán
Thay vì làm cho mọi thứ trông hay hoạt động như IDE, tôi muốn có CLI tập trung và có thể kết hợp hơn, cùng với thứ gì đó như tmux nhưng quản lý cửa sổ và tính bền vững đỡ tệ hơn
Chỉ cần tạo một REPL đơn giản có readline là sẽ có hành vi chuẩn và dễ đoán
Dù vậy tôi vẫn thích việc xu hướng này đang thúc đẩy cải thiện terminal emulator
Các TUI tôi xem qua có vẻ phần lớn đều phụ thuộc NPM
Thật kỳ lạ vì trông như các agent còn chẳng có thời gian để tự viết lại chính mình thành thứ gì đó không phải đám cháy lốp xe bảo mật
Tất cả câu chuyện về việc các agent sẽ thống trị mọi thứ cuối cùng lại khiến tôi nghĩ đó chỉ là sản phẩm của kiểu người startup biến-rác-thành-rác, những người chẳng cần lo lắng về kết quả nào khác ngoài việc nó chưa đủ nhanh
Ví dụ OpenCode đến giờ vẫn không làm đúng nổi điều cơ bản là giữ toàn bộ log tin nhắn rồi gửi log đó theo đúng thứ tự tới SSE endpoint để nhận phản hồi tiếp theo, và ngay cả khi tắt cắt tỉa ngữ cảnh thì lỗi trượt cache prompt vẫn xảy ra thường xuyên
Trải nghiệm phát triển cũng tuyệt vời và không cần npm
curl | bashViệc để cho lập trình viên phần mềm tự thiết kế giao diện người dùng ngay từ đầu đã là chuyện kỳ quặc
Có vẻ họ không có khả năng làm giao diện người dùng không dựa trên văn bản. Kiểu như nếu để thợ ống nước thiết kế nhà thì họ sẽ làm mọi sàn dốc xuống để tiện đi đường ống
Nếu cần di chuyển và thay đổi kích thước nhiều cửa sổ thì họ làm cửa sổ văn bản, nếu cần chọn nhanh tùy chọn thì họ làm hộp văn bản, và nếu cần viết nhanh tài liệu có kiểu dáng và định dạng thì họ lại bắt viết thêm nhiều văn bản hơn để biểu diễn định dạng
Nhưng rồi lại không làm ra ứng dụng nào giúp xem chính văn bản đó một cách dễ dàng trong trạng thái đã được định dạng
Họ được phép làm thế, và nếu không thích thì đừng dùng
Nhìn thì đẹp, nhưng gần như vô dụng cho việc phát triển phong cách ứng dụng hay các tác vụ phức tạp hơn quản lý tệp
TUI tốt cho những người sống trong terminal
Không bị xao nhãng bởi nội dung thị giác, cực kỳ hiệu quả bằng bàn phím, và giờ đây AI có thể tạo ra chúng rất nhanh. Ngày xưa chuyện đó thật sự rất đau đớn
Khán giả của TUI tăng lên nên TUI cũng trở nên phổ biến hơn
Trong 80 cột văn bản thì cũng chẳng có nhiều thứ mà quản lý sản phẩm có thể “tinh giản” đi được
Chẳng phải việc không một ông lớn công nghệ nào từ bỏ trình duyệt mới là điều sai sao?
Ý 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 đã 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
[
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
Đô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
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 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?
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
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
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ỉ
Đí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