React đang chiến thắng theo mặc định và làm chậm đổi mới frontend

• Ngày nay, việc chọn React diễn ra như một lựa chọn mặc định chứ không phải vì ưu thế kỹ thuật, và điều này đang làm chậm lại sự đổi mới của hệ sinh thái frontend
• Nhiều nhóm chọn “React mà ai cũng biết” mà không cân nhắc các ràng buộc, khiến hiệu ứng mạng lưới chi phối quyết định kiến trúc nhiều hơn là mức độ phù hợp về kỹ thuật
• Các framework đổi mới như Svelte, Solid, Qwik mang lại mô hình hiệu năng tốt hơn, nhưng bị đẩy khỏi cuộc cạnh tranh chính thống vì tỷ lệ chấp nhận còn thấp
• React có nhiều điểm xuất sắc, nhưng vấn đề là tư duy React-là-mặc-định làm tăng chi phí cơ hội và cản trở việc cân nhắc các phương án tốt hơn
• Để có một hệ sinh thái lành mạnh, cần có đa dạng và cạnh tranh, và thông điệp ở đây là hãy chọn framework dựa trên ràng buộc và độ phù hợp thay vì mặc định

---

React thắng theo mặc định và những giới hạn của nó

• React ngày nay thường không còn được chọn vì ưu thế kỹ thuật mà vì nó được chấp nhận như lựa chọn mặc định
  • Điều này củng cố thói quen các nhóm tự động dùng React mà không đánh giá các ràng buộc của dự án
• Các framework thay thế (Svelte, Solid, Qwik) thường không được đánh giá đúng mức dù có lợi thế hiệu năng hơn React trong một số kịch bản nhất định
• Vấn đề không hẳn nằm ở bản thân React, mà ở tư duy React-là-mặc-định đang tạo ra một cấu trúc cản trở đổi mới

Trần giới hạn của đổi mới

• Virtual DOM của React phù hợp vào năm 2013, nhưng ngày nay lại trở thành một lớp overhead không cần thiết
• Hooks đã giải quyết vấn đề của class component, nhưng lại đưa vào những độ phức tạp mới như dependency array và stale closure
• Server Components và React Compiler cố gắng cải thiện hiệu năng, nhưng đó là những biện pháp vòng tránh để vượt qua các giới hạn của mô hình React
• Trong khi đó, Runes của Svelte, tính phản ứng tinh vi của Solid, và Resumability của Qwik cho thấy tiềm năng cao hơn với những mô hình hoàn toàn khác

Nợ kỹ thuật

• Khi chọn React làm mặc định, sẽ phát sinh chi phí runtime không cần thiết và gánh nặng quản lý rerender
• Lập trình viên phải dành thời gian cho dependency của effect hay quản lý hydration thay vì tạo ra giá trị kinh doanh
• Trong benchmark, Solid cho thấy hiệu năng cập nhật nhanh hơn React từ 2 đến 3 lần
• Lối tư duy xoay quanh các pattern của React làm suy yếu nền tảng web cơ bản và gia tăng quán tính kiến trúc

Các framework thay thế

• Svelte: cuộc cách mạng compiler

  • Svelte xử lý phần lớn công việc ở compile time và loại bỏ virtual DOM
  • Component trở nên gần hơn với cấu trúc gốc của web, và overhead lúc chạy giảm mạnh
  • Tuy vậy, tỷ lệ áp dụng vẫn thấp vì nhận thức rằng “ít cơ hội việc làm”
  • Nhiều trường hợp như The Guardian, Wired, Shawn Wang chứng minh rằng sau khi áp dụng Svelte, kích thước bundle và thời gian tải giảm mạnh, còn năng suất phát triển thì tăng lên
  • Ví dụ, Shawn Wang đã giảm kích thước trang từ 187KB với React xuống còn 9KB với Svelte

• Solid: cách tiếp cận nguyên bản của phản ứng tinh vi

  • Solid kết hợp reactivity chính xác ở mức vi mô với cú pháp JSX
  • Thông qua signal, nó truy cập trực tiếp chỉ vào phần DOM đã thay đổi, hoàn toàn tránh được nút thắt reconciliation
  • Nó có thế mạnh về hiệu năng vượt trội và quản lý trạng thái gọn gàng
  • Dù các trường hợp áp dụng còn hạn chế, trải nghiệm của những nhóm dùng sớm cho thấy họ đạt được bước nhảy lớn cả về hiệu quả lẫn độ đơn giản của mã nguồn

• Qwik: đổi mới Resumability

  • Thay vì hydration truyền thống, Qwik nổi bật với resumability, cho phép khởi động gần như tức thì
  • Nó chỉ tải dần các chức năng cần thiết tại thời điểm hiện tại, và cả trạng thái lẫn mã đều có thể được tuần tự hóa
  • Nó cho thấy kết quả đặc biệt tốt trên các website lớn, phiên làm việc dài, và mạng chậm
  • Dù chưa nhiều nhóm thử nghiệm, những đội đã áp dụng đều báo cáo cải thiện lớn ở thời gian tải ban đầu và hiệu quả tài nguyên

• Độ phức tạp của React API và sự đơn giản của các framework thay thế

  • API của React bao gồm những khái niệm phức tạp như hook, context, reducer, memoization..., làm tăng gánh nặng nhận thức cho lập trình viên
  • Nếu dùng sai, rất dễ phát sinh bug do vấn đề dependency hoặc tạo ra gánh nặng thiết kế quá mức
  • Ví dụ, sự cố ngày 12/9/2025 của Cloudflare cũng xảy ra do cấu hình sai dependency array của useEffect
  • Ngược lại, các lựa chọn như Svelte, Solid, Qwik nhấn mạnh sự đơn giản và các nguyên lý cốt lõi của web với API nhỏ gọn và tập trung hơn nhiều
  • Cả ba framework này đều có đủ ưu thế kỹ thuật, nhưng vì văn hóa xem React là mặc định nên trong thực tế phần lớn còn chưa có cơ hội được thử nghiệm

Nhà tù của hiệu ứng mạng lưới

• Sự thống trị của React đang tạo ra những rào cản tự củng cố
• Thị trường tuyển dụng chỉ tìm “lập trình viên React”, còn trong các tổ chức thì thư viện component, thói quen phát triển cũng đã đóng cứng theo React
• Những nhà lãnh đạo muốn tránh rủi ro đương nhiên sẽ chọn React vì an toàn, và các cơ sở đào tạo cũng đi theo hướng đó
• Đây là đặc trưng của một hệ sinh thái đã đánh mất cạnh tranh lành mạnh

Phá vỡ hiệu ứng mạng lưới

• Muốn thoát khỏi điều này cần có sự lựa chọn có chủ đích
• Lãnh đạo kỹ thuật cần từ bỏ quán tính và quyết định cấu trúc theo yêu cầu thực tế, còn doanh nghiệp có thể phân bổ ngân sách pilot để thử các phương án thay thế
• Bản thân lập trình viên cũng không nên cố chấp với một hệ hình duy nhất, mà cần tiếp thu tinh thần của nhiều framework khác nhau
• Các cơ sở đào tạo nên tăng cường giảng dạy các khái niệm mang tính bất khả tri với framework, còn cộng đồng nguồn mở có thể hỗ trợ mạnh hơn cho các hệ sinh thái nhỏ
  Thay đổi sẽ không tự xảy ra; nó phải được tạo ra một cách có chủ đích.

Checklist đánh giá framework

Khi bắt đầu dự án mới, có thể dùng các tiêu chí sau để đánh giá

• Yêu cầu hiệu năng: tải ban đầu, hiệu quả cập nhật, kích thước bundle, và khả năng tối ưu ở compile time
• Năng lực đội ngũ và đường cong học tập: cân nhắc kinh nghiệm sẵn có, đồng thời lưu ý vẫn có các phương án thay thế tương thích với tư duy React như Solid
• Khả năng mở rộng và chi phí sở hữu: đánh giá chi phí dài hạn gồm bảo trì, quản lý dependency và nợ kỹ thuật
• Mức độ phù hợp của hệ sinh thái: cân bằng giữa độ trưởng thành và tính đổi mới, thử pilot ở các hạng mục không cốt lõi và kiểm tra ROI

Những phản biện thường gặp và cách đáp lại

• Độ trưởng thành của hệ sinh thái: một hệ sinh thái lâu năm không đồng nghĩa nó tất yếu phù hợp hơn với các vấn đề hiện tại. Khi phụ thuộc quá nhiều vào package bên thứ ba, gánh nặng bảo trì, lỗ hổng bảo mật và bundle phình to cũng tăng theo. Ngược lại, hệ sinh thái nhỏ có thể tập trung hơn vào nền tảng web, và với sự phát triển của công cụ AI, việc xây dựng giải pháp tùy chỉnh cũng trở nên nhanh và dễ hơn.
• Vấn đề tuyển dụng: nhu cầu rồi sẽ trở thành tiêu chí tuyển dụng. Có thể kiểm thử các lựa chọn thay thế ở những mảng không cốt lõi trước, sau đó bù đắp khoảng trống năng lực bằng học tập ngay trong thực tế.
• Thư viện component: có thể giảm lock-in và vẫn giữ năng suất bằng cách dùng design system độc lập với framework hoặc tận dụng Web Component.
• Tính ổn định: bản thân React cũng liên tục thay đổi với hooks, Server Components... Trong nhiều trường hợp, các framework thay thế thậm chí còn cung cấp API nhất quán hơn.
• Nhu cầu kiểm chứng ở quy mô lớn: jQuery từng là ví dụ thành công ở quy mô toàn cầu. Thành công trong quá khứ không đảm bảo vẫn còn hiệu lực trong tương lai.

Tác hại đối với toàn bộ hệ sinh thái và ngành

• Văn hóa đơn canh React đang làm chậm chính sự phát triển của web
• Tài năng và vốn chỉ đổ dồn vào việc giải quyết các vấn đề của React, trong khi đổi mới mang tính nền tảng của platform lại bị trì hoãn
• Các cơ sở đào tạo cũng chỉ tập trung vào khả năng có việc ngay lập tức trong chương trình giảng dạy, khiến việc học các kỹ năng thiếu tính chuyển đổi ngày càng nhiều
• Sự phát triển của chính platform web bị chặn lại bởi câu trả lời “chỉ cần React là đủ”, và sự thiếu đa dạng của hệ sinh thái cuối cùng sẽ trở thành tổn thất dài hạn cho tất cả

Hệ sinh thái đáng mong muốn mà chúng ta có thể cùng tạo ra

• Đa dạng là điều kiện thiết yếu của một hệ sinh thái lành mạnh
• Khi nhiều hệ hình cạnh tranh và trao đổi với nhau, đổi mới mới có thể ra đời
• Lập trình viên trưởng thành nhờ học nhiều cách tư duy khác nhau, và chính nền tảng web cũng phát triển nhờ tinh thần thử thách đa dạng đó

• Dồn toàn lực vào một framework sẽ tạo ra một điểm lỗi đơn. Khi chạm tới giới hạn, tăng trưởng cũng dừng lại và những cơ hội tốt hơn cũng biến mất
• Mỗi dự án cần được lựa chọn dựa trên các ràng buộc kỹ thuật và mức độ phù hợp, thay vì chỉ dựa vào mặc định React
• Chỉ có đa dạng mới bảo đảm được đổi mới thực sự

• Đã đến lúc ngừng gieo cùng một “hạt giống (React)” như tất cả mọi người, và cùng tham gia xây dựng một hệ sinh thái web bền vững và sáng tạo hơn thông qua những thử nghiệm đa dạng với framework
• Quyết định nằm ở chúng ta