Next.js Is Always The Right Tool For The Job
In software, there exists a concept called “choosing the right tool for the job”. The implication is that when choosing a tool, there are ones better suited for a task than others. Sometimes there are trade-offs, but— after investigation—you can still tell which choice is best for you.
Sometimes the choice is difficult. Perhaps you haven’t worked in a space long enough to contextualize a decision. Perhaps you feel some choices aren’t available to you because of a perceived obstacle. For example, you may believe creating a native iOS app for some new idea is best, but you need to get the idea out as quickly as possible so you choose React Native.
Rarely - but sometimes - the choice is easy.
When it comes time to creating your next React app or updating an existing one, I’m here to tell you that Next.js should be your choice, regardless of what you’re building. I’ll outline my explanation later, but first…
- You will need to use Vercel or roll your own continuous deployment with the Serverless Framework Next.js plug-in. It’s a lot more involved than simply hosting static files and — if for some reason Vercel isn’t an option — then you’ve got a small initial hill to climb.
- There are a few Next.js specific things you need to learn. It’s a framework so there is some rigidness, but it’s on purpose.
- There’s no 1st-class way to build native apps. The closest you can get is by making a progressive web app (PWA) or using Nextron.
Assuming you’re willing to learn, are able to use Vercel, and are simply making a website/app/hybrid… there are no downsides.
The Major Wins
- The ability to choose your rendering strategy on a per-page basis. No more converting or changing tooling or setting up a haphazard micro front end because you need SEO or server-side rendering. Even if you believe you only have client-side rendered plans, Next.js can handle that now and be ready for any change of plans.
- You get lots of tooling without configuration. Don’t get stalled on setting up your application. Going with Next.js means out-of-the-box setup available for TypeScript, ESLint, Internationalization, lambdas, many CSS tools, automatic route-based code-splitting, and image optimization.
- You will work in a prime developer experience environment. You’ll notice obvious niceties like high quality documentation, but you’ll come to love the examples folder in their repository. You’ll notice the framework-specific ESLint rules, but the custom dev server errors are the real coup.
- Opt-in to flexibility. Next.js doesn’t care about how you fetch data, unlike Gatsby which requires GraphQL or CRA which requires client-side fetching. You can even leverage React Router if you just want to dip your toes into some technology but still have a familiar router.
- Choosing a tool that the React and Chrome teams are partnering with! Get first access to new features and make a step forward knowing you’re making a choice that these teams are backing.
The Right Tool?
I can think of only two exceptions to Next.js always being the right tool for the job. Firstly, if building a WebAssembly application and the time wasted loading React is deemed unacceptable. Lastly, if you are absolutely certain that you are building a simple (five or fewer pages), static application where performance is the top concern. I cannot find a link to back my claim; however, I believe that a Next.js static export devoid of React may be possible in the future. In that future, I can think of no exceptions to always using Next.js. If you think you’ve got an edge case or are still unsure, feel free tweet at me! At worst, I believe that you’re choosing a tool to abstract other tools away. As a bonus, you’re being prepared for the future in many ways. All of this is important because it lets you spend less time on less important aspects of web development. Good luck!