Nếu không phải React, thì nên dùng gì?

(infrequently.org)

11 điểm bởi GN⁺ 2024-12-01 | 12 bình luận | Chia sẻ qua WhatsApp

> "Frameworkism (chủ nghĩa framework) không còn hiệu quả nữa. Đáp án không phải là một công cụ khác, mà là dũng khí để làm kỹ thuật đúng nghĩa"

Trong 10 năm qua, đã trải nghiệm hơn 100 dự án thông qua nhiều sản phẩm và tech stack khác nhau cho web desktop và mobile
Phần lớn thời gian được dùng để xử lý các vấn đề về hiệu năng và khả năng truy cập do các framework frontend như React gây ra, thay vì cải thiện Web API
Dù React đã là công nghệ legacy, nó vẫn tiếp tục được áp dụng trong các dự án mới
Có người vẫn cho rằng React là "hiện đại", nhưng thực chất đó chỉ là lặp lại những cách làm của quá khứ

Quy tắc giảm thiểu độ phức tạp phía client

Mã phía server nằm trong phạm vi kiểm soát của lập trình viên, nên có thể quản lý hiệu năng và độ sẵn sàng một cách hiệu quả
Mã phía client chạy trong nhiều môi trường mà lập trình viên không thể kiểm soát, nên rất khó đảm bảo tính ổn định và hiệu năng
Chiến lược tốt nhất là giảm lượng mã gửi xuống client
- Ưu tiên HTML và CSS để giảm thiểu sự phụ thuộc vào JavaScript
- React và các framework tương tự gây ra tình trạng trùng lặp mã không cần thiết và suy giảm hiệu năng

Vậy lựa chọn thay thế là gì?

Cuộc thảo luận được tách thành hai câu hỏi

Câu hỏi hẹp: "Nếu cần client rendering, công nghệ nào có thể thay thế React?"
- Đáng cân nhắc các framework hiện đại như Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil
- Tuy vậy, ngay cả khi dùng các framework này cũng phải kiểm soát nghiêm ngặt payload phía client và độ phức tạp. JavaScript tốn kém ít nhất gấp 3 lần so với HTML/CSS
Câu hỏi rộng: "Nếu muốn rà soát lại toàn diện một tech stack đang phụ thuộc vào React thì phải làm thế nào?"
- Không chỉ đơn giản là thay bằng công cụ mới, mà cần hiểu mục tiêu và giới hạn của kiến trúc hiện tại rồi thiết kế lại

Cách tiếp cận cho câu hỏi hẹp

Tạo nhiều PoC (Proof of Concept) quy mô nhỏ để đánh giá khả năng mở rộng hiệu năng và các giới hạn
Những thử nghiệm khách quan như vậy mang lại cho đội ngũ kinh nghiệm kỹ thuật có ý nghĩa

Tình huống chung của các đội ngũ đặt ra câu hỏi rộng

Họ thường cảm thấy bối rối khi bàn về việc thay thế React
- Phần lớn quyết định trước đây được đưa ra theo cách chỉ đơn thuần đi theo kiến trúc có sẵn
- Thiếu hiểu biết rõ ràng về trải nghiệm người dùng và thiếu ra quyết định dựa trên dữ liệu

Sự khác biệt giữa chủ nghĩa framework và cách tiếp cận lấy người dùng làm trung tâm

Chủ nghĩa framework: niềm tin rằng chỉ cần bổ sung thêm tính năng vào framework là mọi vấn đề sẽ được giải quyết
- Trên thực tế, nhiều khi nó không giải quyết được vấn đề của người dùng
- Bỏ qua các mẫu không điển hình hoặc bằng chứng dựa trên dữ liệu
Chủ nghĩa hiện thực: đo lường trải nghiệm người dùng và đưa ra quyết định dựa trên dữ liệu thực tế
- Hiểu nhu cầu và các ràng buộc của người dùng, rồi thiết kế tech stack dựa trên đó
- Điểm khởi đầu luôn là nhu cầu của người dùng

Cách đưa chủ nghĩa hiện thực vào thực tế

Tận dụng dữ liệu RUM: dùng các chỉ số hiệu năng lấy người dùng làm trung tâm như Core Web Vitals
Kiểm thử hiệu năng: dùng công cụ như WebPageTest (WPT) để đo các hành trình người dùng quan trọng (critical user journeys)
Liên kết mục tiêu kinh doanh với trải nghiệm người dùng: dùng dữ liệu để đánh giá hướng cải thiện và hiệu quả đầu tư

Tầm quan trọng của cách tiếp cận dựa trên dữ liệu

Thay vì áp dụng framework dựa trên niềm tin, hãy xác minh hiệu quả của nó bằng dữ liệu
So sánh chi phí và hiệu quả thực tế của việc áp dụng công nghệ theo trào lưu
Khuyến khích lựa chọn công nghệ tập trung vào tối ưu hóa trải nghiệm người dùng thông qua các chỉ số có thể đo lường

Không có gì có giá trị thực sự bị mất đi

Hiệu quả của các chính sách ngăn React lan rộng

Việc cấm React và các cách tiếp cận lấy framework làm trung tâm khác góp phần giảm chi phí và điều chỉnh lại đội ngũ theo hướng lấy người dùng làm trung tâm
Tuy nhiên, nếu không loại bỏ hoàn toàn chủ nghĩa framework thì rất khó đạt được cải thiện hiệu quả ở cấp độ nền tảng
Dù tránh được một sai lầm, nếu vẫn đầu tư vào sai lầm khác cùng loại thì tác dụng cũng bị giới hạn

Những giải pháp phổ biến cho bài toán rộng hơn

Lấy người dùng làm trung tâm

Người ra quyết định phải chịu trách nhiệm trực tiếp cho kết quả từ các lựa chọn kỹ thuật của mình
Không viện cớ: nếu hệ thống không hoạt động tốt cho người dùng, đặc biệt là những người dùng bị thiệt thòi, thì phải cung cấp phiên bản thay thế
Chỉ có những vấn đề cần giải quyết; loại bỏ việc "thần thánh hóa" cách làm cũ một cách vô điều kiện

Cách tiếp cận dựa trên bằng chứng

Cần có cam kết chung giữa lãnh đạo và kỹ thuật đối với chủ nghĩa hiện thực
Trong quá trình ra quyết định, bằng chứng tốt hơn phải luôn chiếm ưu thế

Cơ chế bảo vệ

Cần có chính sách để ngăn các tuyên bố viển vông của chủ nghĩa framework
Ví dụ: yêu cầu kỹ thuật về progressive enhancement của UK Government Digital Service
- Có thể điều chỉnh chính sách tùy theo bối cảnh tổ chức, ví dụ tạo luồng escalation cho các trường hợp ngoại lệ
- Nhưng điều quan trọng là đặt ra tiêu chí rõ ràng. Chính sách dựa trên bằng chứng có sức ảnh hưởng rất mạnh

Đánh giá so sánh công nghệ

Đừng triển khai hệ thống mới nếu chưa có các hành trình người dùng quan trọng (critical user journeys) được định nghĩa rõ ràng
Các hành trình người dùng quan trọng đại diện cho những tác vụ người dùng thực hiện thường xuyên nhất trong hệ thống
Dựa trên đó, tiến hành đánh giá đối chiếu (bakeoffs) để kiểm thử hiệu quả của từng công nghệ dưới các điều kiện ràng buộc
- Product manager không nên chỉ đề xuất thử nghiệm một cách mơ hồ, mà phải xác định giả thuyết sản phẩm rõ ràng và tiêu chí thành công
- Đây có thể là một quá trình khó chịu, nhưng là vai trò cốt lõi của product manager
- Việc các PM cho rằng điều này không phù hợp với công việc của họ rồi nghỉ việc là điều có thể chấp nhận

Nghiên cứu tình huống

Hiểu sự khác biệt giữa chủ nghĩa hiện thực và chủ nghĩa framework qua ví dụ

Tiêu chí lựa chọn công nghệ
- Việc chọn công nghệ được đánh giá theo số lần cập nhật dữ liệu chính và độ dài phiên sử dụng
- Một số loại ứng dụng có đặc trưng là phiên dài và cập nhật dữ liệu thường xuyên
  - Trong trường hợp này, mô hình dữ liệu cục bộ có thể phù hợp
  - Nhưng đây là trường hợp ngoại lệ hiếm gặp
Với các phiên ngắn
- Những website có thời lượng phiên trung bình ngắn cần giảm tối đa lượng JavaScript tải ban đầu
- Phần lớn website không cần kiến trúc SPA
Khi nào SPA là cần thiết
- Chỉ nên cân nhắc kiến trúc SPA khi đáp ứng các điều kiện cụ thể
  - Phiên dài và cần nhiều lần cập nhật trên cùng một dữ liệu
- Các website không đáp ứng điều kiện này thì không nên áp dụng SPA
Câu hỏi cốt lõi
- Vấn đề không nằm ở việc chọn giữa các JavaScript framework
- Trong đa số trường hợp, điều quan trọng là xác định liệu bản thân việc dùng công cụ định hướng SPA có phù hợp hay không
- Với hầu hết website, câu trả lời rõ ràng là "không"

Website cung cấp thông tin (Informational)

Cấu trúc tối ưu: dùng HTML ngữ nghĩa và progressive enhancement khi cần
Các static site generator như Hugo, Astro, 11ty, Jekyll là lựa chọn phù hợp
Với nội dung cập nhật thường xuyên, dùng công cụ CMS như WordPress
Blog, website marketing, trang chủ công ty, website thông tin công cộng cần giảm tối đa payload JavaScript phía client
Không nên dùng các framework được thiết kế cho kiến trúc SPA
Vì sao markup ngữ nghĩa và progressive enhancement là phù hợp?
- Đặc trưng là phiên ngắn và mô hình dữ liệu do server sở hữu
  - Nguồn dữ liệu hiển thị trên trang luôn được quản lý từ server
  - Không cần abstraction cho mô hình dữ liệu phía client hay định nghĩa component
- Cấu hình CMS:
  - Trình biên tập tương tác cao, lưu lượng thấp cho tác giả
  - UI trình xem tương tác thấp, lưu lượng cao cho độc giả

Thương mại điện tử (E-Commerce)

Kiến trúc khuyến nghị: HTML ngữ nghĩa do server sinh ra và progressive enhancement
Khoảng cách hiệu năng giữa Amazon và các đối thủ dùng React là rất rõ ràng
- Hơn 70% lưu lượng của Walmart đến từ mobile, và Next.js dựa trên SPA gây ảnh hưởng tiêu cực đến kinh doanh
Vì sao progressive enhancement là phù hợp
- Cấu trúc phổ biến của e-commerce:
  - Trang đích có sản phẩm hiện có và chức năng tìm kiếm
  - Trang kết quả tìm kiếm hỗ trợ lọc và so sánh
  - Trang chi tiết sản phẩm gồm media, review và các lựa chọn thay thế được gợi ý
  - Màn hình quản lý giỏ hàng, thanh toán và quản lý tài khoản
- Trạng thái do server sở hữu:
  - Giữ nội dung luôn mới, ví dụ giá
  - Giảm độ trễ bằng tối ưu hóa trang nhẹ
  - Áp dụng caching quyết liệt, tối ưu ảnh và chiến lược giảm kích thước trang

Website tiêu thụ media (Media)

Cấu trúc cơ bản: thiết kế dựa trên progressive enhancement
- Khi cần, có thể thêm độ phức tạp theo thay đổi của sản phẩm
Vì sao progressive enhancement và kiến trúc Islands là phù hợp
- Các yếu tố tương tác như luồng bình luận có thể được cấu thành như mô hình dữ liệu độc lập
- Có thể triển khai trong trang tĩnh bằng Web Components
Khi nào SPA là phù hợp
- Tính liên tục của phát media:
  - Cần duy trì mini player khi điều hướng giữa các trang
  - Dùng công nghệ SPA và quản lý chặt chẽ giới hạn kích thước JS phía client
- Hỗ trợ phát offline:
  - Cần logic quản lý local media cache
  - Có thể cân nhắc các hệ thống đồng bộ dữ liệu như Zero, Y.js

Mạng xã hội (Social)

Mô hình hybrid: ít tương tác dựa trên mô hình dữ liệu do server sở hữu + cập nhật media không thường xuyên
Vì sao progressive enhancement là phù hợp
- Tương tác phổ biến:
  - Nhấn "thích", cập nhật không thường xuyên, v.v.
  - Cách làm hybrid dùng Hotwire hoặc HTMX là phù hợp
Khi nào SPA là phù hợp
- Các đảo tương tác sâu:
  - Tận dụng client caching cho những việc như lưu bài viết nháp
- Hỗ trợ offline:
  - Vẫn ưu tiên gửi HTML trước, nhưng triển khai logic đồng bộ và offline qua Service Worker

Ứng dụng năng suất (Productivity)

Các ứng dụng năng suất xoay quanh tài liệu có yêu cầu phức tạp như chỉnh sửa cộng tác, hỗ trợ offline, chế độ xem nhẹ
Mô hình dữ liệu cục bộ và kiến trúc dựa trên SPA có thể phù hợp
Vì sao SPA là phù hợp
- Cập nhật dữ liệu thường xuyên:
  - Với các thao tác như gõ phím, kéo thả chuột, logic phía client có ưu thế
- Cần quản lý các ràng buộc hiệu năng:
  - Kiểm soát kích thước bundle ban đầu
  - Áp dụng chiến lược tải package trì hoãn

Các lớp ứng dụng khác (Other Application Classes)

Yêu cầu đặc thù:
- 3D CAD, trình soạn thảo lập trình, game streaming, game trên web, chỉnh sửa media, hệ thống sản xuất âm nhạc, v.v.
- Mỗi lớp ứng dụng cần được đánh giá cẩn trọng theo cách tương tự như ứng dụng năng suất
Điều kiện thành công:
- Định nghĩa các hành trình người dùng quan trọng
- Phân tích độ sâu phiên trung bình
- Thiết lập các chỉ số đảm bảo hiệu năng
- Kiểm soát các script và tài nguyên cốt lõi

Một lời về phần mềm enterprise

"Ứng dụng kinh doanh doanh nghiệp" thường gây ra các vấn đề hiệu năng tệ nhất
- Dashboard, hệ thống workflow, ứng dụng chat doanh nghiệp là những ví dụ tiêu biểu
Hiệu năng là văn hóa:
- Thất bại trong việc định nghĩa và đo lường thời gian tải ban đầu cũng như hiệu năng sau tương tác
- Văn hóa lấy developer làm trung tâm và phớt lờ người dùng là chất độc

"Nhưng mà…"

Các nhà quản lý bị ràng buộc với một framework cụ thể như React thường đưa ra nhiều lập luận để hợp lý hóa lựa chọn đó
Nhưng các cuộc tranh luận ấy không đặt trải nghiệm người dùng vào trung tâm, và sự thiếu sót này lặp đi lặp lại.

"...chúng ta phải đi thật nhanh"

Câu hỏi: "Theo bạn điều đó sẽ kéo dài được bao lâu?"
Các dự án dựa trên NPM được phát triển quá nhanh sẽ dẫn đến vấn đề accessibility, hiệu năng kém và độ phức tạp gia tăng, khiến tốc độ cuối cùng giảm xuống.
Chi phí remediation: mất hàng tháng để giải quyết các vấn đề JavaScript, và tốc độ phát hành tính năng còn giảm mạnh hơn.
Để đạt Product-Market Fit, cần ưu tiên accessibility và chất lượng.
Lựa chọn dùng React để "đi thật nhanh" về lâu dài tốn kém hơn và cản trở tăng trưởng.

"...Facebook đang dùng tốt mà"

Phần lớn doanh nghiệp không gặp những vấn đề như Facebook.
Bản thân Facebook cũng gặp vấn đề hiệu năng do dùng React, nhưng che lấp được nhờ vị thế độc quyền.
Các doanh nghiệp thông thường không nên mù quáng bắt chước trường hợp của Facebook.

"...đội của chúng tôi đã biết React rồi"

Developer React vẫn là web developer. Làm việc với CSS, HTML, JavaScript và DOM là điều bắt buộc.
React là lớp đơn giản nhất có thể thay thế trong tech stack.
Không có rào cản lớn để học các framework nhỏ hơn và nhanh hơn như Preact, Svelte, Lit, FAST

"...chúng tôi cần tuyển người dễ hơn"

Ngành IT hiện nay là cơ hội rất tốt để tuyển được developer giỏi.
Kiến thức về React không thể là tiêu chí tuyển dụng.
Đa số developer biết React cũng có thể học web standards một cách dễ dàng.
Ngược lại, hệ thống đơn giản hơn mới mang lại ROI cao hơn.

"...ai cũng dùng điện thoại nhanh mà"

Trong 10 năm qua, khi mobile usage tăng mạnh, giả định rằng tài nguyên phía client là rẻ đã là một giả định sai.
Người dùng điện thoại hiệu năng thấp cũng rất có thể là khách hàng chính của sản phẩm.
Chọn React đồng nghĩa với việc giả định mọi người dùng đều có thiết bị đắt tiền, điều này rất rủi ro

"...React là chuẩn ngành"

React không phải một tiêu chuẩn nhất quán.
- Ngay trong chính React, cách làm cũng khác nhau theo từng dự án: class component hay function component, có dùng TypeScript hay không, chọn công cụ state management nào, v.v.
React stack luôn biến động, và tuyên bố rằng nó là "chuẩn" chỉ là một hư cấu dễ chịu.

"...ecosystem…"

Rất hiếm thư viện chỉ tương thích riêng với React; phần lớn công cụ cũng có thể dùng với Preact và các lựa chọn khác.
Mọi package NPM đều trở thành technical debt cho tương lai.
Các dependency không cần thiết như CSS-in-JS chỉ làm chi phí tăng thêm.

"...Next.js cũng đủ nhanh mà"

Next.js về cơ bản mang theo luôn các vấn đề hiệu năng của React.
Các công cụ ưu tiên HTML như Astro, 11ty cho hiệu năng tốt hơn Next.js.
Ngoài ra còn có vấn đề bị lock-in vào API của các startup được VC hậu thuẫn.

"...React Native!"

React Native làm ứng dụng mobile chậm đi và đòi hỏi chi phí bảo trì cao.
PWA và Capacitor/Cordova là lựa chọn tốt hơn.
Ngay cả Facebook cũng đang rời xa React Native.

12 bình luận

nemorize 2024-12-08

Doanh nghiệp thông thường không nên mù quáng làm theo trường hợp của Facebook.

Ngay cả Facebook cũng đang rời xa React Native.

Người dùng điện thoại hiệu năng thấp cũng rất có thể là nhóm khách hàng chính của sản phẩm.

Triển khai logic đồng bộ hóa và ngoại tuyến thông qua Service Worker

React Native khiến ứng dụng di động chậm hơn và đòi hỏi nhiều chi phí bảo trì.

Sử dụng Capacitor/Cordova là lựa chọn tốt hơn.

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

wildmental 2024-12-03

Bài viết quá dài nên trọng tâm vấn đề bị loãng.

Có vẻ tác giả cho rằng ý kiến ủng hộ dùng React đương nhiên xuất phát từ chủ nghĩa sùng bái framework.

Sau khi nói rằng cần thoát khỏi chủ nghĩa framework và tiếp cận theo từng trường hợp, tác giả lại đang cố tạo ra một công thức cho mọi loại nhu cầu kỹ thuật.

Điểm nổi bật là nỗ lực chiếm lĩnh cuộc đối thoại một cách quá mức khi muốn trả lời mọi phản biện có thể được nêu ra. Những phản biện ngược lại đối với ý kiến phản đối cũng quá phiến diện.

Tức là, để thực hiện một cuộc thảo luận bàn về vấn đề chung vượt ra ngoài một trường hợp cụ thể, có vẻ tác giả còn thiếu rất nhiều cả về thái độ lẫn kỹ năng tranh luận.

Kết quả là, dù tôi vốn không thích dùng React, chỉ vì thái độ một chiều của tác giả mà tôi lại muốn lắng nghe thêm suy nghĩ của những người ủng hộ việc dùng React.

savvykang 2024-12-03

Cá nhân tôi hiện vẫn nghĩ React là lựa chọn tốt nhất, nên xin chia sẻ ý kiến như vậy.

Tôi bắt đầu học phát triển web từ thời php và jquery, rồi ở công ty hiện tại đã trải nghiệm AngularJS, Angular, React kiểu class và React kiểu hook. Từ góc nhìn của người đã dùng qua, việc chuyển đổi tech stack sau khi đã có đủ những bài học thử-sai của người đi trước và hệ sinh thái thư viện hoàn thiện sẽ bớt đau đầu hơn. Nếu nói theo semantic versioning thì tức là dùng bản major thấp hơn một bậc so với bản mới nhất. Vì yêu cầu và các tính năng cấp cao không thay đổi nên không thành vấn đề, nhưng nếu thiếu tài liệu tham khảo về công nghệ nền tảng thì năng suất thực sự không lên được. Ngoài ra, do đặc thù dự án ở công ty tôi khác với dịch vụ SaaS, chu kỳ sản phẩm dài và có những giai đoạn chỉ làm maintenance, nên lại càng khó áp dụng công nghệ mới nhất.

Có lẽ đến thời điểm React chuyển hướng sang Next.js, chấm dứt hỗ trợ SPA và ép buộc thay đổi kiến trúc, thì sẽ cần cân nhắc lại một lần nữa việc chuyển đổi công nghệ. Nếu Vue được phổ biến hơn một chút thì đương nhiên nó sẽ nằm trong nhóm ứng viên. Không có lý do gì để không dùng cả.