Bạn không cần Next.js - Vì sao chúng tôi chuyển từ Next sang React

• Kết quả đạt được khi di chuyển dashboard ComfyDeploy từ Next.js sang React:
  • Thời gian build giảm từ 3 phút xuống 18 giây
  • Hot reload được cải thiện xuống dưới 200ms
  • Các thành viên trong nhóm hài lòng hơn rất nhiều
• Ban đầu chúng tôi bắt đầu với một ứng dụng full-stack dùng Next.js, và nhờ Drizzle cùng Server Actions, hệ thống hoạt động tốt với độ an toàn kiểu dữ liệu và mã nguồn gọn gàng, nhưng đã phát sinh các vấn đề sau:
  • Một người dùng cụ thể khiến chi phí API trên Vercel tăng cao tới $2,000
  • Độ phức tạp trong việc kiểm thử API tăng lên: Server Actions và API routes bị trộn lẫn
  • Thời gian build chậm và môi trường phát triển cục bộ kém hiệu quả
  • Chỉ một thay đổi nhỏ cũng khiến toàn bộ SSR phải reload lại
• Vấn đề
  • Độ phức tạp của Next.js tăng lên: cách tiếp cận tất cả trong một (full-stack) của Next.js gây ra độ phức tạp trong phát triển khi ứng dụng lớn dần
  • Dashboard của chúng tôi chủ yếu dựa trên React và không cần các tính năng phía server của Next.js
• Chuyển từ Next.js sang React
  • Chuyển từ Next.js sang React bằng TanStack Router và Rspack
    • Khởi động dev server: dưới 2 giây
    • Thời gian build trên Vercel: 18 giây
  • Cải thiện cấu hình API, loại bỏ các dependency không cần thiết, đơn giản hóa mã nguồn và tăng năng suất
• So sánh hiệu năng
  • Next.js 15 (dùng chế độ Turbo)
    • Build trang đầu tiên: 10.4 giây
  • React + TanStack Router + Rspack
    • Tính toán route: dưới 200ms
    • Build bundle ban đầu: 1.67 giây
• Đánh đổi
  • Những gì mất đi
    • Co-location của mã frontend và backend: khi tách frontend và backend ra, ranh giới trở nên rõ ràng hơn
    • Tính năng caching của Next.js: vì có nhiều dữ liệu cập nhật theo thời gian thực nên được thay bằng caching tùy chỉnh
    • Prerendering và tải ban đầu: thay vì Static Generation, chúng tôi triển khai UX tốt hơn - không còn hiển thị nút bị vô hiệu hóa
    • Server Components và Actions: mất đi sự "ma thuật" của server components, nhưng đổi lại API được thiết kế có chủ đích hơn
  • Những gì đạt được
    • Tăng cường thiết kế hợp đồng API
    • Chỉ triển khai caching ở những nơi cần thiết
    • Thiết kế cẩn thận luồng dữ liệu và quản lý trạng thái
• Kết luận
  • Next.js phù hợp cho các tác vụ như landing page và SEO, nhưng với phần lớn sản phẩm thì nó tạo ra độ phức tạp quá mức
  • Vẫn sử dụng Next.js cho công việc về landing page và SEO
  • Dashboard được chuyển sang Pure React + TanStack Router + Rspack
  • API chạy trên máy chủ Python FastAPI trên Google Cloud Run và tự động mở rộng theo nhu cầu
• Việc chọn đúng công cụ là quan trọng, và với chúng tôi, Next.js là một lựa chọn quá mức cần thiết

[zerocyber]

Đúng lúc công ty mình đang chuẩn bị thống nhất/migrate phần frontend sang Next.js thì lại đọc được bài viết này, khiến mình có khá nhiều suy nghĩ....

[nemorize]

Chúng tôi chỉ vận hành các dịch vụ có thể theo hướng mobile "app" first, nên
những phần cần SEO thì hoàn toàn không dùng React (hoặc những thứ tương tự như vậy) và giữ chúng cực kỳ nhẹ.
Web chỉ được dùng với mục đích câu SEO, rồi dẫn người dùng sang app...

[beenzinozino]

"Việc chọn đúng công cụ là quan trọng, và với chúng tôi, Next.js là một lựa chọn quá mức cần thiết"

Có vẻ như câu cuối mới là điểm mấu chốt.

Để chọn được công cụ phù hợp, có lẽ việc trải qua thật nhiều kiểu thất bại khác nhau cũng là điều quan trọng.

[iolothebard]

Việc cần SEO có nghĩa là nội dung mới là cốt lõi,
nhưng vì các component UI (?) và state lại chiếm phần cốt lõi nên… những sinh vật kỳ quái như SSR, ISR, Hydrate… đã ra đời…

[schang124]

Tôi khá đồng cảm với nội dung này.
Cá nhân tôi, nếu không phải trường hợp cần SEO thì tuyệt đối không đưa Next.js vào sử dụng.
Giống như bài viết ở trên, khi chỉ dùng React thì có nhiều ưu điểm:

• Loại bỏ sự phức tạp và các pattern không cần thiết đặc trưng của Next.js.
  • Việc bảo trì trở nên gọn gàng hơn
• Không còn phải gánh các chi phí SSR không cần thiết
• Có nhiều quyền lựa chọn hơn với các thư viện thuộc hạ tầng FE như router, bundler, v.v.

[jhj0517]

Tôi không rõ lắm, nhưng có vẻ thời gian build chênh lệch khá nhiều.

[bichi]

Có vẻ bạn vẫn chưa biết rằng React chậm hơn nhiều so với các framework khác nhỉ.

[slowandsnow]

Không phải vì tốc độ quan trọng. Nếu tốc độ thật sự quan trọng thì có lẽ expressjs đã không còn được dùng nữa. Cộng đồng và hệ sinh thái thư viện áp đảo hơn nhiều.

[devheerim]

Có vẻ bài viết này tập trung vào việc di chuyển từ Next sang React nhỉ haha

[bbulbum]

Cộng đồng React đã từ bỏ CRA ngay từ giai đoạn khởi đầu và chuyển sang các framework, nên tôi không chắc việc đi ngược lại xu hướng đó có phải là một lựa chọn dễ dàng hay không.

[sacru2red]

Phần lớn là đã chuyển sang vite, và hiện tại chúng tôi vẫn sử dụng framework khi cần.

[bbulbum]

react.dev có nói rằng khi xây dựng một ứng dụng mới hoặc toàn bộ website bằng React, họ khuyến nghị sử dụng framework.

Nên là ~

[kandk]

Thú vị thật. So với React thì Next nặng hơn à? Mình mới chỉ thử thiết lập dự án với Next, nhưng việc xây dựng dự án và bắt đầu phát triển đã diễn ra cực kỳ đơn giản.

[cichol]

"Đơn giản" <= để đạt được điều này, có rất nhiều phép màu (?) ẩn bên dưới kéo theo nhiều đánh đổi.

[beenzinozino]

Đồng cảm. Có vô số phụ thuộc khổng lồ ẩn bên dưới Next.js...

[GN⁺]

Ý kiến Hacker News

• Nhiều người quá tập trung vào việc liệu ý tưởng của mình có thể mở rộng tới hàng tỷ người dùng hay không. Vì thế mới có chuyện dùng Kubernetes cho một website chỉ có 5 lượt truy cập. Tôi cũng từng thấy sinh viên dùng Next.js để làm những website mà lẽ ra chỉ cần HTML + CSS đơn giản là đủ

• Tôi đã xây dựng dự án bằng Next.js nhưng cảm thấy nó quá phức tạp để sử dụng. API truy cập cookie giữa client và server khác nhau, rồi còn phải truy cập biến môi trường bằng process.env.NEXT_PUBLIC_*, rất dễ gây rối. Tôi muốn viết code có thể chạy ở cả client lẫn server với thay đổi tối thiểu, nhưng thực tế không được như vậy. Tôi cảm thấy việc học và chi phí phụ trội của Next.js không xứng đáng với những gì nó mang lại

• Codebase đã đơn giản hơn và tốc độ render trang cũng nhanh hơn. Thật đáng tiếc khi cộng đồng bị đẩy vào những framework như thế này một cách không cần thiết. Phần lớn mọi người chỉ cần npx rsbuild init. Dùng rspack và rsbuild là đã có một router đơn giản cùng sự tối giản rất đẹp

• Tôi dùng Next.js từ sau khi v14 phát hành và rất hài lòng. Với RSCs, nhiều phần của ứng dụng vẫn hoạt động tốt ngay cả khi JS phía client bị tắt. Nó có sức mạnh đơn giản của ứng dụng PHP, đồng thời cho phép đưa các client component có trạng thái, tương tác, cùng hệ thống kiểu, vào "cấp lá" của cây view một cách mượt mà

• Nhờ Rails và Hotwire, tôi đã thoát khỏi sự hỗn loạn của hệ sinh thái React. Có quá nhiều lựa chọn như thư viện quản lý trạng thái, meta-framework, thư viện data fetching, v.v. Không cần biến công việc đơn giản là hiển thị dữ liệu từ server lên trang thành thứ gì đó phức tạp

• Tôi đang làm việc với một CMS (PayloadCMS) dùng NextJS, và NextJS là công nghệ tệ nhất tôi từng sử dụng

• Gần như mọi dự án dùng các framework/thư viện frontend nặng như Next.js, React, Vue sẽ tốt hơn nếu dùng thư viện xử lý template ở backend. Đôi khi render phía client qua EJS cũng có ý nghĩa. Tôi thực sự không hiểu vì sao lại phải dùng framework

• Tôi dùng Next.js để tối ưu SEO và crawling. Nếu trang không cần được crawl (ví dụ: dashboard sau màn hình đăng nhập), thì không cần Next.js, dùng React thuần sẽ đơn giản hơn

• Tôi ngạc nhiên khi Next.js đã trở thành lựa chọn khởi đầu mặc định. So với 2~3 năm trước, đây giống như một thay đổi rất lớn

• Tôi đang thử dùng Vike để thay thế một ứng dụng NextJS và khá hài lòng. Nó cho phép tôi xây dựng theo cách mình muốn mà không bị cản trở

[aer0700]

Ứng dụng chỉ có 5 người truy cập mà lại dùng k8s... ghê thật đấy