Thế giới tài liệu đang có một cuộc thảo luận sôi nổi về các ngôn ngữ đánh dấu. Một bài viết gần đây bảo vệ reStructuredText (rST) so với Markdown đã châm ngòi cho cuộc tranh luận gay gắt giữa các nhà phát triển về việc công cụ nào phục vụ họ tốt hơn.
Cuộc trò chuyện tập trung xung quanh một sự đánh đổi cơ bản trong các công cụ phần mềm: sức mạnh so với sự đơn giản. Trong khi bài viết gốc lập luận về khả năng mở rộng vượt trội và khả năng xử lý tài liệu của rST, phản hồi từ cộng đồng nhà phát triển cho thấy một sự chia rẽ rõ ràng về sở thích.
Khả năng đọc hiểu quan trọng hơn tính năng đối với hầu hết người dùng
Phản ứng mạnh mẽ nhất từ các nhà phát triển tập trung vào trải nghiệm người dùng. Nhiều người cho rằng lợi thế lớn nhất của Markdown không phải là khả năng kỹ thuật, mà là việc con người có thể đọc và viết dễ dàng như thế nào. Cú pháp có cảm giác tự nhiên, giống như cách mọi người đã định dạng email văn bản thuần túy và tin nhắn.
Mối quan tâm về khả năng đọc hiểu này trở nên rõ rệt hơn đối với các ngôn ngữ không phải tiếng Anh. Các nhà phát triển Hàn Quốc đã chỉ ra rằng cú pháp nội tuyến dựa trên từ của rST tạo ra những vấn đề đáng kể cho các ngôn ngữ kết hợp, nơi các tiếp tố gắn trực tiếp vào gốc từ mà không có khoảng trắng. Trong những ngôn ngữ này, việc áp dụng đánh dấu đòi hỏi các chuỗi thoát khó xử làm gián đoạn dòng chảy của việc viết.
Vấn đề hỗ trợ ngôn ngữ:
- Tiếng Hàn/Ngôn ngữ kết hợp: rST yêu cầu các chuỗi thoát như
*text*\ suffixcho việc đánh dấu nội tuyến - Markdown: Xử lý tốt hơn các ngôn ngữ không có ranh giới từ
- CommonMark: Có những trường hợp đặc biệt nhưng nhìn chung linh hoạt hơn cho văn bản không phải tiếng Anh
Khoảng cách công cụ tiết lộ ưu tiên thực tế
Thảo luận cộng đồng tiết lộ một điểm yếu quan trọng trong việc áp dụng rST: hỗ trợ công cụ. Các nhà phát triển báo cáo rằng các tiện ích mở rộng rST thường chậm hơn so với các bản phát hành chính, buộc họ phải sử dụng các phiên bản lỗi thời để tương thích. Việc thiếu các trình chỉnh sửa WYSIWYG trưởng thành và các linter tự động sửa lỗi khiến việc chỉnh sửa các tài liệu rST lớn trở nên đau đớn so với hệ sinh thái của Markdown.
Trong khi đó, Markdown đã trở nên phổ biến trên các nền tảng. Các nhà phát triển sử dụng nó hàng ngày trong Slack, GitHub, Obsidian và vô số công cụ khác. Sự quen thuộc này giảm tải nhận thức và khiến việc viết tài liệu trở nên dễ dàng thay vì gánh nặng.
Hệ sinh thái công cụ:
- Markdown: Hỗ trợ rộng rãi trình soạn thảo WYSIWYG, tích hợp trong Slack / GitHub / Obsidian
- rST: Tùy chọn trình soạn thảo hạn chế, vấn đề tương thích với các tiện ích mở rộng
- Giải pháp thay thế: AsciiDoc được đề cập như là giải pháp trung gian, Pandoc để chuyển đổi
Trường hợp sử dụng quyết định người chiến thắng
Cuộc tranh luận cuối cùng tiết lộ rằng cả hai công cụ đều phục vụ hiệu quả các nhu cầu khác nhau. Các dự án tài liệu quy mô lớn, sách và các đặc tả kỹ thuật phức tạp được hưởng lợi từ các tính năng nâng cao của rST như tham chiếu chéo, các chỉ thị tùy chỉnh và khả năng chuyển đổi tài liệu.
Đối với sách hoặc các bộ tài liệu quan trọng, tôi chắc chắn đồng ý với tác giả về điều này. Các tính năng tích hợp sẵn cho thuật ngữ và chỉ mục cũng rất tốt. Khả năng mở rộng thật tuyệt vời.
Tuy nhiên, đối với tài liệu hàng ngày, ghi chú nhanh và viết cộng tác, sự đơn giản của Markdown thắng thế. Các hệ thống tài liệu chính tại Microsoft, RethinkDB và các tổ chức lớn khác sử dụng thành công các giải pháp dựa trên Markdown với các tiện ích mở rộng tùy chỉnh khi cần thiết.
Cuộc thảo luận làm nổi bật một nguyên tắc quan trọng trong việc lựa chọn công cụ: công cụ tốt nhất không phải lúc nào cũng là công cụ mạnh nhất, mà là công cụ phù hợp nhất với quy trình làm việc và ràng buộc cụ thể của bạn. Đối với hầu hết các nhà phát triển, sự kết hợp giữa tính đơn giản, tính phổ biến và chức năng đủ tốt của Markdown vượt trội hơn khả năng kỹ thuật vượt trội của rST.
Lưu ý: reStructuredText (rST) là một ngôn ngữ đánh dấu được thiết kế cho tài liệu kỹ thuật, trong khi Markdown là một ngôn ngữ đánh dấu nhẹ ban đầu được tạo ra để viết web. Các ngôn ngữ kết hợp như tiếng Hàn tạo thành từ bằng cách kết hợp các hình vị (đơn vị có nghĩa) mà không có khoảng trắng giữa chúng.
Tham khảo: Why I prefer rST to markdown