"Nếu trình duyệt tự xây dựng giao diện cho bạn?"

Chúng ta đang đứng tại một điểm chuyển đổi kỳ lạ trong phát triển giao diện người dùng (frontend). AI hiện nay có thể tạo ra toàn bộ giao diện, và các mô hình ngôn ngữ lớn (LLM) có khả năng suy luận về dữ liệu và bố cục. Tuy nhiên — hầu hết các sản phẩm SaaS vẫn chỉ đóng gói các ứng dụng React được viết tay, mỗi ứng dụng tự xây dựng giao diện riêng, lớp hỗ trợ tiếp cận riêng, hệ thống chủ đề riêng và các điểm dừng (breakpoints) riêng. Không phải mọi dịch vụ, nhưng phần lớn.

Đây là một sự lãng phí lớn công sức cho một công việc cơ bản: hiển thị dữ liệu cho con người và cho phép họ tương tác với nó.

Tôi đã suy nghĩ nhiều về điều này gần đây và đã xây dựng một bản minh họa (proof of concept) để thử nghiệm một ý tưởng: nếu chính trình duyệt tự động sinh giao diện?

Hiện trạng của ngành

Ngành công nghiệp đang xoay quanh ý tưởng này từ nhiều góc độ, nhưng chưa ai thực sự chạm tới nó hoàn toàn.

UI điều khiển từ server (Server-driven UI) đã tồn tại từ lâu — Airbnb và các đối tượng khác đã tiên phong cho lĩnh vực này trên di động, nơi chu trình phê duyệt của cửa hàng ứng dụng khiến việc cập nhật giao diện trở nên đau đớn. Server gửi xuống một cây JSON mô tả những gì cần hiển thị, và client chỉ đơn giản là làm theo hướng dẫn. Nó rất thông minh, nhưng server vẫn là người ra quyết định.

Google vừa phát hành Natively Adaptive Interfaces — một khung framework sử dụng các tác nhân AI để biến khả năng tiếp cận thành mặc định thay vì là ý nghĩ sau cùng. Ý tưởng rất hay và cảm giác đúng đắn. Nhưng nó vẫn hoạt động trong biên giới của một ứng dụng duy nhất. Tùy chọn khả năng tiếp cận của bạn không được chuyển sang các sản phẩm của Google và, ví dụ, công cụ quản lý dự án của bạn.

Sau đó là làn sóng Generative UI — CopilotKit, AI SDK của Vercel và các đối tượng khác đang xây dựng các khung framework mà LLM sinh ra các thành phần trên chéo. Đây là các công cụ phát triển mạnh mẽ, nhưng chúng vẫn là công cụ dành cho nhà phát triển. Sự tạo ra diễn ra ở thời điểm xây dựng hoặc trên server. Dịch vụ vẫn nắm quyền kiểm soát.

Nhìn thấy xu hướng chưa? Mọi cách tiếp cận đều giữ quyền lực ở phía dịch vụ.

Đảo ngược logic

Đây là ý tưởng đằng sau trình duyệt thích ứng: nếu việc tạo ra diễn ra ở phía bạn?

Thay vì một dịch vụ gửi giao diện người dùng hoàn chỉnh cho bạn, nó xuất bản một "manifest" — một mô tả cấu trúc về những gì nó có thể làm. Các khả năng của nó, các điểm cuối (endpoints), hình dạng dữ liệu, các hành động có sẵn. Hãy tưởng tượng nó giống như một đặc tả API, nhưng mang tính ngữ nghĩa. Không chỉ "đây là điểm cuối GET" mà là "đây là danh sách kho lưu trữ, chúng có thể sắp xếp theo sao và ngôn ngữ, bạn có thể tạo, xóa, sao chép hoặc nhánh (fork)."

Trình duyệt của bạn lấy manifest đó, gọi các API thực tế, nhận dữ liệu thật về và sau đó sinh ra giao diện dựa trên tùy chọn của bạn. Kích thước phông chữ. Sắc màu. Bố cục ưa thích (bảng vs thẻ vs Kanban). Nhu cầu khả năng tiếp cận của bạn. Tất cả đều được áp dụng một cách phổ quát, trên mọi dịch vụ.

Dưới đây là ví dụ về manifest cho một dịch vụ như GitHub — dịch vụ mô tả khả năng của nó và trình duyệt xử lý phần còn lại:

service:
  name: "GitHub"
  domain: "api.github.com"
  capabilities:
    - id: "repositories"
      endpoints:
        - path: "/user/repos"
          semantic: "list"
          entity: "repository"
          sortable_fields: [name, updated_at, stargazers_count]
          actions: [create, delete, star, fork]

Trình duyệt lấy dữ liệu đó, gọi API và sinh ra một giao diện riêng biệt — sử dụng LLM để suy luận về cách tốt nhất để trình bày nó dựa trên ai bạn là và bạn đang cố gắng làm gì.

Tại sao điều này quan trọng hơn những gì bạn nghĩ

Khi tôi đang xây dựng ứng dụng cửa hàng và các nền tảng tích hợp tại Xero, một trong những nỗi đau thường xuyên là mỗi tích hợp của bên thứ ba có một số mẫu giao diện riêng. Người dùng phải học một giao diện mới cho mỗi ứng dụng họ kết nối. Nếu trình duyệt đang sinh giao diện từ một tập hợp các tùy chọn chung, vấn đề này... biến mất.

Khả năng tiếp cận là vấn đề lớn nhất. Hiện tại, khả năng tiếp cận là một tính năng được gắn thêm — và thường là kém. Khi trình duyệt sinh giao diện, khả năng tiếp cận không phải là một tính năng. Nó là mặc định. Tùy chọn của bạn — độ tương phản cao, điều hướng ưu tiên bàn phím, tối ưu hóa cho trình đọc màn hình, văn bản lớn — áp dụng ở khắp mọi nơi. Không phải vì mọi nhà phát triển đều nhớ thực hiện chúng, mà vì chúng được "nướng" vào cách giao diện được sinh ra từ đầu.

Tùy chỉnh cũng trở nên thực sự cá nhân hóa. Không phải "chọn từ ba chủ đề mà nhà phát triển tạo ra" mà là "đây là cách tôi tương tác với phần mềm, hết câu."

Tuy nhiên, sự đánh đổi là có thật

Độ phức tạp của giao diện người dùng giảm đi đáng kể, nhưng sự phức tạp không biến mất — nó di chuyển phía sau API. Và thực sự, nó có thể tăng lên.

Thiết kế API trở nên quan trọng hơn bao giờ hết. Bạn không thể chỉ vứt một số điểm cuối REST lại đó và gọi là xong. Manifest của bạn cần mang tính ngữ nghĩa — mô tả ý nghĩa của dữ liệu, không chỉ hình dạng của nó. Các hợp đồng dữ liệu giữa các dịch vụ quan trọng hơn. Việc phiên bản hóa (versioning) quan trọng hơn.

Architecture Diagram

Nhưng điều này đúng — sự đánh đổi này đẩy chúng ta đến một nơi thực sự thú vị. Nếu mọi dịch vụ cần mô tả chính mình một cách ngữ nghĩa thông qua API và manifest, thì các API đó trở thành bề mặt sản phẩm thực sự. Không phải giao diện người dùng. Các API.

Và khi API trở thành bề mặt sản phẩm, việc chia sẻ ngữ cảnh giữa các nền tảng trở thành vấn đề thú vị. Công cụ quản lý dự án của bạn biết bạn đang làm gì. Khách hàng email của bạn biết ai bạn đang trò chuyện. Trình soạn thảo code của bạn biết bạn đang xây dựng cái gì. Hiện tại, không cái nào nói chuyện với cái nào trong ý nghĩa nào vì tất cả đều bị khóa sau giao diện riêng của chúng. Trong một thế giới điều khiển bằng manifest, ngữ cảnh đó chảy qua các API — và trình duyệt của bạn có thể ghép tất cả chúng lại thành một thứ thống nhất.

Hướng đi của nó (theo quan điểm cá nhân)

Tôi nghĩ chúng ta sẽ được 3-5 năm nữa thì điều này sẽ trở nên phổ biến. Các mảnh ghép đều có sẵn — các LLM có thể suy luận về UI, các nỗ lực tiêu chuẩn hóa về việc gửi ý định UI qua API, và sự mong đợi ngày càng tăng của người dùng rằng phần mềm nên thích nghi với họ, chứ không phải ngược lại.

Các dịch vụ sẽ thắng trong thế giới này không phải là những dịch vụ có giao diện đẹp nhất được viết tay. Họ là những dịch vụ có API tốt nhất, các manifest phong phú nhất và dữ liệu hữu ích nhất. Giao diện người dùng trở thành đầu ra được sinh ra, không phải đầu vào được viết tay.

Các tổ chức sẽ đặt ra các rào cản tùy chọn — "nhân viên của chúng tôi có thể dùng chế độ tối hoặc sáng, phải có xác nhận hành động hủy diệt, các trường này luôn hiển thị" — trong khi cá nhân tùy chỉnh trong những giới hạn đó. Trình duyệt của bạn trở thành đại lý (agent) của bạn, không chỉ là trình duyệt.

Tôi đã xây dựng trình duyệt thích ứng như một bản minh họa để thử nghiệm suy nghĩ này — nó sử dụng Claude để sinh ra các giao diện từ một manifest GitHub và các tùy chọn người dùng được định nghĩa trong YAML. Nó chưa hoàn thiện, nhưng hướng đi cảm thấy đúng đắn.

Giao diện người dùng không chết. Nhưng những gì chúng ta nghĩ là "phát triển giao diện người dùng" sắp thay đổi. Công việc thú vị chuyển sang thiết kế API, các hợp đồng dữ liệu ngữ nghĩa và xây dựng các trình duyệt đủ thông minh để trở thành các đại lý người dùng thực sự.