Is Next.js Worth It?
This article hopes to touch on some of the high level points of why you would or wouldn’t use Next.js. Before going any further, we need to define what Next.js is.
- Marketing blurb from nextjs.org: Used by some of the world’s largest companies, Next.js enables you to create full-stack Web applications by extending the latest React features, and integrating powerful Rust-based JavaScript tooling for the fastest builds.
- Let’s see if ChatGPT does any better: Next.js is a popular open-source React framework for building server-side rendered (SSR) and statically generated (SSG) web applications. Next.js is widely used by developers to create fast, scalable, and SEO-friendly web applications.
- —To be honest, I have no idea what this means!
- —Much better!
Main Features
Sometimes it’s easier to know what something is by looking at the features it brings to the table.
- Server and client side rendering
- API Routes or Route Handlers for “serverless” APIs
- Site routing mainly based on folder names
- —Under the app & pages reserved folders
- Multiple data fetching options (server and client side)
- Optimizations for images, fonts and scripts built-in
- Your site can be hosted on vercel.com for free
Create React App vs. Create Next App
Next.js offers a “Create Next App” to bootstrap a new Next.js app.
- npx create-next-app@latest
Let’s compare it to “Create React App”.
Two Ways to do Routing
Like I mentioned before, there are two ways to do routing with Next.js:
- Prior to v13, there was only one way: pages (directory) routing
- Now, they recommend using the new way: app (directory) routing
Pages Routing
- Routes go under the “pages” folder by convention
- — Add routes based on file name and folder name
- — [id] means it’s a dynamic route, if the id were 15, the route would be /15
— Under the api folder are api routes you can call in your code to run on the server
— It’s important to understand where you are with Next.js – client or server
(The server code never makes it to the browser)
- — The component is still a client if it has one of the below, it just gets props from the server (except for client side fetching)
- — getStaticProps/getStaticPaths (static site generation)
• More for pages that don’t change much
— getServerSideProps (server-side rendering)
• If you want to render the page every time you visit it, use this
— Incremental Static Regeneration (use revalidate prop for getStaticProps)
• Use the revalidate prop to incrementally regen the page for getStaticProps
— Client-side fetching
(Normal React fetching using the api of choice (fetch/ky, etc.))
App Routing
- Routes go under the “app” folder by convention
- — Add routes based on folder name with “page.js” at leaf
— Add layouts (layout.js) or templates (template.js) at each folder level also
- Defaults to server component unless “use client” added to top
- — (demo) is a naming convention to say that the folder doesn’t count for routing
— For this example, we’d have the root page (/), then a /hello page and and /world page
— There is a layout.js at the root page level which all of the children will inherit
• You can add layout.js at any folder level
- Data fetching:
- — Extend “fetch” to give caching and revalidating (server components)
• Be default, data is cached indefinitely
• Can revalidate at a timed interval – fetch(‘https://…’, { next: { revalidate: 10 } });
• Can choose not to cache – fetch(‘https://…’, { cache: ‘no-store’ });
— They recommend using SWR or React Query for client components
My Experience
I created an application using Next.js (pages routing) because I wanted to try it out and find its strengths and weaknesses. It’s a simple bookmark application.
Quick observations:
- It works fine to use static generation until things get more dynamic
- — In my case, it stopped working when I added a new bookmark because it didn’t refresh the main page with the new bookmark properly (most likely, I was doing something wrong)
- I then moved to using server side rendering to solve the previous problem and that worked fine
- — However, once I got more dynamic and added tags to the bookmarks, it failed when you refreshed the page because the server side generated page didn’t match the page with a tag applied.
- I ended up using client side fetching because of the tags – it seems the more dynamic the app got, the more I was pushed to client side fetching
- I think there could be uses for static pages in my app. I think if I added a way to publish a set of curated bookmarks without tags to a page with a unique id, that would work fine
Conclusion
I like Next.js and the things it brings to the table. It’s a little difficult when you are starting to know if you are on the client or the server and what that means. But nothing you couldn’t get used to. I think it is also tough coming from a pure SPA programming mindset where all the data is fetched from an API and called from javascript. I would use Next.js given the right project and pages. But it is definitely something you need to discuss with your team before starting it to see if the benefits outweigh the challenges.
About Intertech
Intertech is a Software Development Consulting Firm that provides single and multiple turnkey software development teams and co-development resources, available on your schedule and configured to achieve success as defined by your requirements. Intertech teams combine proven full-stack, DevOps, Agile-experienced lead consultants with Delivery Management, User Experience, Software Development, and QA experts in Business Process Automation (BPA), Microservices, Client- and Server-Side Web Frameworks of multiple technologies, Custom Portal and Dashboard development, Cloud Integration and Migration (Azure and AWS), and so much more. Each Intertech employee leads with the soft skills necessary to explain complex concepts to stakeholders and team members alike and makes your business more efficient, your data more valuable, and your team better. In addition, Intertech is a trusted partner of more than 4000 satisfied customers and has a 99.70% “would recommend” rating.
