Vì sao nhiều lập trình viên không chịu "dùng nền tảng"?

04 tháng 10, 2026·7 phút đọc

Bài viết của Nolan Lawson phân tích lý do nhiều lập trình viên web vẫn thích tự xây dựng giải pháp bằng JavaScript thay vì dùng API sẵn có của trình duyệt, dù lời khuyên "hãy dùng nền tảng" nghe có vẻ hiển nhiên. Tác giả nhìn từ cả hai phía: lịch sử trình duyệt chậm chạp, thói quen dùng thư viện npm, niềm vui khi tự tay viết code, cho tới tác động của AI đối với xu hướng này.

Vì sao nhiều lập trình viên không chịu "dùng nền tảng"?

Trong nhiều năm, những người ủng hộ chuẩn web, hiệu năng và khả năng tiếp cận đã liên tục kêu gọi lập trình viên web hãy "dùng nền tảng" (use the platform). Bản thân tác giả Nolan Lawson cũng thường là một trong những người hô hào như vậy.

Lập luận rất đơn giản: tại sao phải tự xây dựng một thứ gì đó bằng JavaScript khi trình duyệt đã làm sẵn cho bạn? Dù bạn có viết tốt đến đâu, sản phẩm tự làm thường có hiệu năng kém hơn và trải nghiệm người dùng tệ hơn so với thứ mà trình duyệt cung cấp sẵn.

Nhưng lần này, tác giả quyết định đứng về phía ngược lại, phần lớn là để hiểu xem những lập trình viên hoài nghi nền tảng đang nghĩ gì. Nếu "dùng nền tảng" hiển nhiên đến thế, tại sao vẫn có rất nhiều người cần được thuyết phục?

Lý do lịch sử: trình duyệt từng chạy sau hệ sinh thái

Lý do rõ ràng nhất mang tính lịch sử. Trong một thời gian rất dài, các trình duyệt luôn chạy theo sau hệ sinh thái được xây dựng trên chính chúng. Những thư viện như jQuery đã lấp đầy các khoảng trống quan trọng trong lúc trình duyệt còn đang loay hoay triển khai API tương đương.

Thậm chí khi API đã có, bạn vẫn phải chờ những trình duyệt lỗi thời như IE6 biến mất hoàn toàn trước khi có thể dùng chúng một cách an toàn. Ngày nay phần lớn trình duyệt đã theo mô hình evergreen (tự động cập nhật), nhưng đến tận thập niên 2020, lập trình viên web vẫn phải làm việc với một nền tảng "gồ ghề" và phân mảnh. Trong môi trường đó, tự viết giải pháp là lựa chọn hợp lý.

Lý do quen thuộc: npm là phản xạ đầu tiên

Một lý do khác là thói quen. Khi bạn đã quen tìm kiếm component React trên npm, đó sẽ là nơi bạn nghĩ tới đầu tiên, bất kể vấn đề gặp phải là gì. Nếu bạn tìm "sticky positioning" trên npm, sẽ chẳng có gói nào ghi rằng "hãy dùng CSS position: sticky đi".

Đôi khi, dù chuẩn đã vững vàng, các thư viện trên npm vẫn lấp một khoảng trống hữu ích giữa trải nghiệm viết code của framework và nền tảng bên dưới. Nhiều lập trình viên React thích bám vào JSX và các idiom của React vì API DOM thuần cảm thấy "thô ráp", nhưng lại sẵn sàng dùng các thư viện cấp thấp hơn.

Một phần hiệu ứng này cũng đến từ tài liệu. Nhiều gói npm có README hoặc website chi tiết với ví dụ, hướng dẫn và ảnh chụp màn hình. Trong khi đó, tài liệu về nền tảng web từng nằm rải rác trên blog, StackOverflow và các trang như CSS Tricks — và không ít trang trong số đó lại khuyên bạn dùng một thư viện nổi tiếng nào đó.

So sánh trang Dragula với trang Drag and Drop trên MDNSo sánh trang Dragula với trang Drag and Drop trên MDN

Khi tự xây dựng là... niềm vui

Nếu chỉ là câu chuyện thư viện bên thứ ba so với API nền tảng, thì chưa đủ để giải thích sự ác cảm với "dùng nền tảng". Với một kiểu lập trình viên nhất định, tự xây dựng mọi thứ đơn giản là vui hơn.

Hãy thử tưởng tượng bạn cần làm một modal dialog. Bạn hiểu trực quan nó phải hoạt động ra sao, rồi vươn tới position: absolute và z-index để định vị. Nhưng nền phía sau vẫn cuộn, nên bạn phải tắt overflow trên body. Rồi nếu hiểu chút về khả năng tiếp cận, bạn nhận ra cần xử lý phím Esc để đóng, cần xây focus trap, cần trả focus về phần tử đã mở dialog, và còn nhiều thứ nữa.

Với nhiều người, mô tả trên nghe như ác mộng. Nhưng với không ít người khác, đó lại là niềm vui. Bạn học được rất nhiều khi bắt tay xây dựng, rồi bắt đầu thêm animation, theme, nút "close" tùy chọn... Trước khi kịp nhận ra, bạn đã có một thư viện sẵn sàng đưa lên npm. Điều đó vui hơn hẳn việc chỉ gọi một API sẵn có rồi xong việc.

Nhiều người hiện đang hô hào "dùng nền tảng" từng là tác giả của các polyfill, shim và thư viện. Tôi biết vì tôi cũng từng như vậy.

Tác giả dành nhiều năm làm công cụ cho IndexedDB, WebSQL và các API lưu trữ trình duyệt khác trong dự án PouchDB. Chính khoảng trống trong nền tảng cần được lấp đầy đã tạo động lực để ông đạt tới trình độ đủ tự tin ngồi trong các cuộc họp chuẩn của W3C và mở issue, pull request trên chính đặc tả IndexedDB.

Khi tự làm xuất phát từ sự thiếu hiểu biết

Tất nhiên, tự làm không phải lúc nào cũng tốt. Đôi khi nó đến từ sự thiếu hiểu biết thuần túy. Trên nền tảng web, một lý do khiến vô số giải pháp JavaScript ra đời để giải quyết những vấn đề lẽ ra CSS làm tốt hơn là vì nhiều lập trình viên không chịu dành thời gian hiểu sâu về CSS.

Và công bằng mà nói, CSS trước đây thực sự khó hiểu. Các kỹ thuật như clear fix, floats hay mẹo min-width: 0 đều không hề trực quan. Thay vì cố hiểu thuật toán bên trong CSS, việc tưởng tượng logic mệnh lệnh mình muốn rồi viết bằng JavaScript thường dễ hơn nhiều.

Hiện tượng này không chỉ có trên web

Tác giả cho rằng hiện tượng "né tránh nền tảng" không giới hạn ở web. Nó áp dụng cho bất kỳ lập trình viên nào làm việc trên một nền tảng mà họ chưa hiểu đầy đủ.

Ví dụ, tại nơi làm việc, tác giả dùng ClickHouse để lưu trữ dữ liệu phân tích. Một đồng nghiệp xây hệ thống nén dữ liệu JSON trước khi lưu, còn tác giả đặt dữ liệu vào một key-value store riêng rồi chỉ chèn khóa vào ClickHouse. Hóa ra cả hai đều sai: ClickHouse tự động nén dữ liệu, và vì là columnar store, việc để nó xử lý sẽ cho tỉ lệ nén tốt hơn trên các hàng.

Chỉ sau khi chịu khó đọc kỹ tài liệu ClickHouse và viết benchmark để kiểm chứng, tác giả mới nhận ra hai người đã xây dựng một thứ vừa chậm hơn vừa cồng kềnh hơn so với những gì nền tảng cung cấp sẵn.

AI sẽ làm mọi chuyện tốt lên hay tệ đi?

Tác giả thừa nhận đã rất cố gắng không nhắc tới AI trong suốt bài viết, nhưng không thể không tự hỏi lập trình bằng AI sẽ tác động thế nào tới hiện tượng này. Ông có cả góc nhìn lạc quan lẫn bi quan.

  • Lạc quan: Vì LLM có kiến thức bách khoa về nền tảng bạn đang dùng, chúng có thể chọn đúng API phù hợp để đáp ứng yêu cầu mô tả bằng tiếng Anh mơ hồ. Giải pháp này nhiều khả năng nhanh và đúng hơn code tự viết, nên agent sẽ ưu tiên nó sau khi kiểm thử và benchmark kỹ càng. Hơn nữa, hiệu ứng IKEA sẽ biến mất khi lập trình viên không còn tự tay viết code.
  • Bi quan: Vì LLM có vẻ rất thích lặp lại code — chẳng hạn bỏ qua các hàm helper đã tồn tại để tự viết lại lần thứ không biết bao nhiêu — lượng code tùy biến, phi idiom của nền tảng sẽ tăng vọt. Lập trình viên không yêu cầu agent kiểm thử đủ nhiều hay thử đủ phương án thay thế, mà chỉ commit bản nháp đầu tiên.

Trong quá trình dùng AI để viết code, tác giả đã chứng kiến cả hai hiện tượng. Ông hy vọng khi model và công cụ lập trình tiến bộ hơn, chúng ta sẽ nghiêng dần về kết quả lạc quan — nhưng chưa thể chắc chắn.

Lời kết

"Use the platform" là một câu thần chú tác giả rất yêu thích, vì nó gói gọn cảm giác khi nhìn vào một mớ code rối rắm và nghĩ rằng mọi thứ sẽ thanh lịch hơn biết bao nếu tác giả của nó hiểu rõ các tầng bên dưới hơn một chút.

Nhưng đồng thời, chính tác giả cũng từng là người viết ra những mớ code như vậy, và từng cảm nhận niềm vui khi xây dựng chúng. Vì thế, việc hiểu được lập trình viên đi ngược lại lời khuyên kia đang xuất phát từ đâu là điều đáng làm.

Và có lẽ, chừng nào còn tồn tại các nền tảng, chúng ta vẫn sẽ còn nghe thấy câu "hãy dùng nền tảng".

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗