ReactJS

Next.js and React.js: 5 Differences to Help You Make Your Choice

Published Mar 1, 2022

Updated Feb 13, 2023

4 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

I should start by saying that I'm not a fulltime React.js or NextJS dev. My main technology is Angular, and I have been using it since I started coding in 2016.

But I am enthusiastic about how other frameworks and libraries work. So with that being said, I tried out some courses over the past few months, and this is why I prefer Next.js over React.js.

Automatic Code Splitting

Of course, you can perform this by lazy loading some components on React, but in NextJS it comes out of the box.

We just need to run npm run build, and the engine will create the proper files just to load those components.

➜ npm run build

> test-blog@0.1.0 build /Users/daianscuarissi/repos/test-blog
> next build

info  - Checking validity of types
info  - Creating an optimized production build
info  - Compiled successfully
info  - Collecting page data
info  - Generating static pages (3/3)
info  - Finalizing page optimization

Page                                       Size     First Load JS
┌ ○ /                                      5.56 kB        76.5 kB
├   └ css/149b18973e5508c7.css             655 B
├   /_app                                  0 B            70.9 kB
├ ○ /404                                   194 B          71.1 kB
└ λ /api/hello                             0 B            70.9 kB
+ First Load JS shared by all              70.9 kB
  ├ chunks/framework-e70c6273bfe3f237.js   42 kB
  ├ chunks/main-a054bbf31fb90f6a.js        27.6 kB
  ├ chunks/pages/_app-ca6aae25bc99a05f.js  491 B
  ├ chunks/webpack-69bfa6990bb9e155.js     769 B
  └ css/27d177a30947857b.css               194 B

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)

And is really cool because we don't need to add extra-code to make this happen. We don't need to configure anything else to deliver what the user needs to see that page. Awesome.

Image Optimization

The thing I love most about NextJS is Next/Image. If you ever work with images in web development, you probably know you need some configuration to lazy load the images. Well, simmilar when code-splitting in NextJS, you only need to use:

  import Image from 'next/image'

Some of the benefits that are mentioned in the documentation include:

Improved Performance
Visual Stability: Prevent Cumulative Layout Shift automatically
Faster Page Loads
Asset Flexibility

This sounds really awesome, but what about using it in a real project?

Another cool feature is you can use this for external or internal images. (If you are using external images, you need to configure the domains for each image. But it seems to be a good method for optimizing configuration.)

  import Image from 'next/image'

  export default function Home() {
    return (
      <>
        <h1>My Homepage</h1>
        <Image
          src="/me.png"
          alt="Picture of the author"
          width={500}
          height={500}
        />
        <p>Welcome to my homepage!</p>
      </>
    )
  }

BONUS:

Recently, I discovered that you can use the flag priority, and then NextJS will try to prioritize the image for loading (e.g. through preload tags or priority hints), leading to a meaningful boost in Largest Contentful Paint.

  import Image from 'next/image'

  export default function Home() {
    return (
      <>
        <h1>My Homepage</h1>
        <Image
          src="/me.png"
          alt="Picture of the author"
          width={500}
          height={500}
          priority
        />
        <p>Welcome to my homepage!</p>
      </>
    )
  }

Many ways to generate the site

NextJS can perform multiple server rendering strategies from a single project, which I was impressed with when I used it for the first time.

Static Generation (SSG)

Basically, using this approach, we render all pages at build time.

Every component can implement a method called getStaticProps() through which we can fetch data from a DDBB, and then return it as props to the component and use it there.

These can be mixed to serve your site through a CDN where it can be stored in cache. This works pretty well if you are building a blog, or just a static site, where the data doesn't change often.

  export async function getStaticProps() {
    const res = await fetch('https://...');
    const data = await res.json();

    return { props: { data } };
  }

Server-side Rendenring (SSR)

What if our data changes often? Well, in that case, you can use this approach, which builds the HTML page at request time every time it is requested by the user.

In the component, we can use the method getServerSideProps() and then pass as props to the component. So the difference with SSG is every time the user enters the page, the backend fetches the latest, and returns that to the page.

  export async function getServerSideProps() {
    const res = await fetch('https://...');
    const data = await res.json();

    return { props: { data } };
  }

Incremental Static Generation (ISG)

This feature allows the regeneration of static pages during runtime. It's a hybrid solution of SSR and SSR.

The page is generated on the first request. Unlike in SSR, where the visitor has to wait for the data fetching, a fallback page is served immediately.

During the fallback stage, we can present placeholders and a skeleton page until everything is resolved. Skeleton pages are a common pattern that you can see almost everywhere.

Once the data is resolved, the final page is cached, and visitors will receive the cached version immediately, just like with SSG. We can also set when Next.js should re-validate the page and update it.

  export async function getStaticProps() {
    const res = await fetch('https://...');
    const data = await res.json();

    return { props: { data }, revalidate: 60 };
  }

Routing

In other frameworks like Angular or React, we need to define the routes in order to serve certain files, components, etc. In Angular, these routes are defined in modules, and in React, we can use react-router.

But, again in NextJS, we have support for routes out of the box, we just need to create a file with extension .js, .jsx, .ts, .tsx under pages folder:

  next-app
  ├── node_modules
  ├── pages
  │   ├── index.js // path: base-url (/)
  │   ├── books.jsx // path: /books
  │   └── book.ts // path: /book
  ├── public
  ├── styles
  ├── .gitignore
  ├── package.json
  └── README.md

But what about dynamic or nested routes? Yes, these are supported, again, out of the box.

  pages/blog/[slug].js → /blog/:slug (/blog/hello-world)
  pages/[username]/settings.js → /:username/settings (/foo/settings)
  pages/post/[...all].js → /post/* (/post/2020/id/title)

API Routing

Another feature I really enjoy using was the API Routing.

Any file inside the folder pages/api is mapped to /api/, and will be treated as an API endpoint instead of a page. They are server-side only bundles, and won't increase your client-side bundle size.

For example, the following API route pages/api/user.js returns a json response with a status code of 200:

  export default function handler(req, res) {
    res.status(200).json({ name: 'John Doe' })
  }

And, if you already have an API, NextJS already can work with that. According to NextJS docs:

Masking the URL of an external service (e.g. /api/secret instead of https://company.com/secret-url)
Using Environment Variables on the server to securely access external services.

BONUS 🔥:

On-demand Incremental Static Regeneration (Beta)

This feature was recently included in the last update from the Vercel Team.

According to the team, we can now use a method called unstable_revalidate(), allowing developers to revalidate individual pages that use getStaticProps.

  // pages/api/revalidate.js
  export default async function handler(req, res) {
    // Check for secret to confirm this is a valid request
    if (req.query.secret !== process.env.MY_SECRET_TOKEN) {
      return res.status(401).json({ message: 'Invalid token' })
    }

    try {
      await res.unstable_revalidate('/path-to-revalidate')
      return res.json({ revalidated: true })
    } catch (err) {
      // If there was an error, Next.js will continue
      // to show the last successfully generated page
      return res.status(500).send('Error revalidating')
    }
  }

This makes it easier to update your site when:

Content from your headless CMS is created or updated
Ecommerce metadata changes (price, description, category, reviews, etc.)

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Daian Scuarissi
@asdaian @SDaian

How to build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

In today’s blog post, we’ll build an AI Assistant using three different AI models: Whisper and TTS from OpenAI and Llama 3.1 from Meta. While exploring AI, I wanted to try different things and create an AI assistant that works by voice. This curiosity led me to combine OpenAI’s Whisper and TTS models with Meta’s Llama 3.1 to build a voice-activated assistant. Here’s how these models will work together: * First, we’ll send our audio to the Whisper model, which will convert it from speech to text. * Next, we’ll pass that text to the Llama 3.1 model. Llama will understand the text and generate a response. * Finally, we’ll take Llama’s response and send it to the TTS model, turning the text back into speech. We’ll then stream that audio back to the client. Let’s dive in and start building this excellent AI Assistant! Getting started We will use different tools to build our assistant. To build our client side, we will use Next.js. However, you could choose whichever framework you prefer. To use our OpenAI models, we will use their TypeScript / JavaScript SDK. To use this API, we require the following environmental variable: OPENAI_API_KEY— To get this key, we need to log in to the OpenAI dashboard and find the API keys section. Here, we can generate a new key. Awesome. Now, to use our Llama 3.1 model, we will use Ollama and the Vercel AI SDK, utilizing a provider called ollama-ai-provider. Ollama will allow us to download our preferred model (we could even use a different one, like Phi) and run it locally. The Vercel SDK will facilitate its use in our Next.js project. To use Ollama, we just need to download it and choose our preferred model. For this blog post, we are going to select Llama 3.1. After installing Ollama, we can verify if it is working by opening our terminal and writing the following command: Notice that I wrote “llama3.1” because that’s my chosen model, but you should use the one you downloaded. Kicking things off It's time to kick things off by setting up our Next.js app. Let's start with this command: ` After running the command, you’ll see a few prompts to set the app's details. Let's go step by step: * Name your app. * Enable app router. The other steps are optional and entirely up to you. In my case, I also chose to use TypeScript and Tailwind CSS. Now that’s done, let’s go into our project and install the dependencies that we need to run our models: ` Building our client logic Now, our goal is to record our voice, send it to the backend, and then receive a voice response from it. To record our audio, we need to use client-side functions, which means we need to use client components. In our case, we don’t want to transform our whole page to use client capabilities and have the whole tree in the client bundle; instead, we would prefer to use Server components and import our client components to progressively enhance our application. So, let’s create a separate component that will handle the client-side logic. Inside our app folder, let's create a components folder, and here, we will be creating our component: ` Let’s go ahead and initialize our component. I went ahead and added a button with some styles in it: ` And then import it into our Page Server component: ` Now, if we run our app, we should see the following: Awesome! Now, our button doesn’t do anything, but our goal is to record our audio and send it to someplace; for that, let us create a hook that will contain our logic: ` We will use two APIs to record our voice: navigator and MediaRecorder. The navigator API will give us information about the user’s media devices like the user media audio, and the MediaRecorder will help us record the audio from it. This is how they’re going to play out together: ` Let’s explain this code step by step. First, we create two new states. The first one is for keeping track of when we are recording, and the second one stores the instance of our MediaRecorder. ` Then, we’ll create our first method, startRecording. Here, we are going to have the logic to start recording our audio. We first check if the user has media devices available thanks to the navigator API that gives us information about the browser environment of our user: If we don’t have media devices to record our audio, we just return. If they do, then let us create a stream using their audio media device. ` Finally, we go ahead and create an instance of a MediaRecorder to record this audio: ` Then we need a method to stop our recording, which will be our stopRecording. Here, we will just stop our recording in case a media recorder exists. ` We are recording our audio, but we are not storing it anywhere. Let’s add a new useEffect and ref to accomplish this. We would need a new ref, and this is where our chunks of audio data will be stored. ` In our useEffect we are going to do two main things: store those chunks in our ref, and when it stops, we are going to create a new Blob of type audio/mp3: ` It is time to wire this hook with our AudioRecorder component: ` Let’s go to the other side of the coin, the backend! Setting up our Server side We want to use our models on the server to keep things safe and run faster. Let’s create a new route and add a handler for it using route handlers from Next.js. In our App folder, let’s make an “Api” folder with the following route in it: We want to use our models on the server to keep things safe and run faster. Let’s create a new route and add a handler for it using route handlers from Next.js. In our App folder, let’s make an “Api” folder with the following route in it: ` Our route is called ‘chat’. In the route.ts file, we’ll set up our handler. Let’s start by setting up our OpenAI SDK. ` In this route, we’ll send the audio from the front end as a base64 string. Then, we’ll receive it and turn it into a Buffer object. ` It’s time to use our first model. We want to turn this audio into text and use OpenAI’s Whisper Speech-To-Text model. Whisper needs an audio file to create the text. Since we have a Buffer instead of a file, we’ll use their ‘toFile’ method to convert our audio Buffer into an audio file like this: ` Notice that we specified “mp3”. This is one of the many extensions that the Whisper model can use. You can see the full list of supported extensions here: https://platform.openai.com/docs/api-reference/audio/createTranscription#audio-createtranscription-file Now that our file is ready, let’s pass it to Whisper! Using our OpenAI instance, this is how we will invoke our model: ` That’s it! Now, we can move on to the next step: using Llama 3.1 to interpret this text and give us an answer. We’ll use two methods for this. First, we’ll use ‘ollama’ from the ‘ollama-ai-provider’ package, which lets us use this model with our locally running Ollama. Then, we’ll use ‘generateText’ from the Vercel AI SDK to generate the text. Side note: To make our Ollama run locally, we need to write the following command in the terminal: ` ` Finally, we have our last model: TTS from OpenAI. We want to reply to our user with audio, so this model will be really helpful. It will turn our text into speech: ` The TTS model will turn our response into an audio file. We want to stream this audio back to the user like this: ` And that’s all the whole backend code! Now, back to the frontend to finish wiring everything up. Putting It All Together In our useRecordVoice.tsx hook, let's create a new method that will call our API endpoint. This method will also take the response back and play to the user the audio that we are streaming from the backend. ` Great! Now that we’re getting our streamed response, we need to handle it and play the audio back to the user. We’ll use the AudioContext API for this. This API allows us to store the audio, decode it and play it to the user once it’s ready: ` And that's it! Now the user should hear the audio response on their device. To wrap things up, let's make our app a bit nicer by adding a little loading indicator: ` Conclusion In this blog post, we saw how combining multiple AI models can help us achieve our goals. We learned to run AI models like Llama 3.1 locally and use them in our Next.js app. We also discovered how to send audio to these models and stream back a response, playing the audio back to the user. This is just one of many ways you can use AI—the possibilities are endless. AI models are amazing tools that let us create things that were once hard to achieve with such quality. Thanks for reading; now, it’s your turn to build something amazing with AI! You can find the complete demo on GitHub: AI Assistant with Whisper TTS and Ollama using Next.js...

Sep 27, 2024

8 mins

AINextJSJavaScript

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

Danny Thompson, Director of Technology at This Dot Labs, talks with Tanner Linsley, Creator of TanStack, about his latest project, TanStack Start. They discuss the challenges of existing frameworks like Next.js and Remix, the development of TanStack Router, and the future of React Server Components. Tanner also explains how caching strategies and fine-grained invalidation can transform the user experience. Chapters - - Introduction & Tanner’s Background (00:00) - Going Full-Time on TanStack (01:00) - The Birth of TanStack Router (02:21) - Why Build Another Framework? (04:00) - React Server Components: Potential & Limitations (07:05) - Fine-Grained Cache Invalidation & UX (09:02) - Parallel Data Fetching in Routing (13:39) - TanStack Start: Alpha & Future Plans (16:41) - Where to Learn More About TanStack (18:48) Find Tanner Linsley on Social Media Twitter: https://x.com/tannerlinsley Linkedin: https://www.linkedin.com/in/tannerlinsley/ Github: https://github.com/tannerlinsley TanStack: https://tanstack.com/ Sponsored by Wix Studio...

Oct 9, 2024

1 min

TanStack QueryJavaScriptReact

Understanding Next.js Data Fetching for Beginners

When I started to learn Next.Js, I felt a little bit lost with some abbreviations they use to make the data fetching. All of them look pretty simmilar, but they have different meanings. If you feel the same, you are not alone. Let's discover what CSR, SSR, SSG, and ISR means, and how we can use them. It is quite confusing because I, as an Angular developer, only knew one strategy to fetch the data:HttpClient. But for example, if you are more familiar with React, you probably use a different strategy: useEffect. So, let's get started. Vercel's Next.js framework has four different data fetching options despite being known as a server-side render framework: - CSR - Client-Side Rendering is a common data fetching method using useEffect. It will fetch the data from the API every single page request on the client-side (after the page is rendered, then the function will run). - SSR - Server-Side Rendering will run a special function to fetch data from the API with every page request on the server-side (before the page is loaded, that special function will run first, creating a delay, then after that, it will serve the page). - SSG - Static Site Generation will run a special function to fetch data once when that page builds. - ISR – Incremental Static Regeneration offers a new method. Shortly put, it is a combination of SSG, and SSR, where it served statically, but at a certain time and certain condition, that page will rebuild and fetch the data from the API again. Don't worry if you don't understand any of the concepts. I will explain a little bit further shortly. CSR (Client-Side Rendering) This is a basic example of how you can use Client-Side Rendering. I'm using the well known useEffect method from React. ` You can see how it works on Stackblitz. We can highlight 2 things here: - The useEffect method to make the retrieve of the name every time the page loads. - A loading indicator, this is used to wait for the fetching data, because the data is fetched after the page is rendered. SSR (Server-Side Rendering) Just to keep in mind, when you are using Server-Side rendering, and using the method getServerSideProps(), Next.js will pre-render this page on each request using the data returned by getServerSideProps. ` You can see how it works: Stackblitz We had 3 highlights here: - Method getServerSideProps(), is a function indicating that a page is using Server-Side Rendering. - We had a delay before render, and NO loading indicator. The data is fetched before the page is rendered, so that's why we can see a little delay. - Data is fetched on every request, that's why every time we reload the page, is showing a different dad joke. SSG (Static Site Generator) If we take a look at the code below, we will see that it is pretty similar to the SSR code, but the difference here is the getStaticProps method. This method will only fetch when the app is building. ` The highlights here are: - getStaticProps is a method indicating that the page is using Static Site Generation. - Data will be fetched only when you run yarn build. The API will be hit only when the app is building. - Data will NOT change because there is no further fetch. You can see how it works: Stackblitz ISR (Incremental Static Regeneration) This strategy works pretty simmilar like SSG, but here we need to add a revalidate prop to our main getStaticProps function. ` There are a few keys to highlight here: - When you set the revalidate prop to certain amount of time (in our example we set it to 20), reloading doesn't trigger changes. The page will remain in a cooldown state. - Is the page rebuilt every 20 seconds then? No. When the cooldown state is off, if no one visits the page, it will not rebuild even after the 20s pass. But the first person who enters the page when the cooldown state is off will trigger a rebuild. However, that person will not see those changes. But the changes will be applied to the next full reload. You can see how it works: Stackblitz Conclusion Understand how these abbreviations work, and how we can use it in a Next.js app will help us develop more robust solutions, and use Next.js' full potential. I know these terms can sound overwhelming and difficult to understand, but with a little bit of practicing, we can see in action in a few steps. In future blog posts, we will see the best approach to identify and choose between them....

May 9, 2022

4 mins

NextJSJavaScriptReact

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau

In this episode of the Modern Web Podcast, Danny Thompson sits down with Ferdinand Como and Baptiste Leproux from Nuxt Labs to uncover the story behind Nuxt Studio, a tool that's transforming how developers and non-technical users interact with Nuxt applications. Ferdinand and Baptiste share how Nuxt Studio bridges the gap between developer customization and user-friendly content management. Built to empower agencies, freelancers, and their clients, Nuxt Studio combines powerful features like live previews, Vue component integration, and schema-driven forms to make managing content seamless. The conversation also explores the broader mission of Nuxt Labs—building sustainable open-source tools that enhance developer experience and meet real-world needs. With insights into the future of Nuxt Studio and its potential to scale for larger organizations, this episode is a must-listen for anyone passionate about innovation in web development. Chapters 1. Introduction and Setting the Stage (00:00:00) 2. The Vision Behind Nuxt Studio (00:03:10) 3. Nuxt Studio’s Core Features (00:08:45) 4. Challenges in Building Nuxt Studio (00:16:20) 5. Target Audience and Use Cases (00:22:35) 6. Sustainability in Open Source (00:29:00) 7. The Future of Nuxt Studio (00:35:10) 8. Nuxt Studio’s Role in the Nuxt Ecosystem (00:42:30) 9. Closing Thoughts and What’s Next (00:48:00) 10. Sponsor Shoutout and Wrap-Up (00:53:20) Follow Baptiste Leproux and Ferdinand Coumau Baptiste Twitter: https://x.com/_larbish Ferdinand Twitter: https://x.com/CoumauFerdinand Baptiste Linkedin: https://www.linkedin.com/in/baptiste-leproux-618842b0/ Ferdinand Linkedin: https://www.linkedin.com/in/ferdinand-coumau-nuxt/ Sponsored by This Dot: thisdot.co...

Nov 20, 2024

2 mins

VueNuxtJS

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Next.js and React.js: 5 Differences to Help You Make Your Choice

Automatic Code Splitting

Image Optimization

Many ways to generate the site

Routing

API Routing

On-demand Incremental Static Regeneration (Beta)

Daian Scuarissi

You might also like

How to build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

Understanding Next.js Data Fetching for Beginners

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau

Let's innovate together!

You might also like

How to build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

Understanding Next.js Data Fetching for Beginners

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau