React Rendering Strategies

Chào mừng bạn đến với Phần 1 của series Modern Front-End Development! Trước khi đi sâu vào từng rendering strategies cụ thể, hãy nhìn lại quá trình phát triển này — vì lịch sử của React rendering không chỉ là lý thuyết suông. Đó là chìa khóa để hiểu tại sao mỗi pattern ra đời và khi nào bạn nên dùng nó.

The Server-Rendered Web (Trước năm 2010)

Mình bắt đầu sự nghiệp với vai trò một .NET MVC developer. Hồi đó, mô hình rendering phổ biến nhất cho web app là server-side: server làm tất cả mọi thứ. Bạn viết business logic trong C# controllers, HTML trong Razor views, và mỗi tương tác của người dùng đều kéo theo một full round-trip lên server. Nếu bạn đã từng làm với ASP.NET MVC, PHP, hay Ruby on Rails, bạn biết chính xác mình đang nói gì.

(Đúng là AJAX đã cho phép partial updates từ thời điểm đó. Nhưng nó chỉ là add-on cho những tương tác cụ thể, chứ không phải cách cốt lõi để xây dựng app. Mental model vẫn là "server render pages, AJAX chỉ là gia vị thêm vào.")

Đây là kiểu code mình viết hằng ngày — controllers lấy data và trả về HTML đầy đủ:

Mỗi tính năng mình xây dựng đều đi theo cùng một vòng lặp:

Mô hình này chạy ổn — và thật ra nó lại khá đơn giản và dễ hiểu. Mình không phải nghĩ đến client-side state, JavaScript bundling, hay hydration. Server là single source of truth. Nhưng sau nhiều dự án, mình nhận ra những pain points như vầy:

• Full page reload cho mọi tương tác — click một button, chờ màn hình trắng flash, thấy trang mới
• Tương tác hạn chế — khi cần UI được update nhanh hơn thay vì phải chờ reload full page, mình phải dùng UpdatePanel, theo kiểu "partial postback" của ASP.NET Web Forms, nhưng nó khá nặng nề và không hề dễ xài
• Tightly coupled — HTML generation bị rối với business logic trong Razor views, component khó tái sử dụng
• Perceived performance kém — người dùng thấy loading state giữa mọi hành động, không cách nào tránh

Kỷ Nguyên jQuery — Thêm Interactivity Lên Server-Rendered Pages

Trước khi các SPA web apps bùng nổ, có một giai đoạn trung gian — và nếu bạn xây dựng web app vào cuối những năm 2000, bạn chắc chắn sẽ biết tới cách làm này: jQuery trên nền server-rendered pages.

Ý tưởng rất đơn giản: giữ server phụ trách render HTML, nhưng viết thêm jQuery code ở client side để UI trở nên interactive hơn. Cần dropdown menu? jQuery plugin. Muốn submit form mà không reload trang? $.ajax(). Cần ẩn/hiện một section? $('.panel').slideToggle(). Và thật lòng mà nói, hồi đó viết code kiểu này cảm thấy đã sướng hơn rất nhiều so với việc phải xài UpdatePanel của C#.

Đây là đoạn code trong một app ASP.NET MVC điển hình — server vẫn render trang, jQuery xử lý tương tác:

Cách làm này khá ổn để thêm tính tương tác vào từng trang riêng lẻ. Nhưng khi app ngày càng phức tạp hơn — real-time updates, form phức tạp, multi-step wizard — nhiều vấn đề bắt đầu xuất hiện:

jQuery không phải là vấn đề — nó làm tốt ở đúng thứ nó được thiết kế để làm: đơn giản hóa DOM manipulation trong thời kỳ browsers còn không nhất quán. Vấn đề là họ đang cố xây applications bằng một công cụ được thiết kế cho enhancements. Cộng đồng cần thứ gì đó khác hẳn — một cách để xây toàn bộ user interface trong browser, với real state management và một component model thực sự.

Và đó chính xác là điều các SPA frameworks thế hệ đầu tiên ra đời để giải quyết.

Làn sóng SPA đầu tiên (2010–2013)

Trước khi React tồn tại, nhiều framework đã tiên phong ý tưởng chuyển rendering từ server sang browser:

Những framework này chứng minh rằng SPA khả thi — trải nghiệm mượt mà, không reload, thứ mà server-rendered app không thể làm được. Nhưng tất cả đều có chung những vấn đề: state management phức tạp, DOM updates khó đoán, và performance xuống cấp khi app lớn dần. Two-way data binding dễ build demo nhỏ nhưng là cơn ác mộng khi debug app lớn ở scale lớn.

React xuất hiện với triết lý khác (2013)

Facebook đang gặp chính những vấn đề đó trong News Feed và Chat UI của họ. Tháng 5/2013, họ ra mắt React — không phải để cạnh tranh tính năng, mà là một hướng tiếp cận hoàn toàn khác cho cùng SPA rendering model:

Mental model rất đơn giản: state thay đổi → React re-render → chỉ phần DOM thay đổi được update. Không còn full-page reload, không còn server round-trip cho mỗi tương tác. React không phải SPA framework đầu tiên, nhưng nó giải quyết đúng vấn đề — và đó là lý do khiến React thành công cho tới tận ngày nay.

Khi SPA Thống Trị — Và Những Vấn Đề Nổi Lên

Sau khi React trỗi dậy, cả ngành công nghiệp đổ dồn vào client-side rendering. Quan điểm phổ biến lúc bấy giờ: "Server rendering đã chết. SPA là tương lai."

Nhưng khi SPA scale lên production, developer phát hiện ra những trade-off đáng kể:

Nghe quen không? Server rendering đã giải quyết phần lớn những vấn đề này từ nhiều năm trước. Cộng đồng đơn giản là đã quên mất lý do tại sao.

Vậy... Quay lại server?

Khoảng từ năm 2016, hệ sinh thái React bắt đầu khám phá cách đưa server rendering trở lại — nhưng không phải kiểu cũ "server làm mọi thứ". Ngành công nghiệp đã học được một bài học quan trọng:

Mỗi vấn đề cộng đồng gặp phải dẫn đến một approach mới — và mỗi approach mang theo trade-offs riêng. Phần còn lại của tutorial này sẽ đi qua từng bước, pattern by pattern.

Tại sao tutorial này ra đời

Đây là điều mình rút ra được sau nhiều năm làm việc với React — bắt đầu từ một developer .NET C# MVC, rồi theo dõi React và hệ sinh thái JS qua nhiều lần thay đổi paradigm:

Mục tiêu của tutorial này rất đơn giản: hiểu từng rendering strategies đủ sâu để đưa ra lựa chọn phù hợp cho project cụ thể của bạn — không phải vì một tech influencer nói vậy, không phải vì nó đang trending, mà vì bạn hiểu trade-offs và có thể tự đưa ra quyết định của mình.

Hãy bắt đầu từ nơi mọi thứ bắt đầu với React: Client-Side Rendering.