Vì sao quá nhiều công cụ lại dùng file cấu hình JSON?

Có bao giờ bạn mở một file config.json và tự hỏi: “Tại sao lại có cái key này? Tại sao giá trị lại là 10 thay vì 20?” — rồi vò đầu bứt tai vì không thể viết một dòng chú thích nào vào đó? Một lập trình viên trên diễn đàn công nghệ vừa đặt ra câu hỏi đầy bức xúc, và câu trả lời nằm ở sự đánh đổi giữa sự đơn giản của máy móc và nhu cầu ghi lại suy nghĩ của con người.

JSON phổ biến vì nó dễ phân tích, dễ tạo bởi hầu hết ngôn ngữ lập trình và không cần những công cụ phức tạp. Nhưng chính đặc tính “khiêm tốn” đó lại là con dao hai lưỡi, khiến cho những ai muốn giải thích ý định thiết kế của mình phải đau đầu.

Sức hút của JSON: Sự đơn giản đến mức khó cưỡng

Trước hết, cần phải công bằng với JSON. Nó không sinh ra để dành cho con người ghi chú, mà để cho máy móc đọc và truyền dữ liệu một cách hiệu quả. Hầu như mọi ngôn ngữ từ JavaScript, Python đến Go hay Rust đều có thư viện chuẩn để parse JSON chỉ trong vài dòng code.

Một file JSON rất dễ dàng để sinh ra từ một API hoặc từ một chương trình khác. Bạn không cần phải lo về định dạng phức tạp, thụt lề kiểu YAML hay các quy tắc nghiêm ngặt của TOML. Chỉ cần tuân thủ cú pháp cơ bản là mọi thứ hoạt động ngay lập tức. Sự tương thích phổ quát này khiến JSON trở thành lựa chọn mặc định cho các công cụ dòng lệnh, trình quản lý gói và hệ thống build.

JSON thường được chọn không phải vì nó tốt nhất, mà vì nó “đủ tốt” và không gây bất ngờ về mặt kỹ thuật.

Nghịch lý: Con người muốn giải thích, máy móc chỉ muốn đối chiếu

Câu hỏi chua chát mà tác giả bài viết đặt ra về việc “vì sao tech people ghét việc viết lời chú thích đến vậy?” lại có một phần đáp án nằm ở chính đặc tính của JSON. Không hỗ trợ comment là một lựa chọn có chủ đích của Douglas Crockford — người tạo ra JSON — để tránh những rắc rối nếu các chuẩn khác nhau định nghĩa cú pháp comment không thống nhất. Điều này giúp ngăn chặn disaster khi cộng đồng phát triển theo những hướng riêng.

Vì không được phép chú thích, các nhà phát triển thường phải tìm cách “ngoài luồng” như thêm các key giả kiểu "_comment": "lý do chọn màu này", hoặc tách ra một file README riêng. Cả hai đều không lý tưởng. Khi bạn đứng trước một cấu hình mặc định của công cụ như ESLint hay Webpack, bạn hiểu một nửa, đoán già đoán non nửa còn lại.

Nhu cầu “ghi chú” vẫn luôn tồn tại và thị trường phản ứng theo

Có lẽ vì đây là một sự thiếu sót quá rõ ràng, cộng đồng nguồn mở đã liên tục đề xuất cách giải quyết.

• JSON5 nới lỏng giới hạn, hỗ trợ comment kiểu JavaScript và khóa không cần dấu ngoặc kép.
• JSONC — được dùng trong Visual Studio Code — bổ sung comment nhưng vẫn giữ phần lớn cú pháp gốc.
• YAML và TOML được thiết kế riêng cho cấu hình, hỗ trợ comment tốt nhưng có đặc tính riêng, thậm chí đôi khi gây khó chịu vì xử lý khoảng trắng hoặc quy tắc phức tạp.

Thực tế cho thấy, việc một công cụ dùng JSON hay YAML không chỉ là vấn đề sở thích, mà là vấn đề hệ sinh thái và tài liệu. Các công cụ lớn như npm, cargo hay pip đều chọn một định dạng riêng, biến nó thành chuẩn bất thành văn trong cộng đồng của mình.

Kết luận: Một cuộc tranh luận về trải nghiệm nhà phát triển

Câu hỏi về file cấu hình JSON thực chất là một phần của cuộc tranh cãi lớn hơn về Developer Experience (DX) — mức độ dễ chịu khi làm việc với một công cụ. Nếu công cụ của bạn hướng đến người dùng cuối là lập trình viên, họ có quyền đòi hỏi sự rõ ràng về lý do tồn tại của một lựa chọn cấu hình. Họ muốn ghi chú để 6 tháng sau quay lại vẫn hiểu điều mình đã nghĩ.

Vậy nên, thay vì than vãn về JSON, các tác giả công cụ hiện đại có thể học cách đặt mình vào vị trí của người dùng. Nếu không thể nhét comment vào file JSON, hãy tự hỏi liệu bạn có nên thay đổi định dạng, hoặc ít nhất là đầu tư vào một hệ thống tài liệu trực tuyến tốt đến mức người dùng không bao giờ cần tự hỏi những câu “tại sao” như thế.

Công cụ tốt không chỉ hoạt động tốt theo cách của máy tính, mà còn phải khiến con người muốn giải thích và chia sẻ cách sử dụng nó cho nhau.

Với một cộng đồng lập trình viên Việt Nam đang phát triển mạnh mẽ, việc hiểu rõ đằng sau những quyết định tưởng chừng vô lý này sẽ giúp chúng ta lựa chọn công cụ phù hợp hơn cho dự án của mình, tránh việc đổ lỗi một cách chủ quan cho một định dạng mà nguyên nhân gốc rễ nằm ở quá trình thiết kế chứ không phải ở một cá nhân nào.