- 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
19 bình luận
Việc các lập trình viên junior chọn React là điều khó tránh, nhưng việc các lập trình viên senior ngừng cân nhắc những lựa chọn thay thế khác mới là vấn đề.
Thực ra đúng là React hay Java đều là rác rưởi lỗi thời, dù đã có rất nhiều lựa chọn thay thế tốt hơn từ lâu mà vẫn còn thống trị quá lâu thật haha
Ngày trước đã thử nghiệm rất nhiều trong thời kỳ hỗn mang của các framework...
Còn trong công việc thì không cần phải lật đổ thứ vốn đang dùng, và dù là dự án mới đi nữa
thì cũng chẳng có mấy người đồng ý bỏ thứ đang dùng tốt để học lại từ đầu rồi chuyển sang cái mới, lại còn có cả vấn đề tuyển dụng nữa..
Mong là Solid sẽ làm nên chuyện thật tốt..... không biết phải phá vỡ thế độc quyền của React kiểu gì đây
Trong gần 10 năm qua, vô số công cụ đã tràn ra trong hệ sinh thái FE, sau bao lần thịnh suy thì giờ mới phần nào ổn định, vậy mà lại muốn thử một lần nữa kiểu hỗn loạn lớn như thế sao..
Đây là một bài viết quá thiên lệch phải không?
"Những framework đổi mới như Svelte, Solid, Qwik cung cấp mô hình hiệu năng tốt hơn, nhưng đang bị đẩy khỏi cuộc cạnh tranh dòng chính vì thiếu mức độ chấp nhận"
Nếu không có một tiêu chí nhất quán để hiểu ý nghĩa của từ "đổi mới",
thì có vẻ như ngay từ giả định ban đầu đã sai rồi.
Đọc những bài như thế này khiến tôi có cảm giác người ta không tập trung vào việc làm ra sản phẩm mà chỉ quá sa đà vào kỹ nghệ phần mềm. Đằng nào cũng na ná nhau cả thôi, điều quan trọng là phải làm sản phẩm cho tốt, vậy mà lúc nào cũng đi tìm framework mới, kiến trúc mới, rồi over-engineering, xong lại bảo cái này tốt hơn nên đổi tiếp. Tôi nghĩ không phải cái mới là tốt, mà điều quan trọng là dùng tốt bất cứ thứ gì để đưa được sản phẩm ra thị trường.
Cũng khó tránh khỏi, vì các công ty big tech trong nước tuyển dụng dựa trên React (Next.js).
Ngay cả với vue.js là framework lớn, số vị trí tuyển dụng ở các công ty big tech cũng không nhiều.
Không thể xem nhẹ hệ sinh thái... Dạo này đa số thư viện bên thứ ba hay thư viện mã nguồn mở mới ra đều hỗ trợ chính thức cho React, còn các framework khác thì chỉ được cộng đồng hỗ trợ, nên nếu muốn ghép đủ thứ lại để dùng thì cuối cùng React gần như vẫn buộc phải là lựa chọn an toàn nhất...
Khó có lĩnh vực nào thử nghiệm đa dạng như frontend...
Nhờ sự tận tâm của đội phát triển React tại Facebook mà việc phát triển ứng dụng web đã có nhiều thử thách hơn. Không phải vai phản diện đâu.. đã chấm dứt thời đại php jquery.
Ý kiến trên Hacker News
Tôi nghĩ không phải React chỉ đơn giản trở thành mặc định, mà là vì nó vốn rất hiệu quả và được thiết kế tốt nên gần như đã trở thành tiêu chuẩn, đồng thời giờ lại bị biến thành vai phản diện
Tôi cảm thấy lập luận rằng React đang làm chậm đổi mới là cực kỳ vô lý
React thực tế gần như là lựa chọn ổn định và hợp lý duy nhất giữa vô số framework kiểu "cho tôi tham gia với" và những thiết kế rối rắm
Tôi khiêm tốn mà nói là không đồng ý
Tôi chưa từng làm ứng dụng tương tác phức tạp bằng React, chỉ vài lần làm các site đơn giản mà đồng đội trước đó đã chọn React sẵn
Kết quả là với các site đơn giản, React lại rõ ràng là không scale xuống nhỏ được
Nếu chỉ là trang đăng nhập đơn giản thì có thể lưu trạng thái trực tiếp trong DOM và chỉ dùng <form> để gửi giá trị, còn hiện/ẩn mật khẩu thì thêm chút JS là xong
Nhưng nếu làm bằng React thì phải học quá nhiều thứ như JSX, hooks, vòng đời component, build cho môi trường phát triển, đóng gói production, v.v.
Các framework khác như Vue hay Alpine có thể dùng theo kiểu "tiệm tiến" và còn có thể bắt đầu ngay chỉ với CDN
React cũng tự nhận là tiệm tiến, nhưng do đặc tính của JSX nên quy trình build-compile là bắt buộc, vì vậy tài liệu chính thức không có cách bắt đầu trực tiếp bằng CDN
Không phải là ép thì không làm được, nhưng cuối cùng sẽ phải gửi cả compiler xuống client nên về thực tế là tệ nhất
Phần lớn website không phải cỡ Facebook, Spotify hay Netflix (thậm chí Netflix cũng từng tuyên bố rời xa React), nên tôi khó đồng ý với nhận định rằng React hiệu quả và được thiết kế tốt đến vậy
Khi React xuất hiện cách đây 12 năm, nó thực sự rất đột phá
Nhưng ngay sau đó đã có hàng loạt framework tương tự xuất hiện, và từ đó về sau nó chỉ dừng ở mức "tạm ổn để dùng" chứ không còn là trung tâm của đổi mới
Giờ đây nó xử lý các vấn đề của thiết kế Virtual DOM lỗi thời trong khi boilerplate ngày càng nhiều, và kém hấp dẫn hơn so với các lựa chọn hiện đại
Ý nghĩa của tiêu đề bài viết đang bị đảo ngược
Thực tế tôi thấy là "đổi mới" đang không bắt kịp công thức React (công thức thành công chính thức)
Cũng nên đặt câu hỏi là cần đổi mới đến mức nào
Thật ra nhiều khi lặp lại và cải tiến còn tốt hơn và rẻ hơn
Tôi thích bài này và góc nhìn đa nguyên của giai đoạn 2015~16
Tôi muốn nói với đội rằng "hãy làm một use case nhỏ riêng bằng Svelte", nhưng checklist đánh giá lại vận hành hoàn toàn ngược với lập luận của bài viết
Hiệu năng: với 99% ứng dụng thì không cảm nhận được khác biệt, nên cuối cùng vẫn chọn React
Trình độ đội ngũ và đường cong học tập: ai cũng chỉ biết React, không biết Qwik hay thứ tương tự. Thế là lại chọn React
Khả năng mở rộng, chi phí vận hành: không khác biệt lớn
Hệ sinh thái: React lớn hơn và ổn định hơn hẳn. Chọn React
Thêm nữa, các công cụ AI hiện nay hỗ trợ React rất tốt, và các lập trình viên cũng gần như tự nhiên học theo hướng xoay quanh React
Rốt cuộc React gần như buộc phải trở thành lựa chọn hợp lý
Tôi nghĩ web components là lối thoát khỏi tình trạng độc quyền nhóm framework này
Mọi framework trừ React đều tích cực ủng hộ web components, và câu trả lời là tận dụng một hệ sinh thái component cùng utility tương thích thay vì mỗi bên lại phải xây dựng lại hệ sinh thái React của riêng mình
Nhiều người xem web components như đối thủ cạnh tranh với framework, nhưng thật ra nó định nghĩa giao diện giữa phần triển khai component và trình duyệt, giúp khả năng tương tác và việc lắp ghép đáng tin cậy hơn
Trên lớp API mức thấp này, vẫn có thể tiếp tục đổi mới về nhiều cách tạo component khác nhau (không cần build, JSX, template, cú pháp tùy biến, compiler, v.v.) cũng như nhiều cách lắp ghép component và quản lý trạng thái khác nhau
Chỉ khi có thể khoe rằng "framework Flugle mới của chúng tôi chạy tốt với mọi framework và có hệ sinh thái công cụ tự động hóa phong phú!" thì mới có thể vượt qua thế độc quyền của React
Tôi cũng đang dùng web components thông qua wrapper để tránh boilerplate
Bằng cách này tôi có được 80% tính năng của web component với rất ít công sức
Xem GitHub liên quan: ZjsComponent, và cả liên kết thảo luận HN trước đây (thảo luận HN)
Không hoàn hảo, nhưng với tôi không có cách nào dễ và nhanh hơn để tạo component HTML mới
Nếu không có lựa chọn thay thế ở mức React Native thì chỉ web components là chưa đủ
Công nghệ trình duyệt không đủ nhanh để đạt tới mức ứng dụng native
Giá trị lớn nhất của React là có thể thống nhất phát triển GUI trên nhiều nền tảng
Tôi từng làm ứng dụng doanh nghiệp bằng lit web components
Việc mọi property đều phải là kiểu string khá bất tiện, và không thể so được với thư viện component thiên về real-time
Ở tập đoàn lớn của chúng tôi, ứng dụng nội bộ bắt buộc phải dùng thư viện React trung tâm
Không phải kiểu "React vì nó là mặc định", mà là "chỉ được dùng React"
Tôi nghĩ lối thoát là tái hiện thực thư viện trung tâm đó bằng web components để có thể dùng framework mình muốn
Tôi tò mò không biết có ai dùng web components tốt trong thư viện UI React chưa
Khi làm thư viện component theo một design system cụ thể, tôi thấy việc phụ thuộc vào thư viện headless như RAC khá thỏa mãn
Tôi hiểu web components có thể là phần bổ trợ, nhưng thực tế dùng vào đâu là hợp lý nhất thì vẫn chưa rõ
Thực ra bài này không nói về hiệu năng của React, mà nói rằng "lợi ích xã hội" của nó lớn hơn hẳn các lựa chọn thay thế nên những lựa chọn khác rất khó tồn tại
Tức là, dù React không nổi bật về mặt kỹ thuật, nó vẫn trở thành lựa chọn mặc định, và tôi đồng ý rằng hiệu ứng mạng ảnh hưởng đến quyết định nhiều hơn độ phù hợp kỹ thuật
Dù vậy, với các đội ngũ thì React vẫn tiếp tục có những lợi thế rõ ràng so với lựa chọn khác
Trên thực tế, phần lớn các đội giỏi đều biết cách xác định rằng chỉ trong những trường hợp thật sự ngoại lệ thì họ mới nên chọn phương án khác
Tôi đã tham gia quyết định tech stack ở nhiều công ty và startup, nhưng chưa từng nghe ai lấy "ưu điểm của chính framework" làm lý do chọn React
Lúc nào cũng là do sự quen thuộc, dễ tuyển người và hệ sinh thái
Người ta giả định rằng các lập trình viên web đưa ra quyết định lý tính, nhưng theo trải nghiệm của tôi thì không phải vậy
Con người rất dễ bị các thiên kiến như “social proof”, “authority” chi phối
Tôi chưa từng nghe ai nói "dùng vì React tốt"
Lúc nào cũng chỉ là "vì dễ tuyển người"
React có thế mạnh trong việc giải quyết các vấn đề phức tạp
Nhưng không phải vấn đề nào cũng phức tạp, và dùng một công cụ phức tạp làm mặc định sẽ mang vào dự án độ phức tạp không cần thiết cùng sự suy giảm tính linh hoạt
Sự bất ổn của hệ sinh thái cần phải duy trì vì tính năng trong quá khứ hoặc tương lai cũng không phải là vấn đề chỉ riêng React mới có
Về sau, tôi kỳ vọng sẽ có một làn sóng mới vượt ra ngoài mô hình web app của thế hệ hiện tại
Có lý do để lo ngại về nền văn hóa đơn nhất ở frontend (React độc chiếm), nhưng điều tôi thấy tò mò là thực ra 10 năm trước tình hình hoàn toàn ngược lại
Framework mới đổ lên HN mỗi tuần, sự hỗn loạn khi Angular 1.x lên 2.0, đến mức còn xuất hiện cả cụm từ "JavaScript fatigue", khiến phát triển frontend rất mệt mỏi
Giờ đây React rõ ràng đã trở thành tiêu chuẩn, và nhờ đó có thể yên tâm tập trung phát triển dịch vụ
Không phải tôi ca ngợi React đâu (bản thân tôi cũng không thích hooks), nhưng tôi biết ơn vì hiện tại không còn là thời như năm 2015
Điều thú vị là theo thời gian, bầu không khí đang dần thay đổi
Tôi nhớ thời kỳ ngập tràn đủ loại thư viện JavaScript boutique điên rồ
Việc React trở thành xu hướng chủ đạo có thể xem như một chiến thắng
Tôi nghĩ nên cảnh giác với việc cố ép bỏ cái quen thuộc và ổn định chỉ vì một khái niệm mơ hồ như "đổi mới"
Thực sự đồng cảm
Từ 2009 đến 2015, tôi từng làm khá tiên phong rất nhiều UX trên trình duyệt ở mức gần như ứng dụng native
Điểm mạnh là tiêu chuẩn web và việc tận dụng chúng trực tiếp tối đa, sau đó tôi chuyển hướng sang backend và quan sát sự trỗi dậy của React từ xa
React trông có vẻ kém hiệu quả, và giới hạn kiểu "mọi thứ đều phải là biểu thức" của JSX cũng khiến tôi ngột ngạt
Dù vậy, tôi đánh giá cao việc React đã mang đến một thay đổi mô hình quan trọng trong state management
Việc chuyển từ mô hình trạng thái cũ sang luồng dữ liệu immutable một chiều là quá trình khó khăn, nhưng cuối cùng rất có ý nghĩa
Dù đó là thời kỳ hỗn loạn, React thực sự đã mang lại đổi mới và thay đổi lớn trong cách tư duy về thiết kế web app
Nhưng nếu so với SolidJS hiện nay, Solid mang lại những lợi ích tương tự theo cách gọn gàng hơn, hiệu năng tốt hơn nhiều và cũng dễ quản lý hơn
JSX, server components và reactive state management cũng được cung cấp tốt hơn, và lập trình viên React cũng có thể chuyển sang khá dễ
Cách tư duy về cấu trúc ứng dụng cũng gần như giữ nguyên, nên gần như mọi lợi ích thực tế có được từ React đều có thể có ở dạng tốt hơn, nhanh hơn và kích thước bundle nhỏ hơn nhiều
Dù vậy toàn bộ thị trường vẫn đổ dồn vào React, nên cuối cùng vẫn bị ép phải tiếp tục dùng nó
SolidJS vẫn còn những chỗ đau riêng
Vấn đề lớn nhất là khó biết một cách trực quan prop đó có phải signal hay không
Hệ thống kiểu cũng không giúp được nhiều
Trong React thì nếu tham chiếu thay đổi, việc nơi nhận prop sẽ re-render là điều rõ ràng, còn trong Solid thì khá mơ hồ không biết thay đổi có được quan sát hay không
Tôi nghĩ phần lớn mọi người thấy hài lòng khi dùng cái mình quen
Có rất nhiều lập trình viên không muốn bị ép dùng React, nhưng cuối cùng vẫn phải dùng thứ mình biết rõ nhất
Thời gian thì có hạn, còn gia đình, sở thích và những phần khác của cuộc sống khiến người ta cần những lựa chọn hiệu quả
Không nhất thiết phải bị trói vào React
Công ty tôi (gần như chỉ có một mình tôi) cũng có framework do tôi phát triển suốt 10 năm qua và đã phát hành mã nguồn mở theo giấy phép MIT
Liên kết Q.js
Tôi muốn nghe ý kiến
Hooks đã giải quyết nhược điểm của class component, nhưng đồng thời cũng tạo ra độ phức tạp mới (dependency array, stale closure, lạm dụng, v.v.)
Nhưng các vấn đề này không chỉ do hooks, mà từ thời component dựa trên class trước đây cũng đã tồn tại rồi
Vấn đề dependency array trước kia cũng tương tự, bug do bỏ sót thay đổi ở props hay state là chuyện rất thường gặp
Stale closure cũng xảy ra y hệt ở tham số thứ hai của setState
Việc lạm dụng các lifecycle method (componentDidMount, componentWillMount, v.v.) cũng diễn ra thường xuyên
Tôi nghĩ những tài liệu kiểu "chỉ dùng Effect khi thật sự cần" ngay từ xưa cũng đã cần thiết
Hooks rõ ràng có góp phần cải thiện vì nó làm giảm cơ hội mắc lỗi, giúp dễ nhận ra những cơ hội mắc lỗi đó hơn, thậm chí còn đưa ra cảnh báo
Vấn đề dependency array có thể giải quyết rất dễ nếu dùng các quy tắc react-hook trong eslint
Dùng fast-check cho kiểm thử prop giúp phòng ngừa bug cực kỳ hiệu quả khi có các thay đổi nhỏ phát sinh
Cộng đồng JavaScript có lẽ nên ngừng đổi mới vài năm
Đổi mới đã quá nhiều nhưng thiếu thực chất
Giờ nên để phía trình duyệt đảm nhiệm việc phát triển component hợp lý cho web
Chỉ cần trình duyệt hỗ trợ ở cấp nền tảng cho các thứ như combobox có backend support hay date picker tiêu chuẩn thì cũng không phải liên tục bận tâm đến việc đổi mới cách quản lý trạng thái cho các UI control cơ bản như vậy nữa
Tôi cũng nghĩ vấn đề là trình duyệt không còn làm tròn vai trò ban đầu của nó nữa
Google gần như có ảnh hưởng độc quyền thông qua Chrome, nên ngoài những gì Google quan tâm và sẵn sàng bỏ nguồn lực phát triển thì tiêu chuẩn web cũng khó tiến lên
Safari và Firefox có cân bằng phần nào, nhưng để thực sự tiến hóa thành một nền tảng khác biệt thì cuối cùng vẫn cần ai đó nắm vai trò dẫn dắt và thúc đẩy
Kết cục là phía JS vì không được hỗ trợ ở cấp nền tảng nên cứ phải tiếp tục hack vá như kiểu hàn chắp chip NAND, khá đáng buồn
Tôi cảm thấy các trình duyệt gần đây cùng với CSS đã liên tục cải thiện/giải quyết những use case vốn trước đây phụ thuộc vào JS
Sẽ rất tốt nếu xu hướng này tiếp tục được mở rộng
Thậm chí có thể nghĩ tới chuyện chia trình duyệt thành 5~6 loại như mua sắm, ngân hàng, mạng xã hội, v.v.
Để mỗi dịch vụ chỉ cạnh tranh đổi mới ở backend, còn frontend thì cung cấp trải nghiệm thống nhất sẽ có lợi hơn cho người dùng
Việc mỗi công ty cứ tiếp tục tự phát triển những frontend gần như giống hệt nhau là một sự lãng phí khổng lồ
Cửa hàng sandwich nên cạnh tranh bằng cách làm sandwich ngon hơn, chứ không phải tạo ra những frontend na ná nhau chỉ để giành 8% người dùng cài app
Thực ra nhìn vào những gì các framework làm được trên một nền tảng phức tạp như vậy (HTML/CSS/JS) thì chỉ thấy kinh ngạc
'Web' phù hợp khi nó tập trung vào tài liệu/văn bản và các form đơn giản, còn giờ đây nó là nền tảng rất không phù hợp cho các ứng dụng tương tác phức tạp
Rồi sẽ đến lúc nó phải được cấu trúc lại hoàn toàn
React không thắng vì "tốt nhất", mà thắng vì trở thành "mặc định an toàn"
Ai cũng biết React, dễ tuyển người, hệ sinh thái lại lớn, nên nó mang lại cảm giác an toàn
Vì thế đổi mới ít dần đi, và những lựa chọn nhẹ hơn như Svelte hay Solid thậm chí còn không được thử
React vẫn hoạt động tốt, nhưng tôi nghĩ trên thực tế nó được dùng nhiều vì quán tính hơn là vì mức độ phù hợp thực sự
Tôi đồng cảm với quan điểm của tác giả. Tuy nhiên, quán tính tiếp tục dùng React không hẳn sai như người ta vẫn nói. Nếu các lựa chọn thay thế như Svelte mà bạn nhắc tới là iPhone 17, thì tôi xem React vào khoảng iPhone 15 hoặc 16. Xét về chi phí so với giá trị, nó vẫn còn đủ dùng và chưa khiến người ta cảm thấy nhất thiết phải đổi. Việc chúng ta chọn React trong thời kỳ frontend đầy hỗn loạn, khác với ý kiến của tác giả, không phải là một quyết định mang tính ý thức rõ ràng. Đơn giản là sau khi dùng nhiều thứ, React được chọn vì tạo cảm giác dùng ổn nhất. Trong tương lai, nếu React trở nên bất tiện và cái khác trông hữu dụng hơn, thì tôi nghĩ dù không cố ý thử thách hay làm thí nghiệm, một sự dịch chuyển tự nhiên vẫn sẽ xảy ra.
Nhìn vào ví dụ về cuộc chiến tiêu chuẩn băng video giữa VHS và Betamax, có vẻ như thứ vượt trội về mặt kỹ thuật không phải lúc nào cũng là lựa chọn được thị trường chọn.
Có phải vấn đề của frontend là đã đổi mới quá mức, vượt quá nhu cầu cần thiết không?
Tôi cũng phần nào đồng cảm.
Vì ngay cả ở backend, khi framework Spring Boot trở thành một dạng chuẩn đến mức cả framework Chính phủ điện tử cũng được xây dựng, rõ ràng có những mặt mà việc có một khuôn mẫu như vậy giúp tăng năng suất, nên tôi nghĩ có lẽ React cũng đang dần thay đổi theo hướng đó.
Vâng, tôi nghĩ ý nghĩa của React là đã định hình được thiết kế dựa trên component và cơ chế render mà khá nhiều người hiểu. Tuy vậy, React tự thân là một framework khá low-level để xây dựng web app, nên tôi vẫn mong ít nhất nó cung cấp sẵn router và form; còn với state và effect, tôi cũng từng nghĩ sẽ ra sao nếu nó mặc định hỗ trợ so sánh sâu và có thể viết logic chỉ bằng cấu trúc dữ liệu và hàm. Vì ràng buộc so sánh nông của JavaScript, rốt cuộc lại phải viết class bằng cú pháp custom hook.
Nói là mức thấp thì cũng không hẳn... Có lẽ động cơ của bài viết là ở chỗ, để triển khai form thì lẽ ra chỉ cần dùng thẻ input của HTML, nhưng lại phải biết quá nhiều thứ không thật sự cần thiết như state, JSX, component không kiểm soát/có kiểm soát, đồng thời còn phải tạo ra rất nhiều mã.
Đồng cảm.