مقایسه Next.js و GatsbyJS

مقدمه

اخیرا فریم‌ورک React رشد بسیاری داشته است و نه تنها در توسعه فرانت‌اند، بلکه در موارد زیر نیز استفاده می‌شود:

• توسعه برنامه‌های دسکتاپ توسط Electron
• بازی‌های ساده برای مرورگر‌ها
• ایجاد برنامه‌های واقعیت مجازی توسط React 360
• ساخت برنامه‌های تلفن همراه توسط React Native

React به طرز چشم‌گیری در حوزه وب رشد کرده و گسترش یافته است. فریم‌ورک‌ها و کتابخانه‌های زیادی وجود دارند که بر اساس React ساخته شده‌اند و این قابلیت را در اختیار توسعه‌دهندگان می‌گذارند که تجربه بهتر و سرعت توسعه بیشتری داشته باشند.

اکنون تمام جامعه کاربری و پروژه‌هایی که در کنار React وجود دارند، بخشی از اکوسیستم React به حساب می‌آیند. امروز دو مورد از فریم‌ورک‌های معروف React، یعنی Next.js و Gatsby را بررسی می‌کنیم.

GatsbyJS چیست؟

Gatsby یک فریم‌ورک SSG مبتنی بر GraphQL و React است که به‌دلیل عملکرد سریع برنامه نهایی و برخی دیگر از ویژگی‌های ارائه شده، توجه توسعه‌دهندگان را به خود جلب کرده و به‌سرعت در حال تبدیل شدن به یکی از اجزای اصلی توسعه‌ی مدرن وب است.

شما برای کسب اطلاعات بیشتر در رابطه با این فریم‌ورک می‌توانید مقاله‌ی Gatsby چیست؟ را مطالعه کنید.

Next.js چیست؟

Next.js یکی دیگر از فریم‌ورک‌های معروف React است. ایده ساخت این فریم‌ورک، ایجاد برنامه‌هایی بر اساس React، بدون کمترین پیکربندی است که در سمت سرور رندر خواهند شد. کارایی و عملکرد عالی، مزیت اصلی Next.js نیست و در عوض تجربه بهتری در اختیار توسعه‌دهندگان (developer experience) قرار داده است و رنج و زحمت ایجاد برنامه‌هایی که در سمت سرور رندر می‌شوند را کاهش می‌دهد.

همچنین Next.js از ساخت سایت‌های استاتیک نیز پشتیبانی می‌کند، اما این قضیه، موضوع اصلی نیست. در رابطه با محدودیت‌های Next.js در موارد استفاده مختلف، در ادامه صحبت خواهیم کرد. همچنین برای آغاز یادگیری Next.js، می‌توانید به مستندات Next.js مراجعه کنید.

تفاوت SSR یا Server Side Rendering با وبسایت‌های استاتیک

برنامه‌هایی که در سمت سرور رندر می‌شوند، به صورت پیشفرض برای سئو بهینه شده‌اند. SSR بسیار سریع‌تر است، زیرا منتظر نمی‌ماند که مرورگر جاوااسکریپت را لود کند تا محتوا نهایی را به کاربر نشان دهد. SSR به سرور‌های مناسبی نیاز دارد تا responseها را در هر لحظه ارسال کنند.

در طرف دیگر، وبسایت‌های استاتیک نیز سریع هستند، زیرا آن‌ها بدون هیچ پردازشی فایل‌های HTML و CSS را به کلاینت ارائه می‌کنند. وبسایت‌های استاتیک توسط CDN قابلیت cache شدن دارند و این قضیه باعث می‌شود که نسبت به وبسایت‌های پویا، سریع‌تر باشند. وبسایت‌های استاتیک، اگر تنها شامل محتوای استاتیک باشند، در سئو به خوبی عمل می‌کنند.

شباهت‌های Next.js و Gatsby

با اینکه هر کدام مشکل مختلفی را حل می‌کنند، اما شباهت‌های زیادی با یکدیگر دارند. مسیر یادگیری هر دو فریم‌ورک، اگر از نحوه ایجاد وبسایت‌ها بر اساس React آگاهی داشته باشید، سخت نخواهد بود و تجربه جدیدی برای هر توسعه‌دهنده، در هر دو فریم‌ورک ایجاد می‌کند. به سادگی و سرعت هر چه تمام‌تر می‌توانیم وبسایت را ایجاد کنیم و قابلیت‌های بیشتری به آن اضافه کنیم، زیرا هر دو فریم‌ورک، مستندات جامع و کاملی را ارائه می‌کنند. هر دو به جهت توسعه سریع‌تر، قابلیت hot-reloading را ارائه می‌کنند (به عبارتی با ایجاد هر تغییر بلافاصله و بدون نیاز به هیج کاری، می‌توانید نتیجه را مشاهده کنید).

cache کردن و عملکرد عالی، از مزایای پایه‌ای آن‌‌ها حساب می‌شوند و نیاز نیست تا در رابطه با بهبود کد، نگران باشیم. همچنین به صورت پیشفرض برای صفحه‌های جدید، route ایجاد می‌کنند، یا به صورت جداگانه برای هر صفحه، route یکتا و یونیکی وجود دارد.

به صورت هوشمندانه صفحه‌ها را لود می‌کنند، به نحوی که لینک‌های صفحه‌های بعد را به صورت async، به هنگام اسکرول کاربر، لود می‌کنند. همچنین امتیاز Lighthouse برای وبسایت‌هایی که توسط Next.js و Gatsby ساخته شده‌اند، بسیار چشم‌گیر است.

این که کدام یک، یعنی Next.js یا Gatsby، وبسایت سریع‌تری ایجاد می‌کند، بستگی به نیاز و استفاده‌تان دارد. به جای بررسی نکته‌های مثبت و منفی برای هرکدام، که به راحتی می‌توانید امثال آن را در مقاله‌های مختلف پیدا کنید، رویکرد‌های مختلفی را بررسی می‌کنیم تا تشخیص دهیم که کدام فریم‌ورک، انتخاب بهتری برای حل مشکل‌های موجود است.

موارد استفاده Next.js و Gatsby

در این قسمت، میان این دو فریم‌ورک، یکی را براساس موارد استفاده انتخاب می‌کنیم:

• وبسایت‌های استاتیک ساده.
• وبسایت‌های بزرگ برای ارائه خدمات به تعداد زیادی از کاربران.
• برنامه‌هایی که در سمت کلاینت رندر می‌شوند (Single Page Apps = SPA / Multi Page Apss = MPA).
• برنامه‌های وب هیبریدی (SPA و SSR در یک برنامه).

وبسایت‌های استاتیک ساده

موارد مورد نیاز:

• یک وبسایت استاتیک با ده‌ها صفحه استاتیک و ثابت.
• برخی از صفحه‌ها گاها آپدیت می‌شوند. همچنین برخی دیگر مرتبا آپدیت نمی‌شوند.
• از سئو پشتیبانی کند.
• محتوای یکسانی به تمامی کاربران ارائه کند.
• بروزرسانی‌های تیم داخلی، نباید تاثیری بر real-time بودن بگذارد.

مثال‌ها:

• وبسایت‌های استاتیک، نظیر وبسایت شرکت‌ها، ارائه دهنده خدمات، وبسایت‌هایی که اطلاعاتی را ارائه می‌دهند و …
• صفحه‌های پابلیک یا عمومی برای هر وبسایتی که یک محصول یا خدمتی را ارائه می‌دهند.
• بلاگ‌ها و وبسایت‌های شخصی.
• بلاگ‌های کوچک که توسط تعداد کمی کاربر و به صورت خصوصی و محرمانه، مدیریت می‌شود (مانند اعضا یک شرکت).

این‌ها مواردی بودند که در آن‌ها، تعداد صفحه‌های قابل پیشبینی است و نیازی نیست که محتوا توسط سرور رندر شود، زیرا برای تمام کاربران استاتیک و یکسان است. Gatsby برای چنین وبسایت‌هایی طراحی شده است. همچنین این موارد را می‌توانید توسط قابلیت جدید static export، در Next.js ایجاد کنید.

با‌این‌حال، Gatsby با اختلاف زیادی در این مورد، به دلیل ارائه پشتیبانی از پلاگین‌های مختلف، برای دریافت اطلاعات از تمامی CMSها، دیتابیس‌ها، REST APIها و GraphQL، برنده می‌شود. همچنین پلاگین‌های مختلفی دارد که از انواع داده‌های مختلف، نظیر JSON، Markdown و MDX یا Markdown with JSX، پشتیبانی می‌کنند. در عین حال، گزینه‌های زیادی برای ساخت و میزبانی وبسایت‌های مختلف در هر جا، ارائه می‌کند.

محتوا و وبسایت را از یکدیگر جدا می‌کند، پس افرادی که توسعه‌دهنده نباشند، می‌توانند به سادگی محتوا را تغییر دهند و این تغییرها را مستقیما در وبسایت مشاهده کنند.

Next.js هر چیزی که به دیتای شما وابسته باشد را مدیریت نمی‌کند. باید روش خودتان را برای دریافت اطلاعات و نمایش آن به عنوان وبسایت، ایجاد کنید. می‌توانید وبسایت‌های استاتیک ایجاد کنید، اما افرادی که توسعه‌دهنده نباشند، برای ایجاد تغییر در محتوا، به کمک نیاز خواهند داشت. این مشکل بزرگی است که هر CMS آن را حل می‌کند و Gatsby با استفاده از پلاگین‌های مختلف، می‌تواند به CMSهای مختلف متصل شود و اطلاعات را از آن‌ها دریافت کند.

برنده: Gatsby

Gatsby برای ایجاد وبسایت‌های استاتیک کارآمد و سریع، مناسب‌تر است. تجربه توسعه‌دهنده، نکته اصلی برای جمع‌بندی این بخش خواهد بود:

• توسعه‌دهندگان می‌توانند بر روی طراحی و استایل وبسایت تمرکز کنند.
• Gatsby محتوا را جدا می‌کند و بدین ترتیب هر شخص، به سادگی می‌تواند محتوا را تغییر دهد.
• همچنین Gatsby فرایند و مسیر توسعه را با استفاده از پلاگین‌ها، تم‌ها و starterها، کوتاه‌تر می‌کند.

وبسایت‌های بزرگ برای ارائه خدمات به تعداد زیادی از کاربران

موارد مورد نیاز:

• یک وبسایت بزرگ که محتوای آن توسط کاربرانی که در احراز هویت تایید شده‌اند، اضافه می‌شود.
• محتوای وبسایت عمومی است و برخی از قابلیت‌های مشخص، خصوصی هستند.
• محتوا بر اساس هر کاربری که login کرده و با توجه به علایق آن‌ها، نمایش داده می‌شود.

مثال:

• وبسایت dev.to. یک وبسایت با حجم زیادی از کاربران. برای توسعه‌دهندگان، توسط توسعه‌دهندگان!
• فروم‌های آنلاین.

Next.js انتخاب خوبی برای چنین نیازمندی‌هایی است، زیرا توسط آن می‌توانید محتوایی پویا، به ازای هر کاربری که login کرده باشد، نمایش دهید. نمی‌توانیم توسط Gatsby، فایل‌های استاتیک HTML را به ازای هر کاربر، کامپایل کنیم (گرچه راه‌حلی برای این موضوع وجود دارد و آن را در بخش وبسایت‌های هیبریدی مشاهده خواهیم کرد). SSR برای ساخت وبسایت‌هایی که بر اساس احراز هویت کاربران ساخته شده‌اند، کمک بسیاری می‌کند.

از آنجایی که محتوا توسط کاربران زیادی ایجاد شده است و به ازای هر کاربر جدید، تعداد آن‌ها افزایش می‌یابد، کامپایل صفحه‌های استاتیک در زمان بیلد، غیرممکن خواهد بود. نمایش محتوای مرتبط، در زمان اجرا، آسان‌تر خواهد بود.

برای Gatsby، اشکال اصلی برای ایجاد چنین وبسایت‌هایی، فرایند بیلد و زمان آن است. اغلب اوقات، کاربران می‌خواهند محتوای خود را به صورت real-time مشاهده کنند و نه بعد از پایان مراحل بیلد. اگر تعداد کاربران زیاد باشد، نه تنها چند دقیقه، بلکه چند ساعت زمان خواهد برد.

Gatsby بر روی بهبود این موضوع کار می‌کند و پشتیبانی از بیلد‌های سریع‌تر را تحت عنوان Gatsby Cloud، ارائه می‌کند. البته دستیابی به این قابلیت، زمان زیادی خواهد برد و همچنین نمی‌دانیم که این قابلیت، بخشی از قابلیت‌های متن‌باز آن خواهد بود یا خیر.

برنده: Next.js

برای وبسایت‌هایی که چندین کاربر برای دسترسی و ویرایش محتوا دارند، استفاده از Next.js انتخاب بهتری است.

• SSR برای محتوای عمومی نیاز است.
• محتوا باید بر اساس هر کاربر، پویا باشد.
• حتی اگر نیاز باشد تا محتوای استاتیک بلاگ، به صورت real-time منتشر شود و به جهت ویرایش برای کاربر، در دسترس باشد.

در این موارد، فریم‌ورک‌هایی که بر اساس زمان بیلد ساخته شده‌اند، به خوبی کار نخواهند کرد.

برنامه‌هایی که در سمت کلاینت رندر می‌شوند (SPA/MPA)

موارد مورد نیاز:

• ایجاد وبسایت برای محصولات، چه یک برنامه تک صفحه‌ای یا یک برنامه چند صفحه‌ای در سمت کلاینت.
• برنامه بعد از اتمام احراز هویت در دسترس قرار بگیرد.
• سئو مهم نباشد. تمام برنامه پویا باشد.

مثال‌ها:

• Trello
• Asana
• Gmail

در اینجا سئو اهمیت ندارد، اما سرعت و پاسخ‌دهی سریع برای کاربر مهم است. برای چنین وبسایت‌هایی، نمی‌توان میان Next.js و Gatsby، یکی را انتخاب کرد. در ادامه با جزئیات، نحوه استقرار برنامه‌های وب، در هر دو را بررسی می‌کنیم.

Gatsby برای برنامه‌های وب پویا

پیشتر گفتیم که Gatsby در زمان بیلد، عملیات بیلد را انجام می‌دهد و وبسایت استاتیک را ارائه می‌کند. اما این موضوع کاملا صحیح نیست. چرا؟

حتی با اینکه Gatsby یک وبسایت استاتیک ایجاد می‌کند، React را در سمت کلاینت، دوباره ارائه می‌کند. بنابراین توسط Gatsby، می‌توانید هر برنامه سمت کلاینتی را، همانند create-react-app یا CRA، ایجاد کنید. اما چرا باید Gatsby را به جای CRA انتخاب کنیم؟

Gatsby به صورت پیشفرض از code splitting پشتیبانی می‌کند. توسط CRA، این کار را باید خودتان انجام دهید. همچنین CRA مکانیسمی برای پشتیبانی از برنامه‌های وب چند صفحه‌ای، ارائه نمی‌کند. این کار ممکن است، اما باید آن را دستی انجام دهیم. از طرف دیگر، Gatsby از برنامه‌های چند صفحه‌ای نیز پشتیبانی می‌کند.

با این اوصاف، سه دسته کاربر مختلف به همراه تجربه‌های کاربری مختلف دارید. پشتیبانی از چندین صفحه در Gatsby، به سادگی، برای تفکیک و هدایت کاربران، بعد از اتمام احراز هویت به صفحه‌های مربوطه، به شما کمک می‌کند. در CRA نیاز دارید تا این موضوع را توسط router خودتان مدیریت کنید. Gatsby از مسیریابی یا routing برای routeهای سمت کاربر، پشتیبانی می‌کند. CRA چنین قابلیتی ندارد، اما پیاده‌سازی آن دشوار نخواهد بود.

دریافت اطلاعاتی کلی، در رابطه با لینک‌های بعدی و assetها، در Gatsby بسیار ساده است و لود صفحه را سریع‌تر می‌کند. دستیابی به چنین حدی از بهینه‌سازی در CRA، توسط خودتان بسیار دشوار خواهد بود.

با همه این اوصاف، ساخت برنامه‌هایی که در سمت کلاینت، رندر می‌شوند، به راحتی توسط Gatsby قابل انجام است. بنابراین فکر نکنید که Gatsby تنها یک سازنده وبسایت‌های استاتیک است، بلکه کارهای بیشتر از این‌ها را می‌تواند مدیریت کند. در واقع فریم‌ورک کاملی برای ایجاد برنامه‌های وب مدرن است.

Next.js برای برنامه‌های وب پویا

اکنون زمان بررسی Next.js برای ایجاد برنامه‌های وب مدرن و پویا فرا رسیده است. تا به اینجا می‌دانیم که Next.js برای ساخت برنامه‌های SSR مناسب است، که موضوع صحیح است، اما این تمام کاری نیست که این فریم‌ورک انجام می‌دهد. این فریم‌ورک نیز React را در سمت کلاینت ارائه می‌کند، پس می‌توانید توسط آن برنامه‌های سمت کلاینت بر اساس React، ایجاد کنید.

بیشتر مزایای آن همانند Gatsby است، اما به هنگام ایجاد برنامه‌های SSR توسط آن، مزایای بیشتری را ارائه می‌کند. برای مثال، می‌توانید همانند Gatsby و CRA، یک وبسایت استاتیک را رندر و تمام منطق و logic خودتان را در سمت کلاینت، پیاده کنید. از لحاظ فنی نیازی نیست تا از قابلیت‌های موجود و مرتبط با SSR، در Next.js استفاده کنید. زیرا می‌توانید توسط Next.js، یک برنامه چند صفحه‌ای یا تک صفحه‌ای که در سمت کاربر رندر می‌شود را ایجاد کنید.

مزیت اصلی Next.js، این است که قابلیت‌های SSR را در کنار قابلیت‌های برنامه‌های سمت کلاینت، ارائه می‌کند. از code splitting بر اساس صفحه‌ها پشتیبانی می‌کند و همچنین این اجازه را می‌دهد تا بخش‌هایی که نیاز دارید را به صورت پویا وارد کد کنید.

رندر اولیه رابط کاربری در برنامه‌های سمت کلاینت، معمولا بسیار آهسته است و routing توسط مرورگر بسیار سریع‌تر مدیریت می‌شود. اما در SSR، می‌توانیم رابط کاربری را سریع‌تر رندر و ارائه کنیم، همچنین صفحه‌های بعدی نیز توسط routeهای موجود در سمت کاربر، لود خواهند شد.

از این طریق می‌توانیم به مزایای Next.js در SSR و CSR دست پیدا کنیم.

برنده: مساوی

بنابراین برای برنامه‌های وب پویا، این دو فریم‌ورک، کارا هستند. اما Next.js در ایجاد رابط کاربری اولیه جلوتر است.

برنامه‌های وب هیبریدی

مثال‌ها:

• Twitter
• Redit
• Stack Overflow

برنامه‌های وب هیبریدی، آخرین نوع در مثال ما هستند. قبل‌تر در رابطه با این که Next.js هم SSR و CSR را پوشش می‌دهد، صحبت کردیم، که در آن رابط کاربری را توسط SSR رندر می‌کند و در طرف دیگر مسئولیت محتوا بر عهده برنامه React سمت کلاینت خواهد بود. اما چه زمانی هر دو آن‌ها را به صورت همزمان نیاز داریم؟

اگر صفحه توییتر خود را بدون login کردن چک کنید، برنامه توییت‌های اولیه را از طریق SSR لود می‌کند. اگر اسکرول کنید، مابقی توییت‌ها را در سمت کلاینت، لود می‌کند. اما اگر login کنید، فقط ظاهر برنامه لود می‌شود و جاوااسکریپت‌های سمت کلاینت، توییت‌ها را لود می‌کنند.

بنابراین در داخل یک برنامه، از SSR برای بازدیدکنندگان و CSR برای کاربرانی که login کرده‌اند، پشتیبانی می‌کند. این موضوع برای شبکه‌های اجتماعی بزرگ و وبسایت‌های بر اساس جامعه کاربری نیز، صحیح است.

برنده: Next.js

برای برنامه‌های هیبریدی که به سئو نیازی ندارند، هر دو فریم‌ورک گزینه‌های مناسبی هستند. اما برای برنامه‌هایی که به سئو برای دسترسی پذیری محتوای پویا برای عموم، نیاز دارند، Next.js بهترین گزینه است.

اکنون تفاوت‌های میان یک برنامه هیبریدی و یک برنامه وب را در یک کد واحد، بررسی می‌کنیم. شما یک وبسایت برای شرکت و یک برنامه وب برای محصول یا محصولات در اختیار دارید. قصد دارید این‌ها را توسط یک کد پایه‌ای ایجاد کنید و نه دو وبسایت جدا از هم. در این شرایط، انجام هر دو مورد توسط Next.js و Gatsby، آسان‌تر خواهد بود. می‌توانیم صفحه‌های استاتیک را برای شرکت رندر کنیم و از CSR در برنامه وب ساخته شده برای محصول، استفاده کنیم. به همین روش می‌توانیم از SSR برای وبسایت، به همراه CSR برای برنامه وب استفاده کنیم.

جمع‌بندی

هر دو، فریم‌ورک‌های بسیار مناسب و مفیدی هستند. در این مقاله، برنده هر دو آن‌ها هستند، اما این موضوع، باز هم بستگی به نیاز و استفاده شما دارد. یکی را انتخاب کنید که با نیاز‌هایتان تناسب داشته باشد. بزرگ‌ترین برندگان در اینجا، توسعه‌دهندگان هستند. تجربه آن‌ها در استفاده از این فریم‌ورک‌ها، بهترین چیزی است که می‌توانند کسب کنند. اگر به این دو فریم‌ورک علاقه‌مند شدید، می‌توانید برای شروع به مستندات آن‌ها مراجعه کنید.

منبع: https://blog.logrocket.com/next-js-vs-gatsbyjs-a-developers-perspective