Gatsby vs. Next.js

Gatsbyjs và Next.js là hai chủ đề nóng nhất trong phát triển web hiện nay. Tôi thấy nhiều người trên diễn đàn và phần bình luận YouTube hỏi tại sao chọn cái này hơn cái kia. Tôi đã đắm chìm trong thế giới Next.js và Gatsbyjs 12 tháng qua, và tôi tin đó làm tôi đủ tư cách để tham gia thảo luận.

Khi chọn Next.js hoặc Gatsby cho dự án, câu "công cụ đúng cho việc đúng" nảy ra. Đừng lo, tôi không để bạn lurch với câu trả lời mơ hồ.

TLDR:

Gatsby và Next.js đều là framework React và đều cung cấp SSR (Server-Side Rendering) out of the box (tốt cho SEO).
Next.js ít opinionated (ít định kiến) hơn, nhưng đường cong học tập dốc hơn, ít "pin" đi kèm, nghĩa là bạn tự lo nhiều hơn.
Next.js được cho là tốt hơn cho trang web có lượng dữ liệu khổng lồ cần cập nhật thường xuyên.

Điểm tương đồng Next.js và Gatsby.js

Có lý do tốt mọi người so sánh Gatsby và Next.js. Chúng giống nhau nhiều hơn khác nhau. Do đó, hãy xem trước những gì Gatsby và Next.js chung, rồi bàn về khác biệt.

Gatsby và Next.js:

Cả hai cung cấp hiệu suất cao out-of-the-box.
Đều là framework JavaScript, và đều dựa trên React.
Cả hai cho Server-Side Rendering (SSR) và Client-Side Rendering (CSR) out of the box
Cả hai cung cấp Static Site Generation (SSG) và Dynamic Site Generation (DSG).
Cả hai có code-splitting và caching xuất sắc out of the box.
Cả hai cung cấp prefetch dữ liệu trang. Gatsby làm tự động, Next.js có prop prefetch dùng với component Link (cho routing).
Cả hai cung cấp routing tự động cho trang, dùng router riêng (Gatsby dùng Reach Router, Next.js dùng Next.js Router).
Cả Gatsby và Next.js có thể lấy dữ liệu từ Rest API, ví dụ dùng WordPress, Contentful, hoặc Prismic làm CMS backend.

Out of the box, Gatsby và Next.js cho bạn cả hai thế giới tốt nhất về SSR và CSR. SSR tốt cho SEO, CSR tốt cho chuyển trang tức thì (không load lại) như app native.

Khác biệt Next.js và Gatsby.js

Tôi muốn rõ ràng: dưới đây dựa trên những gì bạn nhận được out of the box với từng framework, không phải những gì chúng có thể trở thành qua tùy chỉnh. Cả Next.js và Gatsby đều linh hoạt cao.

Gatsby và Next.js có thể tùy chỉnh "vô hạn". Cả hai đều cam đoan điều đó. Câu nói kinh điển "muốn làm mọi thứ cho mọi người" nảy ra. Không cái nào muốn loại khách hàng tiềm năng, và như người kinh doanh giỏi, họ tập trung vào điểm mạnh hơn điểm yếu. Đúng như vậy.

Không cái nào nói dối, nhưng vì cả Next.js và Gatsby đều linh hoạt và tiến hóa liên tục (với tài chính mạnh), khó nói cái nào tốt hơn cho trường hợp cụ thể khi nói dài hạn.

Tôi không có lợi ích liên quan, nên đây là góc nhìn khách quan. Các lĩnh vực chính làm Next.js và Gatsby khác nhau:

Gatsby ép bạn dùng GraphQL (opinionated), Next.js thì tùy chọn.
Gatsby xử lý biến đổi hình ảnh out-of-the-box (hơi opinionated) dù không ép bạn dùng.
Gatsby thêm lazy-loading cho hình ảnh tự động (opinionated)
Trang Gatsby có thể biến thành Progressive Web App (PWA) bằng cài plugin nhỏ. Tôi chưa thấy cách đơn giản làm vậy trong Next.js.
Next.js cung cấp cả dynamic và static routing. Theo tôi biết Gatsby chỉ cung cấp static/hardcoded routing. Tôi không 100% chắc về cái này vì khó tìm info rõ ràng (sẽ cập nhật khi biết thêm).
Gatsby làm SSR trong giai đoạn build site (SSG).
Next.js làm SSR động khi request trang — nhưng cũng cung cấp SSG qua static export.

Về tùy chỉnh, Gatsby có nhiều plugin hữu íchmostly straight forward cài đặt (từ Comments đến Algolia cho search). Next.js có thư mục /examples trong repo GitHub demo các thư viện ("plugins") dùng với Next. Nhưng theo kinh nghiệm tôi, dùng examples Next.js khó cấu hình hơn dùng plugin Gatsby.

Lấy dữ liệu động (Dynamic data fetching)

Mặc dù Gatsby là static generated out of the box, Gatsby có thể query các server API để động lấy dữ liệu.

Next.js cũng làm dynamic data fetching tương tự.

Nếu cần SSR, bạn có thể dùng GraphQL API built-in của Gatsby để consume dữ liệu từ CMS như WordPress hoặc Contentful ("Headless CMS") và dùng webhook (từ CMS) để handle auto-deploy mỗi khi publish nội dung.

Convention vs. Configuration (Quy ước vs Cấu hình)

Nói chung, Gatsby là cái opinionated hơn. Ưu điểm là bạn ít quyết định hơn. Next.js cần cấu hình nhiều hơn để chạy. Ưu điểm là không gì bị ép buộc.

Next.js giống sản phẩm "xây dựng app từ nền tảng", với một số pin tiện lợi đi kèm (SSR, routing, prefetching, code-splitting).

Gatsby giống sản phẩm "điểm xuất phát đã bao gồm những gì bạn có thể muốn", với nhiều pin đi kèm (GraphQL, prefetching, SSR, code-splitting, lazy loading, image transformations).

Nếu cần tùy chỉnh chính xác từng góc sản phẩm, Next.js là lựa chọn tốt hơn, đơn giản vì nó "barebone" hơn (ít việc được làm sẵn) out of the box.

Không bao giờ vui khi bắt đầu dự án bằng cách gỡ bỏ tính năng từ framework, nên nếu bạn không thích GraphQL (bất kỳ lý do) thì Gatsby không dành cho bạn.

GraphQL đang là hot trend (có lý do tốt) khiến khó chống lại việc Gatsby đưa nó vào framework. Tôi coi đó là bonus, nhưng sở thích bạn có thể khác. Đáng chú ý Apollo (GraphQL engine) là một trong những thêm phổ biến nhất cho Next.js apps.

Về Gatsby xử lý image transformations và lazy loading giúp bạn, dù opinionated, nhưng hiệu suất khổng lồ nó mang lại sẽ khiến bạn tha thứ cho việc họ quyết định giúp bạn. Nhưng lại, có thể bạn muốn tự xử lý image transformations, lúc đó Next.js là lựa chọn tốt hơn.

Gatsby vs. Next.js cho SEO

Vì cả Gatsby và Next.js đều server-side rendered out-of-the box, cả hai đều lựa chọn tuyệt vời cho trang web cần SEO (Search Engine Optimization) tuyệt vời — nghĩa là hầu hết trang web công khai hiện nay.

Tuy nhiên, có trường hợp SEO cụ thể Next.js tỏa sáng so với Gatsby:

Nếu bạn xây dựng nền tảng như Twitter hoặc Reddit, nơi cần đẩy cập nhật nội dung liên tục — và cần SEO tối ưu cho tất cả nội dung — thì Next.js là lựa chọn tốt nhất.

Tại sao? Vì Next.js có thể dynamic server-side render cập nhật nội dung từ server của bạn, ngay lập tức khi có thay đổi.

Để Gatsby hiển thị nội dung mới, bạn phải rebuild và redeploy app mỗi lần nội dung thay đổi. Điều này ổn cho blog, trang eCommerce, và hầu hết các trang khác chỉ cần đẩy cập nhật một lần ngày, thậm chí một lần giờ.

Nếu ngược lại trang Gatsby của bạn dynamic fetch dữ liệu từ API bên ngoài để hiển thị cập nhật (ví dụ qua dịch vụ comments như Talkard hoặc Disqus) thì bạn có thể real-time content updates trên trang Gatsby — nhưng bạn không nhận được lợi ích SEO, vì cập nhật sẽ client-side rendered — không phải server-side rendered (điều bạn muốn cho SEO).

Quan sát thực tế chung

Công ty lớn với trang lớn thường dùng Next.js thay vì Gatsby. Đừng hiểu sai, trang tài liệu chính thức ReactJS dùng Gatsby. Tôi chỉ nói về quan sát.

Trang lớn dùng Next.js:

Marvel.com
Netflix
Uber Marketplace
Invisionapp
Material UI

Trang lớn dùng Gatsby

ReactJS
MarvelApp.com

Thú vị, Marvel dùng cả hai. Dùng Next.js cho trang chính, Gatsby cho MarvelApp (nền tảng thiết kế).

Về blogging, tôi chỉ thấy vài ví dụ Next.js blog tốt nhưng khá nhiều Gatsby blog tốt. Ví dụ của Tania Rascia là yêu thích.

Mặc dù Gatsby khẳng định không muốn bị nhìn là "chỉ static site generator cho blogger khác" (như Jekyll), điều đó không thay đổi thực tế nó phổ biến cho blogging, nhiều user WordPress chuyển sang Gatsby vì lý do đó (kể cả Tania trên).

Headless CMS với Gatsby hoặc Next.js

Nhiều dev nói về trending "Headless CMS" hoặc "Decoupled CMS", nơi bạn dùng ví dụ WordPress làm backend rồi dùng React (hoặc Angular/Vue) consume dữ liệu qua Rest API/GraphQL. Cả Next.js và Gatsby đều dùng được làm frontend app cho Headless CMS. Nghe hứa hẹn trong lý thuyết, nhưng cho đến nay tôi chỉ thấy vài ví dụ tốt:

Next.js + WordPress bởi Kata.ai
Gatsby + WordPress bởi Chase McCoy
Gatsby + WordPress bởi Indigo Tree
Gatsby + WordPress bởi Adam Rasheed

Adam và Chase Gatsby + WordPress đều rất nhanh. Còn Kata Next.js ví dụ đẹp nhưng hơi chậm. Vì hiệu suất cao là selling point chính Next.js, Kata không phải ví dụ thuyết phục nhất tại sao dùng Next.js với WordPress.

Headless CMS vẫn còn mới. Chắc chắn Headless CMS nói chung (không chỉ Headless WordPress) sẽ là chủ đề nóng 2020 về sau. Vì cả Gatsby và Next.js lo SSR, cả hai đều lựa chọn chắc chắn làm frontend Headless.

Deploy/Hosting Gatsby và Next

Vì Gatsby static generated (prebuild) trước deploy, nó chạy ở đâu cũng được không cần server riêng. Thông thường Next.js cần server Node.js trừ khi toàn bộ app được export static site, giống Gatsby. (có thể làm được). Một số hosting tailer-made cho cái này hơn cái kia.

Gatsby + Netlify

Gatsby và Netlify là cặp đôi trời sinh. Nếu trang serverless, deploy Gatsby lên Netlify có thể config trong chưa đầy 30 giây.

Tiếp theo continuous deployment chỉ còn lệnh git push origin master trong terminal — nếu dùng plugin gatsby-plugin-netlify.

Next.js + Now

Next.js pair tốt với dịch vụ hosting Now, và có lý do, Zeit là công ty đứng sau cả Now (hosting) và Next.js (framework).

Giống Netlify, deploy lên Now có thể trong vài giây, nhưng tùy loại app deploy.

Lưu ý: dù Gatsby và Next.js pair tốt với hosting cụ thể, bạn thực sự có thể host static/frontend Next.js app trên Netlify (ví dụ), và host Gatsby trên Now (ví dụ).

Cả hai framework đều host được trên DigitalOcean, Heroku v.v.

Nếu muốn host backend server/API riêng (khác serverless) cho Next.js hoặc Gatsby app thì muốn xem DigitalOcean, Heroku, hoặc Now. Chú ý ("as of Now") Zeit's Now v2.0, họ không còn support Docker, dealbreaker cho nhiều dev.

Next.js vs Gatsby thời gian deploy

Có độ trễ giữa cập nhật khi rebuild và re-deploy Gatsby. Độ trễ bao nhiêu tùy kích thước trang. Càng lớn càng lâu rebuild và redeploy. Tôi mới build trang này với Gatsby, mất khoảng 2 phút từ rebuild đến redeploy xong, trang khá nhỏ.

Next.js không có vấn đề rebuild > redeploy > downtime. Nếu chạy backend server riêng, nội dung mới cập nhật ngay lập tức.

Điều này có thể không thành vấn đề nếu Gatsby làm incremental updates dễ dàng không downtime/delay, nhưng hiện tại bạn tự tìm cách (ví dụ websocket).

Tài nguyên

Postlight.com có WordPress + Next.js starter kit thú vị trên GitHub.
Cho Headless CMS, một số alternative tốt cho WordPress: Prismic, Contentful, Sanity, Ghost và ButterCMS