and are modern front-end frameworks based on React. Next.js Gatsby Typically each is regarded as relevant for different use cases. There is a tendency to view Next.js as the go-to choice for large web applications with lots of dynamic content, while Gatsby is - to some extent correctly in my opinion - viewed as most beneficial for applications with small to medium content requirements. In fact, both frameworks can be used to fit a massive range of use cases covering applications big and small. In this article, we'll be taking a look at how they handle the serving of HTML data i.e. rendering. Rendering Modes The advent of frontend libraries like React accompanied a surge in popularity of the (SPA), which is an application that loads a single document and gradually modifies the body of that document in response to user interactions and navigation actions. Single-page application In the past, it was often the case that entire HTML documents had to be loaded from a remote web server whenever a user navigated to a new page. Thankfully this can be avoided nowadays using a SPA. Next and Gatsby largely fit into the SPA paradigm, although they do enhance the functionality that can be achieved by using something basic like the CLI utility. Let's take a look at the three main types of rendering supported by the two of them. create-react-app Server-Side Rendering (SSR) Server-side rendering is a somewhat advanced technique whereby a fully formed HTML document is sent to the client's browser, often providing a better experience by minimizing the perceived loading time. On the other hand, it can increase , which is the time before the page can be interacted with. First Input Delay Other advantages of this rendering technique include better SEO performance, loader perceived load time (no blank screen as is common with CSR), and more efficient data fetching. If your service relies heavily on social media sharing to drive traffic, SSR is hugely beneficial because of its ability to populate and Twitter Cards with rich, dynamic data. Open Graph SSR in Next.js In Next, SSR can be implemented using the method, as seen in the snippet below. This method has access to the initial network request, which can make it useful for loading different data depending on, among other things, the request locale, language or device type. getServerSideProps // _app.tsx MyProject.getServerSideProps = async (context: AppContext) => { const session = await getSession(context.ctx); return { props: { session, }, }; }; Any file listed in the directory of a Next project can have a method. What this method does on a more technical level is define a snippet of JavaScript or TypeScript code that will be run in a serverless function in a Node.js environment - see the for how to do this easily. pages getServerSideProps Next on Netlify plugin Whatever props are returned by will be injected into the page component on the server, which will in turn render a full HTML document to be sent over the wire to the browser. getServerSideProps SSR in Gatsby In spite of its reputation as a static site generator, Gatsby is also capable of performing server-side rendering. In Gatsby, the method can be used to indicate that we want a particular page to use server-side rendering. This might look something like the snippet below: getServerData // my-page.tsx export async function getServerData( props: GetServerDataProps ): GetServerDataReturn<ServerDataProps> { return { status: 200, headers: {}, props: { message: "Hello World", }, } } Like in Next with , the function must be executed in a Node.js environment in order to work. Thankfully there is a a designed to do this without us needing to provision our own infrastructure. getServerSideProps getServerData Netlify plugin Gatsby Cloud also offers automatic setup of SSR as part of its plans, so that is a good option too. Note on SSR Though SSR can be a very powerful tool, it might make it harder to develop and maintain your application code in future since not all developers will be used to it. There may also be additional hosting costs if the server-side code requires additional infrastructure to run on, even though on a service like Netlify the cost will grow linearly with network requests. Static Site Generation (SSG) (or Server-Side Generated) Static Site Generation is a technique whereby all or part of a website is generated in advance, typically in a Node.js runtime. What is great about this is how fast it makes the resultant website. Because all the HTML, CSS and JS has been precompiled into individual bundles for each page, a change in route in the client's browser only requires the browser to load in the bundle for that route, leading to blazingly fast page loading. As a result, SSG is a great choice if you have small to medium content requirements and know that your content is unlikely to change often. Assuming you have certain content that changes according to the user's authenticated state (logged in vs logged out), it may be advisable to use SSG with caution, as rehydration problems can occur if the authenticated state is only known after client-side running of JavaScript, a problem described and one which can also affect SSR. here SSG in Next.js Next.js implements SSG through a function called , which might typically look something like the snippet below: getStaticProps // my-static-page.tsx export const getStaticProps: GetStaticProps = async (context) => { const pageData = await loadDataFromServer(context); return { props: { pageData, }, } } Another useful function in the same mold as this is , which can be used to predefine all the possible routes for a specific type of path. To clarify, say we had a few hundred different articles on a news website, we could define a page called , and would prerender a list of articles defined within its method body. getStaticPaths articles/[id].tsx getStaticPaths If SSG is only required on a subset of, say, the most popular pages, the option can be added to , which will make builds faster, albeit at the expense of an initially slower load time. fallback: true getStaticPaths SSG in Gatsby As Gatsby is pretty much synonymous with SSG, it's no surprise that it's been built to work incredibly well with this type of rendering. On any given Gatsby page, you can define a that can load data and populate the page. Generally speaking, Gatsby is geared towards using a headless CMS like Contentful. Data transfer is oriented around , which is particularly efficient as it allows developers to load only the data that is genuinely required. pageQuery GraphQL export const pageQuery = graphql` query GetBlogPostBySlug($slug: String!) { site { siteMetadata { title siteUrl } } contentfulBlogPost(slug: { eq: $slug }) { title slug publishedAt tags } } ` In the example above, we are loading a blog article from the Contentful CMS by using its slug, which is passed to the GraphQL query at build time. For configuring what happens at build time, which is when the static generation takes place, we can use the file: gatsby-node.js const path = require("path"); exports.createPages = ({ graphql, actions }) => { const { createPage } = actions; return new Promise((resolve, reject) => { const postTemplate = path.resolve("src/templates/blogpost-template.js"); resolve( graphql( ` { allContentfulBlogPost { edges { node { title slug } } } } ` ).then(({ errors }) => { if (errors) { console.log(errors); reject(errors); } const posts = result.data.allContentfulBlogPost.edges; posts.forEach((post) => { createPage({ path: `/blog/${post.node.slug}/`, component: postTemplate, context: { slug: post.node.slug, }, }) }) }) ) }) } In the example above, we are loading blog posts using the Contentful GraphQL API and using the API to inject the slug of each blog post into an HTML-CSS-JS template which will use the slug to load the post details using the we saw earlier. createPage pageQuery Although Gatsby makes SSG very enjoyable to work with, the learning curve is somewhat steep as it requires developers to be reasonably competent at GraphQL. Nonetheless, even this latter hurdle can be overcome using the endpoint available in development mode; this includes a feature attached to , which makes query formulation much easier for those without GraphQL knowledge. /_graphql Code Exporter GraphiQL Note on SSG As much as SSG might seem like the answer to a lot of common web development problems, notably slow page load, powering a large-scale application with SSG alone may lead to inordinately long build times, potentially incurring a large cost. Techniques like Gatsby's can mitigate this by configuring certain pages to only be statically generated - and subsequently cached - at the time of the first user request. Deferred Static Generation Client-Side Rendering (CSR) Client-side rendering will be familiar to most React developers because it's the default for any project created with the widely used . create-react-app What CSR means is that the browser is responsible for creating the entire HTML document that users see. Although this can result in seemingly faster page transitions compared to SSR, it's not uncommon to see a flash of a blank page or interminable loading spinner animations while the browser puts together the required HTML. CSR in Next.js In Next.js, CSR is the default configuration. Just like in a typical SPA created through , you can use lifecycle hooks like to load data from a remote server. create-react-app useEffect Next's creator Vercel makes things even easier for us in this regard by providing the that deals with caching, periodic refetches, revalidations and more. useSWR hook CSR in Gatsby CSR in Gatsby can be implemented using . Since Gatsby ships with , developers can define routes in a way that will feel very familiar to anyone who has worked on a project created using . client-only routes @reach/router create-react-app Although CSR definitely has its place in Gatsby, it can seem like we're underutilizing Gatsby's rich functionality if we rely too heavily on this rendering mode. Note on CSR As the simplest one of the three rendering modes to learn, CSR is a good choice if speed is your primary business goal. That said, its convenience does come with obvious disadvantages. SEO will be severely impacted because search engine crawlers are not always capable of acquiring knowledge client-side rendered pages. Similarly, social media and external link sharing will be ineffectie since OpenGraph and Twitter cards can't pull metadata from applications using CSR. Summary This article compared the different ways Gatsby and Next.js approach data loading and rendering. We saw that both can used for server-side rendering, client-side rendering and static site generation, also known as server-side generation. Undoubtedly there is a place for each of these three rendering modes in web development, and we're lucky that in the modern era there are frameworks like these that make things easier than ever for us. Thanks for reading! Also Published Here
