Đừng làm TUI nữa: Kỷ nguyên mới của phát triển ứng dụng Native với AI

Ngành của chúng ta có một mối quan hệ kỳ lạ với các giao diện dòng lệnh (command line interface) và terminal. Đã đến lúc chúng ta cần đánh giá lại vấn đề này.

Gần đây, tôi đang rất hào hứng trong việc thuyết phục bạn bè thử xây dựng các giao diện người dùng (UI) native. Tôi đã tự tay viết ứng dụng Mac nghiêm túc đầu tiên của mình vài tháng trước, và kể từ đó, tôi đã tạo ra nhiều sản phẩm UI native hơn cả toàn bộ sự nghiệp trước đây của mình cộng lại. Hãy cùng điểm qua một vòng nhé.

Đây là MDV.app, trình xem Markdown tuyệt vời nhất thế giới cho đến khi có ai đó viết một trình xem Markdown nghiêm túc hơn. Tôi đã viết khá nhiều về MDV và sẽ không làm bạn mệt mỏi thêm với việc quảng bá cho nó nữa. Nhưng nó thực sự rất tuyệt.

Tôi gần như không đụng tay vào việc viết mã nguồn cho giao diện này. Tại sao phải làm vậy chứ? Giống như hầu hết các giao diện người dùng khác, MDV không tạo ra bước đột phá nào cả. Đó không phải là một vấn đề hóc búa. Nhưng việc xây dựng một UI tốt lại rất khó: loại mã này tẻ nhạt, lặp đi lặp lại, đòi hỏi sự chính xác cao và bị giới hạn bởi kiến thức chuyên môn về nền tảng. Phải mất nhiều năm mới có thể giỏi được công việc này. Đó là lý do tại sao tôi không bao giờ tự tay viết chương trình này. Thay vào đó, tôi đã "triệu hồi" nó.

Tiếp tục nào:

Tôi đã dành cả năm qua để học Math Academy, từ Foundations I cho đến Machine Learning, mà bạn có thể tóm tắt ngắn gọn là “tôi đã tự học giải tích”. Tôi rất thích Math Academy và có nhiều điều để nói về nó, nhưng ở đây, nó chỉ là bước đệm cho một ứng dụng SwiftUI khác mà tôi đã tạo ra bằng ý chí: một giao diện người dùng kiểu máy tính cầm tay cho SageMath, hệ thống toán học mặc định dành cho các nhà mật mã học.

Ứng dụng này mang lại cho tôi ba lợi ích lớn: nó tự động hiển thị kết quả của Sage dưới dạng LaTeX, điều này càng trở nên hữu ích khi bạn đi sâu vào giải tích đa biến; nó cho phép trỏ-và-nhấp để sử dụng các phương thức của Sage trên các đối tượng như vector, ma trận và biểu thức (tiện hơn nhiều so với việc gõ `trig_simplify` lặp đi lặp lại); và nó cung cấp một “ngôn ngữ nhỏ” gồm các lệnh viết tắt giúp thực hiện các thao tác phổ biến (như “tính gradient của biểu thức này”) một cách nhanh chóng. [1,2;3,4] là một ma trận trong hệ thống này; bạn chắc chắn sẽ bị thuyết phục ngay thôi.

Tôi sẽ không đóng gói ứng dụng này. Nếu bạn muốn có nó, chỉ cần chụp màn hình phần này của bài viết và đưa cho Claude. Nó sẽ xây dựng thứ gì đó hữu ích cho bạn. Bạn hiểu ý tôi rồi đấy.

(nó sẽ hữu ích hơn nếu tôi dọn dẹp lại tất cả các nhãn thể loại nhạc của mình, hầu hết chúng có từ thời tôi bắt đầu rip MP3 vào năm 1997). Đây là DJ Roomba, trình phát Apple Music của tôi. Bản đồ thể loại nhạc là một tính năng khá mơ hồ. Điều không mơ hồ chính là tác nhân LLM được nhúng bên trong, có khả năng gọi các công cụ để đọc thư viện, danh sách phát gần đây và các bài hát sắp tới của tôi. “Tôi đang xuống xưởng dưới tầng hầm để đóng khung tranh; hãy cho tôi một danh sách phát không cần bỏ qua bài nào để phù hợp với tâm trạng này”. Hóa ra tâm trạng đó là “rất nhiều Kurt Vile và Tom Petty”. Không chê vào đâu được.

Nó sử dụng cơ sở dữ liệu SQLite ở phía sau, một cơ sở dữ liệu hợp lý với lược đồ rõ ràng, đây cũng là một tính năng hữu ích đến bất ngờ.

Tôi thực sự không biết nên nghĩ gì về những chương trình như thế này. Nó là một trình phát nhạc hỗ trợ bởi AI bao gồm 90% giao diện của Music.app. Music.app, kẻ thù không đội trời chung trong trải nghiệm máy tính cá nhân của tôi. Đây giống như việc tiêu diệt một con rồng trong lĩnh vực máy tính cá nhân vậy. Nhưng tôi không hề viết một dòng mã nào cho nó cả. Tôi đang phát triển phần mềm, hay chỉ đơn thuần là đang cấu hình máy tính của mình?

Hãy giữ suy nghĩ đó lại đã.

Đây là LLMwiki của tôi. Lẽ ra nên có ai đó viết một bài báo phổ biến, được chia sẻ rộng rãi về giá trị của một wiki tự vận hành (self-driving wiki), nơi bạn cung cấp tài liệu nguồn, đặt câu hỏi và nó sẽ tự viết wiki cho bạn. Một ý tưởng cực kỳ hữu ích, tôi rất vui vì mình đã nghĩ ra nó.

Việc viết Self Driving Wiki.app rất thú vị. Không giống như DJ Roomba, vốn nhúng trực tiếp một client Responses API, ứng dụng này điều khiển `claude -p` ở phía sau. Vì tôi cho rằng các tác nhân (agents) hoạt động tốt hơn khi có hệ thống tệp để "đào bới", tôi đã triệu hồi một tiện ích mở rộng hệ thống tệp ảo của macOS, giúp phản chiếu chế độ xem chỉ đọc của cơ sở dữ liệu SQLite bên dưới như một hệ thống tệp được gắn kết bên trong sandbox của ứng dụng.

Việc này có lẽ là không cần thiết? Nó có làm cho ứng dụng khó cài đặt hơn không, ví dụ như yêu cầu phải chạy từ thư mục /Applications/? Có, và cũng có. Nhưng những kiểu "cạo lông bò" (yak-shaving) này chính là niềm vui của việc phát triển phần mềm trong kỷ nguyên tiền-LLM, và tôi rất vui khi khám phá ra rằng mình vẫn có thể trải nghiệm chúng ngày nay.

(hyper-responder ở mức 2.5 với không tác dụng phụ, thứ này cực kỳ đỉnh) Đây là thứ tôi sử dụng liên tục: một trình theo dõi chỉ số dinh dưỡng (macro) bán tự động. Tôi cũng đang "phát cuồng" như bao người khác. Ứng dụng này là một tác nhân đơn giản khác đứng trước GPT5, nhận các mô tả bữa ăn rất ngắn như "đoán thử lượng calo của việc nếm bột bánh và kem phô mai (nhưng tôi không ăn miếng bánh nào)" và chuyển đổi chúng thành các ước tính lượng nạp vào.

Đây là một ứng dụng trên thanh menu giúp theo dõi nhiệt độ quanh nhà tôi bằng cách sử dụng những cảm biến nhiệt độ TP-Link rẻ tiền, thứ đang cho phép Đảng Cộng sản Trung Quốc truy cập vào Apple TV của tôi. Thông thường, sau khi lắp đặt thứ này, tôi sẽ có thể kể cho bạn nghe nhiều hơn về các giao thức và HTTP API mà chúng sử dụng để giao tiếp, nhưng tôi chẳng làm gì để tìm hiểu điều đó cả, nên tất cả những gì tôi có thể nói là có hai đường dẫn đăng nhập khác nhau để lấy thông tin từ đám mây của họ và trực tiếp từ các cảm biến nhỏ.

Cuối cùng, nói về Apple TV, tôi xin giới thiệu "chén thánh" của việc phát triển phần mềm native trên macOS: một điều khiển từ xa Apple TV hoạt động ngay trên thanh menu. Vài năm trước, tôi đã sẵn sàng trả rất nhiều tiền cho thứ này, vì tôi chính là kiểu người "mọt công nghệ" thường để MacBook mở trên đùi trong khi xem *House Of Ninjas* cùng vợ.

(và cho cả Roku TV và đầu thu Denon của tôi, vì đây là điều khiển vạn năng) Việc giao tiếp trực tiếp với Apple TV là một nỗi đau. Nhưng hóa ra mọi người đã tìm ra cách và viết các thư viện Python để làm điều đó. Tôi không "sử dụng" các thư viện đó, vì đây là ứng dụng Swift native, nhưng điều đó không quan trọng: bất cứ thứ gì được viết bằng Python cũng có thể được triển khai bằng Swift, C# hay Brainfuck. Đối với một mô hình tiên phong (frontier model), tất cả đều như nhau cả thôi.

Tôi cũng có chút tự nhận thức. Việc khoe khoang về một loạt giao diện SwiftUI mà tôi đã tạo ra rõ ràng sẽ mời gọi những lời phê bình lâm sàng và không khoan nhượng về thiết kế hình ảnh của chúng. Cứ tự nhiên đi. Nhưng: với tư cách là một người dùng App Store lâu năm, tôi khẳng định rằng những thiết kế này đều vượt xa mức trung bình. Năm năm trước, nếu tôi có một chuyên gia UI macOS trong nhóm, tôi đã vô cùng hạnh phúc khi nhận được kết quả chất lượng như thế này.

Sự thật là, tôi hầu như không coi những thứ này là "ứng dụng" (tôi không có ý định phân phối chúng). Chúng là những sản phẩm phụ của việc tôi bắt máy tính làm những việc tôi muốn, theo cách tôi muốn. Là một người đam mê Unix, tôi luôn có thể làm điều này bằng ngôn ngữ dòng lệnh. Giờ đây, việc thực hiện công việc đó với giao diện đồ họa cũng dễ dàng như vậy.

Chúng ta xây dựng giao diện terminal vì chúng ta buộc phải làm vậy, chứ không phải vì chúng ta nên làm vậy.

Nhưng trước hết, một vài lời về CLI và TUI: giao diện dòng lệnh (CLI) và giao diện người dùng terminal (TUI) đều là sản phẩm của những năm 1970, bị bó hẹp trong các giới hạn của giao diện teletype và các thiết bị đầu cuối video "ngu ngốc". Cả hai đều có xu hướng lỗi thời, thiếu thân thiện và bị hạn chế so với giao diện đồ họa. Nhưng những xu hướng này là bản chất của TUI, chứ không phải CLI. CLI có những mục đích mà không gì thay thế được. Xây dựng một CLI gần như luôn là một ý tưởng hay. Xây dựng một TUI thì gần như không bao giờ.

Quay lại năm 1999, Neal Stephenson đã viết một bài luận về giao diện dòng lệnh khiến lĩnh vực tương tác người-máy thụt lùi khoảng 20 năm. Trong đó, ông mô tả tầng lớp "tu sĩ" Unix nerds sử dụng CLI như những Morlock quyền năng, gánh vác cả ngành công nghiệp máy tính trên vai. Còn những người Eloi thì sử dụng GUI như Microsoft Word. Vì đây là kiểu "chiều lòng fan" hạng nặng, "In The Beginning Was The Command Line" đã trở thành một trong những văn bản thiêng liêng của ngành chúng ta, mặc dù chỉ có rất ít nội dung trong đó còn đúng sau 25 năm.

Trên thực tế, giao diện terminal không tồn tại vì bất kỳ sự đồng cảm đặc biệt nào giữa máy tính và người vận hành. Thay vào đó, TUI tồn tại chỉ vì hai lý do: modem, và vì những người đam mê Unix không muốn học Motif.

Tôi không thể trách họ. Tôi đã phải làm một chút việc với Motif vào giữa những năm 1990 và nó khiến tôi chán ghét việc phát triển UI trong suốt 29 năm sau đó. Curses không phải là thứ gì quá ghê gớm, nhưng bạn có thể học nó trong vòng 5 phút. Tôi không đùa đâu: bạn sẽ không chọn curses thô cho một TUI ngày nay, nhưng hãy thử hỏi ChatGPT đưa cho bạn một bản tóm tắt ngắn gọn (“đừng lãng phí thời gian giải thích các khái niệm”) về những thứ tối thiểu cần thiết để viết pico. Lấy đoạn mã nó đưa cho bạn và biên dịch nó; nó hoạt động. Rõ ràng là nên đi theo hướng đó. Chẳng có gì nhiều để bàn cả.

Một tác nhân (agent) có thể xây dựng một giao diện macOS native hợp lý một cách đáng tin cậy, nhờ vào việc sử dụng các framework SwiftUI theo cách Apple hướng dẫn. Đây là sự khác biệt giữa ứng dụng native và giao diện web: sự đồng nhất là một điều tốt: các ứng dụng native được cho là phải trông giống các ứng dụng native khác.

Nhưng đó là một trong những vấn đề của TUI: ngay cả với một framework tốt như Ratatui, Textual hay Bubbletea, bạn vẫn đang phải đấu tranh với terminal để đạt được kết quả tiệm cận với những gì mọi framework native làm tốt ngay từ đầu. Cuộn trang và các mục tiêu cuộn là một ví dụ rõ ràng. Kéo và thả là một ví dụ khác. Chọn văn bản — nó trở nên phức tạp khi bạn sử dụng tín hiệu trong băng (in-band signaling) để vẽ đường viền cửa sổ! Nhiều cửa sổ nổi. Tất cả những điều này còn chưa tính đến việc xử lý hình ảnh.

Bạn có thể dành một giờ để có được một phiên bản khá ổn của nhiều điều khiển tiêu chuẩn trong một framework TUI: bộ chọn ngày, trường văn bản bảo mật, thanh tiến trình, trình soạn thảo văn bản. Nhưng hầu hết chúng sẽ không tốt bằng các phiên bản hệ thống của cùng các widget đó, và chúng sẽ không kết hợp tốt với nhau nếu không tốn thêm công sức.

Tất cả những thứ này đều hoạt động hoàn hảo ngay từ đầu trong UI native.

Bạn sắp nói với tôi, một cách chắc chắn, lý do tại sao tất cả chúng ta sẽ sử dụng và yêu thích TUI vào năm 2046. Hãy để tôi dự đoán trước một vài lập luận của bạn.

TUI là những giao diện tiết kiệm, nhanh chóng với mật độ thông tin cao. Những người đam mê công nghệ không chỉ thích chúng vì tính thẩm mỹ cổ điển. Họ đánh giá cao việc có thể hoàn thành các tác vụ phức tạp trong vài giây chỉ với vài lần nhấn phím.

Tất cả những điều này đều đúng, nhưng để lập luận đó thuyết phục, tôi cần bắt đầu đoạn văn đó bằng từ “chỉ”, và nếu tôi làm vậy, tôi đang nói dối. Giao diện đồ họa thường không tiết kiệm, dày đặc hay thiên về bàn phím. Nhưng đó thường là vì chúng không được thiết kế cho những người đam mê công nghệ (ngay cả trên Linux, giao diện đồ họa thường được thiết kế theo hướng lý tưởng hóa cho người dùng Linux On The Desktop bình thường). Không có gì ngăn cản bạn thiết kế một GUI dày đặc và tiết kiệm cả. Người ta đã làm được rồi!

Đối với tôi, những điểm thú vị của TUI là một lập luận mạnh mẽ để thực hiện nhiều công việc đồ họa hơn, vì việc thử nghiệm những thứ này đã trở nên dễ dàng và rẻ tiền, và tôi muốn thấy một UI native được xây dựng để nắm bắt mọi thứ tuyệt vời về Magit hoặc Lazygit (mà không cần phải tự mình xây dựng).

Tiếp theo: TUI hoạt động qua kết nối SSH. Nếu bạn cần một giao diện người dùng trên môi trường production, đó sẽ là một TUI.

Vấn đề với lập luận này là bạn có lẽ không cần một giao diện người dùng trên production. Bạn cần một giao diện dòng lệnh trên production mà một giao diện người dùng trên Macbook của bạn có thể điều khiển. Bất cứ ai từng làm việc với bpftrace đều nên hiểu điều này trong xương tủy, ít nhất là đến lần thứ 3 họ xây dựng một biểu đồ cột từ các dấu thăng. May mắn thay, đã có tiền lệ cho việc này: hãy xem Emacs TRAMP, thứ giúp ẩn các kết nối SSH một cách hiệu quả và trình bày trải nghiệm trình soạn thảo native (và đồ họa, nếu đó là sở thích của bạn) cho các tệp từ xa, thậm chí hoạt động với cả LSP và Magit.

Mọi người sẽ nói với bạn rằng TUI có tính truy cập (accessibility) tốt.

Vấn đề với lập luận này là nó có lẽ không đúng. Tôi muốn cẩn thận với lập luận này, vì tôi không phải là khách hàng của các tính năng hỗ trợ truy cập. Tất cả những gì tôi có thể làm là dựa vào trải nghiệm của những người làm công việc a11y. Giống như diễn giả này mô tả cách các trình đọc màn hình đọc tất cả các cập nhật từng dòng của "chrome" TUI; dấu thăng, dấu thăng, dấu thăng, dấu thăng, dấu gạch ngang, dấu gạch ngang. Có vẻ tệ thật!

Các framework UI native hiện đại được thiết kế ngay từ đầu để thực hiện tốt tính năng truy cập. SwiftUI duy trì hai cây UI, một cây trực quan và một cây ngữ nghĩa cho tính năng truy cập. Có những framework TUI, rất đáng ngưỡng mộ, cố gắng làm đúng điều này. Tôi không ở đây để nói với bạn rằng TUI không thể có tính truy cập; chỉ là tính truy cập không phải là lý do để ưu tiên TUI hơn GUI.

Cuối cùng, tôi có thể nghĩ ra một lập luận mạnh mẽ cho TUI: chúng là đa nền tảng.