Why I choose NextJS over CRA for new projects

I used to use Create React App (CRA) for building new applications (i.e. app.example.com). For landing pages, however, I would use NextJS for better SEO (i.e. www.example.com). Nowadays I will exclusively use NextJS over CRA when starting new applications for the following three reasons.

Reason 1: Monolith

When starting a new application, the main goal is to find product market fit. This means reducing distractions. With Create React App, we might need to build three different applications to test out our idea (Client App, Landing Page, API). With NextJS, we only need to build one app to test out our idea.

NextJS allows us to build our landing page, application, and API server all in a monolith. We can write backend routes that interact with a database inside of the api/ directory, server side render pages that is important to SEO, and also render things in the client side if necessary.

I want to build a monolith when kickstarting an app without compromising SEO. NextJS is the only tool that allows me to do that so that I can focus on solving problems for customers.

Reason 2: Performance

Google ranks websites with better performance higher in search results. Therefore some say only use NextJS when SEO matters...but it's hard for me to think of a reason why we would not want better performance and SEO regardless of the application. Why sacrifice on SEO when we don't have to? NextJS gives us the best of both worlds; we can decide when to server side render and when to client side render.

Reason 3: Ecosystem

By using NextJS, we expose ourselves to not only the React ecosystem but also the Vercel ecosystem. Vercel provides us with an easy way to deploy our NextJS application and take advantage of serverless. I am very excited to see Vercel build upon their edge functions to provide an end to end development platform for JavaScript engineers.

Conclusion

I reach for NextJS when starting any new application because it allows me to build a monolith using a mature framework to validate business ideas without sacrificing on performance.

Comments

[Gabi Mor]

Take a look at Remix, it looks very promising!

[martin rojas]

There is part of NextJS I don't get and honestly haven't really looked into it. If you are creating an API route. Is there a special way to query that API or is it still going to 'url/API/todo'

[Andrew Lee]

It's just like how it worlds with /pages. Give it a whirl!

npx create-next-app@latest

Then create folder /api at the root of the NextJS app.

my-app/
  api/
  pages/

Create a fileapi/hello.js

export default function handler(_req, res) {
  res.status(200).json({ messages: "Hello" });
}

Then we can access this API route when we make request to http://localhost:3000/api/hello

API Routes Introduction

[Andre Greeff]

this is one point that causes quite a bit of confusion, but these API routes are actually added inside the my-app/pages/ folder, not alongside it... as per the documentation you linked to:

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.

so basically:

my-app/
- pages/
- - index.tsx // URL "example.com"
- - about/
- - - index.tsx // URL "example.com/about"
- - api/
- - - index.tsx // URL "example.com/api"
- - - about/
- - - - index.tsx // URL "example.com/api/about"

---

disclaimer: I am still learning my way around Next.js myself, so I'm far from an expert on the topic, but this point has already caught me out a few times now..

perhaps it would've been more "logical" to have src/pages for reserved for "frontend" and src/api reserved for "backend"? ..and now suddenly I'm wondering if it might change to that one day.

[Andrew Lee]

Oh that was a mistake on my part. The docs do indicate that the api/ should be inside of pages/. I'm surprised that it still works even when it is outside of pages/. Thanks for clarifying.

[Andre Greeff]

hmm.. I really shouldn't be digging into this now (I'm at work, so I need to do work stuff), but......

after a little searching, I found an interesting part of the NextJS docs, which states:

Pages can also be added under src/pages as an alternative to the root pages directory.

The src directory is very common in many apps and Next.js supports it by default.

which goes on to list a caveat for this:

src/pages will be ignored if pages is present in the root directory

so after a quick chat with my friend Charlie (yes, the unicorn), we have a theory that perhaps there might be something similar with the API routes handling? maybe the pages/ parent folder path is "optional" due to some internal conditional checks and/or default fallbacks?? honestly not sure.

FWIW, I did see something in the configuration side about redirecting api/ URL requests to a custom folder in the project, not sure which tab that was in now though.

anyways, I need to get on with my day job now, so I'll go play with NextJS a bit more when I get home this evening. (:

[Mainak Das]

It's like the fs routing. If you've api/auth/register.js then url will be /api/auth/register. Then you've to check if the request is POST or GET or etc via conditional with req.method.

[leob]

The title suggests that one should always choose NextJS over CRA, for any project - is that what you mean to say? For sure there are scenarios where you have "app-like" (rather than "site-like") requirements, where NextJS doesn't make much sense?

Then, your point 2 says "Performance", suggesting that NextJS somehow "has better performance" (than a plain React app) ... can you expand on that?

[Andrew Lee]

Yes, I am claiming that for building new websites, I would always choose NextJS over CRA. NextJS already provides everything CRA does (client side rendering) but also gives me the option to server side render specific pages. Server side rendering provides better SEO/performance. Server side rendering allows users to see content faster (since it's already rendered), which Google rewards by placing it higher than purely client side rendered apps.

There may be scenarios where we want to render everything on the client side. In this case, it might be overkill to use NextJS if we are never going to use the additional features. However, even for apps where SEO is not important, there are often specific pages that we want good SEO.

One example I can think of where I would use CRA is if I'm building an Electron app. Electron apps mimic native applications where everything is rendered on the client side. The landing page for my Electron app might still be in NextJS, but I can see myself using CRA to kickstart an Electron app...since Electron apps by definition aren't websites and do not show up on search results.

[leob]

Fair enough! The only thing that confused me is when I thought that you suggested that NextJS somehow magically solves all performance problems ... if your React code is poorly designed or written, causing slow performance, then NextJS won't suddenly make it run fast, I think we'll agree on that.

[Viney Rawat]

That's actually really great to use NextJs over CRA as my experience.

[Andrew Baisden]

Both are great options 💜