Việc xây dựng Terminal UI giờ đã trở nên dễ dàng hơn

 (hatchet.run)
22 điểm bởi GN⁺ 2026-02-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • Giới thiệu trường hợp đội ngũ Hatchet đã phát triển nhanh giao diện người dùng trên terminal (TUI) bằng Claude Code
  • Sử dụng stack Charm (Bubble Tea, Lip Gloss, Huh) để hiện thực mô hình phát triển dựa trên thành phần ở mức tương đương React và phong cách hiển thị nhất quán
  • Vẫn dùng cùng API như web UI hiện có, nhưng nâng cao hiệu quả cho lập trình viên bằng giao diện tập trung vào văn bản, mật độ thông tin cao
  • Claude Code chạy các phiên tmux và tự động hóa kiểm thử, đóng vai trò lớn trong việc phát triển lặp lại và đảm bảo độ ổn định
  • Hatchet TUI hoàn thành chỉ trong 2 ngày được đánh giá là một ví dụ cho thấy mức cải thiện năng suất thực tế từ phát triển dựa trên LLM

Động lực phát triển TUI

  • Đội ngũ Hatchet muốn có một TUI tương tự k9s, và người dùng đánh giá nó nhanh hơn và trực quan hơn web UI
    • Trong phản hồi của người dùng có ý kiến rằng “CLI và TUI cho hiệu năng tốt hơn nhiều”
  • TUI cho phép trực quan hóa và thực thi workflow ngay trong cùng môi trường với mã nguồn, nên không cần chuyển qua lại giữa các tab
  • Vì người dùng chính của Hatchet là các lập trình viên làm việc trong IDE, mục tiêu là mang đến trải nghiệm quản lý workflow ngay trong terminal

Stack công nghệ

  • Sử dụng stack Charm tương ứng với stack frontend phổ biến (React, Tailwind, v.v.)
    • Các thư viện chính: Bubble Tea, Lip Gloss, Huh
    • Được đội ngũ Charm bảo trì, có tài liệu và ví dụ phong phú
  • Dùng Lip Gloss và theme của Huh để áp dụng phong cách nhất quán cho toàn bộ TUI
    • Cùng một theme cũng được tái sử dụng cho các lệnh Hatchet CLI để mang lại trải nghiệm người dùng thống nhất
  • Việc tùy biến ngoài Bubble Tea có phần khó hơn, nhưng vẫn đơn giản hơn nhiều so với tự xây một engine render dựa trên React

Cách tiếp cận kiểm thử

  • Claude Code trực tiếp chạy các công cụ trên terminal để thực hiện kiểm thử
    • Dùng tmux capture-pane để chụp view đã render và xác minh đầu ra có đúng hay không
  • Cách này đặc biệt hiệu quả cho việc tự động hóa vòng kiểm thử đầu tiên, và vẫn có thể xác nhận render ổn định ngay cả khi số lượng view tăng lên
  • Sau đó kết hợp kiểm thử thủ công và unit test để hình thành vòng lặp phát triển lặp lại ổn định
  • Claude Code được tối ưu cho các tác vụ lặp lại trong môi trường ASCII, nên vòng phản hồi kiểm thử hội tụ rất nhanh

Xây dựng môi trường phát triển hiệu quả

  • Claude Code nâng cao hiệu quả phát triển bằng cách tham chiếu phần triển khai frontend Hatchet hiện có
    • Tận dụng cấu trúc component đơn giản dựa trên React và đặc tả OpenAPI để thiết lập ranh giới rõ ràng
    • Có thể phát triển dựa trên đặc tả thông qua REST API client được tạo tự động
  • Việc triển khai renderer dựa trên DAG là phần khó nhất, nhưng
    • Tham khảo mermaid-ascii để triển khai thành công trình render đồ thị ASCII
    • Dù chưa hoàn hảo, vẫn có được chức năng trực quan hóa DAG hoạt động được

Kết quả và bài học

  • Tổng thời gian phát triển là khoảng 2 ngày, nhanh hơn và ổn định hơn nhiều so với lần refactor frontend trước đó
  • Việc phát triển với Claude Code được đánh giá là trường hợp đầu tiên cho thấy mức tăng năng suất thực tế, không mơ hồ
  • Trong tương lai, đội ngũ Hatchet dự định tiếp tục mở rộng dần phát triển dựa trên LLM cho các tính năng ngoài đường đi cốt lõi
  • Bài học then chốt là tầm quan trọng của vòng phản hồi ngắn, tính mô-đun, thiết kế dựa trên đặc tả và kiểm thử liên tục
  • Hatchet TUI hoàn chỉnh đã được công bố tại https://tui.hatchet.run và hiện đang thu thập phản hồi từ người dùng

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-15
Ý kiến trên Hacker News

  • Có một sự mỉa mai là trang web nói về hiệu năng UI terminal, nhưng lại bị giật khi cuộn ngay trên chiếc Dell XPS hiệu năng cao của tôi vì các hiệu ứng phức tạp như CSS mask compositing hay cubic gradient
    Theo Gemini, đây là kiểu “Scrim hoặc Easing Gradient”, dùng 16 điểm dừng màu để tạo hiệu ứng fade mượt, nhưng đổi lại là phải tính lại màu của hàng triệu pixel mỗi lần cuộn
    Trên Firefox thì hầu hết các trang cuộn mượt, nên tôi khuyên nên thử cả trên laptop hiDPI dùng iGPU chứ không chỉ trên Mac
    Nhân tiện, cũng có ảnh khi tắt gradient — liên kết

    • Chuẩn đấy. Trước mắt tôi sẽ xem xét bỏ hiệu ứng đó để cải thiện hiệu năng, hoặc loại bỏ hẳn. Cảm ơn vì phản hồi
    • Nói là “ở mức Commodore 64” thì hơi quá. Thực ra C64 cuộn mượt được mà
    • Có người chia sẻ cách đọc bằng Firefox hay trình duyệt khác không cần CSS hay JS. Họ đưa ra một script đơn giản dùng busybox ssl_client và grep để trích HTML rồi mở bằng Firefox
    • Tôi thấy khá rõ là trong bài blog, Claude Code được nhắc đến nhiều một cách đáng chú ý
    • Đừng đổ lỗi cho Commodore 64 của tôi. Khi chương trình đã load xong thì nó chạy rất mượt ở 50~60Hz

  • Tôi thấy việc TUI cố trông giống GUI hơi buồn. Nó kém về khả năng truy cập, cấu trúc bị làm phẳng, nên người dùng không thể dùng ngoài cách đã được định sẵn. Trong khi đó GUI hiện đại gắn kết với OS về mặt cấu trúc nên linh hoạt hơn nhiều

    • Tôi không đồng ý. Với một số nhóm bài toán, TUI phù hợp hơn hẳn. Ví dụ, hộp thoại cấu hình gói Debian tiện hơn nhiều so với văn bản thuần, và vẫn hoạt động tốt qua SSH hay serial console. Nó cũng hữu ích trong những trường hợp cần thông tin trực quan như công cụ hiển thị biểu đồ CPU
    • Tôi dùng TUI vì thích việc không phải cài thêm một ứng dụng Electron. Nó nhẹ hơn, không nhúng sẵn trình duyệt nên đỡ lãng phí tài nguyên
    • Tôi cảm thấy chính các ràng buộc của TUI lại giúp nhà thiết kế UI tập trung hơn. Ứng dụng bây giờ hay giấu menu nên bất tiện, còn TUI thì rõ ràng
    • Tôi thích việc mọi thứ đều chạy trong terminal. Workflow của tôi xoay quanh các trình multiplex như tmux, nên cứ bật thêm cửa sổ riêng là đứt mạch làm việc. Chính các giới hạn đó lại tạo ra sự đơn giản và nhất quán
    • Nhìn vào các ví dụ như Emacs, Vim, mc, htop, mutt thì thấy TUI đủ mạnh rồi. Không phải mọi UI đều cần phải lòe loẹt

  • So với trước đây, việc phát triển TUI giờ dễ hơn nhiều nhờ các framework như BubbleTea, Textualize và Ratatui.
    Nhờ LLM mà giờ có thể tạo nhanh những công cụ như thế, và tôi đang bảo trì thư viện biểu đồ TUI tên là NTCharts
    Nhờ khả năng hiểu không gian của Gemini, tôi đã sửa được bug, và hiện đang làm một trình xem hội thoại LLM cục bộ bằng BubbleTea
    Liên kết liên quan: NTCharts issue, dự án thinkt

  • Tôi không hiểu nổi sự ám ảnh với TUI trong các ứng dụng LLM. Nhìn Copilot trong VS2026 thì GUI hiển thị được nhiều thông tin hơn hẳn trong thời gian ngắn. Có thể bấm vào diff theo thời gian thực để kiểm tra nên hiệu quả hơn

    • Tôi dùng VSCode, và từ khi có thể mở sidebar AI agent ra thành cửa sổ riêng thì thấy tiện hơn Claude Code rất nhiều. Mật độ thông tin trực quan và độ chính xác đều cao hơn TUI hẳn
    • Lý do rất đơn giản. TUI là cách đơn giản nhất để nhanh chóng dựng UI lên trên hệ thống tệp. Nếu làm bằng công nghệ web thì cần cả trình duyệt lẫn server
    • Tính năng của Claude Code thì ổn, nhưng tôi thấy UI xem trước diff AI của VSCode tốt hơn nhiều. Chỉ là bản tích hợp mới vẫn còn khá nhiều bug
    • Thật ra cái này hơi giống một kiểu LARP (đóng vai). Chỉ là hành động mang tính biểu tượng để trông như “hacker thứ thiệt”, nhưng thực chất vẫn là ứng dụng web làm bằng React/CSS

  • Trong thời đại LLM đang ngốn tài nguyên tính toán, nó lại vô tình tạo động lực để làm ra những công cụ dùng stack nhẹ hơn.
    Viết bằng C giúp tăng hiệu năng CPU lên hàng nghìn lần và giảm RAM xuống một nửa. TUI là một ví dụ hay cho kiểu hiệu quả đó

    • Dù vậy, GUI native hay các framework như Flutter vẫn có thể cho hiệu năng tốt hơn TUI
    • Tôi vẫn nghi ngờ việc tối ưu có thể bù lại được bao nhiêu so với năng lượng đã dùng để huấn luyện LLM
    • TUI cũng tốt ở chỗ giảm phụ thuộc. Trước đây cần 100 gói npm, giờ 200 dòng JS là đủ

  • Tôi vẫn nghĩ Midnight Commander (mc) là một trong những TUI tốt nhất. Nó cung cấp gần như đầy đủ tính năng của bản GUI (Double Commander) mà vẫn có thể chạy từ xa.
    Hiện tôi đang làm skin mới và hy vọng nó sẽ được đưa vào bản phát hành kế tiếp

    • Cá nhân tôi thấy Far Manager hay Dos Navigator ổn định hơn
    • Cảm ơn các nhà phát triển của mc

  • Gemini đã tạo cho tôi một TUI cho dự án scraper DHT — ảnh
    Bản đầu tiên cần chỉnh vì vấn đề với ký tự CJK, nhưng nhìn chung rất ấn tượng. Nhờ vậy tôi có thể tập trung vào thuật toán

    • Tôi tò mò không biết đã dùng thư viện nào
    • Tôi quan tâm tới các dự án liên quan DHT. Muốn biết nó được ứng dụng thế nào trong công cụ tìm kiếm chẳng hạn
    • Có người xác nhận “DHT” là viết tắt của Distributed Hash Table. Và đánh giá đây là một TUI rất đẹp

  • Tôi không thấy rõ TUI tốt hơn web form hay GUI ở điểm nào. Nhưng khả năng ghép pipeline CLI thì tôi thấy cực kỳ mạnh

    • Một số tổ chức (NSA, CSE, GCHQ...) cấm UI quản trị web vì lý do bảo mật. Vì thế sản phẩm của chúng tôi được quản trị bằng TUI qua console cục bộ hoặc SSH. Chúng tôi dùng cấu hình SELinux MAC rất hạn chế
    • Với các ứng dụng có thể chạy song song cùng CLI thì TUI rất tiện. Dễ chia cửa sổ bằng tmux/zellij, mà khác biệt UI giữa các OS cũng ít hơn
    • TUI đặc biệt hữu ích trong môi trường SSH. Ngay cả trên client SSH của điện thoại thông minh cũng chạy tốt
    • Gemini từng tạo TUI cho dự án C# của tôi, nhưng sau đó lại đề xuất nhúng web server Kestrel sẽ tốt hơn. Và đúng là như vậy
    • TUI cho keybinding tốt và có thể truy cập ngay tại nơi chạy lệnh, nên rất hợp cho các tác vụ nhanh

  • Tôi thích Claude Code, nhưng cảm thấy cấu trúc TUI dựa trên React thật sự rất kém hiệu quả

    • Đặc biệt khi cuộn văn bản dài thì hiệu năng giảm mạnh. Có vẻ nó đã như vậy ngay từ đầu, nên tôi thắc mắc vì sao lại khó sửa đến thế
    • Nếu phần render đã dùng JS rồi, thì dùng React như một bộ máy tái sử dụng cũng có thể là hợp lý

  • Tôi đã làm frontend prompt của riêng mình dựa trên Cursor CLI — ảnh
    Tôi tích hợp git, diff và lịch sử chat, đồng thời có thể truy cập dễ dàng từ điện thoại qua Tailscale.
    Nó hiểu các quy tắc của tôi và có thể grep cả dự án, nên khả năng sử dụng rất cao