Những điều giá như tôi biết trước khi chuyển 50 nghìn dòng mã sang React Server Components

• Bài viết về những trải nghiệm và bài học mà tác giả rút ra trong quá trình chuyển 50.000 dòng mã sang React Server Components (RSCs)
• RSCs là các component React chạy trên máy chủ thay vì phía client, mang lại hai lợi ích chính so với server-side rendering (SSR)
  • Thứ nhất, RSCs cho phép lập trình viên xác định nơi đoạn mã được thực thi, từ đó giảm kích thước bundle và giảm lượng công việc trong quá trình hydration
  • Thứ hai, server component có thể lấy dữ liệu trực tiếp bên trong component và stream tới client, giúp việc lấy dữ liệu trong React trở nên dễ dàng và hiệu quả hơn
• Tuy nhiên, việc sử dụng RSCs cũng có một số hạn chế. CSS-in-JS không hoạt động trong server component, React Context chỉ có thể được truy cập trong client component, và sự phức tạp của việc quản lý nơi mã được thực thi có thể là một thách thức
• Tác giả đề xuất cách tiếp cận 3 bước để áp dụng RSCs một cách dần dần:
  • Thêm chỉ thị "use client" ở gốc của ứng dụng
  • Di chuyển chỉ thị xuống vị trí thấp nhất có thể trong cây render
  • Áp dụng các mẫu nâng cao khi phát sinh vấn đề về hiệu năng
• Dù có thêm độ phức tạp, tác giả kết luận rằng các lợi ích của RSCs, như kích thước bundle nhỏ hơn, thực thi nhanh hơn và các mẫu tải dữ liệu nâng cao, có thể lớn hơn chi phí nếu lợi ích hiệu năng đó là điều đội ngũ cần

[GN⁺]

Ý kiến trên Hacker News

• Bài viết bàn về việc chuyển đổi 50K dòng mã sang React Server Components (RSCs).
• Một số người dùng nhắc đến tốc độ và sự đơn giản của render phía máy chủ, đồng thời chỉ ra rằng phía client sẽ nhận được HTML có thể xem ngay lập tức.
• Có ý kiến cho rằng thay vì RSCs, việc cân nhắc các framework web full-stack hoặc kiểu cổ điển như Rails, Django, Laravel có thể là giải pháp nhanh hơn và dễ mở rộng hơn.
• Một số người dùng bày tỏ lo ngại về độ phức tạp của các framework hiện đại, nhắc đến các pipeline build và biên dịch đồ sộ cần thiết ngay cả cho những tác vụ đơn giản.
• Người dùng chia sẻ trải nghiệm cá nhân với next.js và cấu hình thư mục app mới của nó, nhấn mạnh sự khó khăn trong việc hiểu công việc diễn ra ở đâu (trên server hay client), cũng như các vấn đề với những thư viện React hiện có vốn giả định xử lý phía client.
• Một số người dùng chỉ ra lỗi và các góc cạnh chưa mượt trong mô hình thư mục app mới của next.js, bao gồm các vấn đề liên quan đến dynamic routes và parallel routes.
• Một người dùng nhắc đến sự tương đồng giữa PHP và JavaScript, cho rằng JavaScript dù có nhiều chữ viết tắt hơn và đường cong học tập dốc hơn nhưng đã phát triển để cung cấp các khả năng phía máy chủ tương tự.
• Một số người dùng đặt câu hỏi về sự cần thiết phải dùng React cho những công việc có thể được giải quyết bằng các công cụ đơn giản hơn như static site generator hoặc CMS có cache.
• Có một cảm giác hoài niệm về thời kỳ server render mọi thứ còn CSS và JavaScript chỉ nâng cấp trang sau khi render xong.
• Một số người dùng bày tỏ quan điểm rằng React đang trở nên phức tạp hơn để bắt kịp các lựa chọn thay thế hiện đại, dễ hơn và nhanh hơn.
• Có tranh luận về việc dùng React để render HTML ở backend; một số người hoài nghi sự cần thiết của cách này, trong khi những người khác bảo vệ các lợi thế của nó so với phương thức phản hồi từ server truyền thống.