When building something you’ll often be put in a position where you have a couple, or more, options that can be justified to be used for the application you’ll be building. Getting to this point is probably the most difficult part for any non seasoned senior+ engineer. There is no “wrong” answer, and each can be justified depending on preferences. So what do you do?
Luckily, I have a handy 3 step process that should expedite that decision making for you. To highlight it, we’ll be looking at a common occurance in the React world today. React vs. Next.Js!
React And Next.JS
In the React world, most projects today face an initial framework decision at the beginning. Deciding between traditional client-side React application and using an SSR solution, most notably something along the lines of Next.JS. The difficulty here is that “technically” there isn’t a wrong answer. In turn, that’s what makes it difficult. Both are great approaches in building web applications, just with different approaches. That’s where are 3 step process comes into play. Let’s get moving into it!
Step 1: Understand The Differences
Before making any decisions, we need to make sure we fully understand what we’re deciding between. React, in the traditional sense, is 100% client-side. The user’s browser is responsible for the loading of all JS and rendering post-loading of files. In Next.JS, there are two separate loading and rendering cycles happening. Server side and client.
Starting with the server, loading here acts in a traditional application. Page rendering happens on the server, converting the baseline React code to HTML, and the server has the ability to pass values to the FE if needed. From there, client-side loading takes effect. This is where hooks, API calls, and logic requiring some loading on the client are handled.
Step 2: Knowing What You Need To Build
After understanding how they both work, it’s time to get back to your perspective application. The first thing needed there is to take a look at what you’re building. In short, the type of application you’ll be building, and the use cases needed to support it, should be the driving factors in your decision. For example, let’s say your application is meant to be used by users in areas with slow and intermittent internet connections. A server-rendered application wouldn’t be the most ideal solution.
On the flip side, let’s say you need to build an application where that isn’t an issue. The most important aspect is optimal load times. Well, with that, the best option will be a traditional server-side rendered application.
Step 3: Make Your Decision
Decision time! After working through the first two steps, this should be the easiest part. In fact, thnink of this as just formalizing a polished summary. You’ve taken time to understand core benefits of your options, put into perspective what the main type of performance your application will need, and now it’s time to just utilize that information.
In the case of our scnerio, we made compelling cases highlighting when each would be neccessary. For traditional React, in circumstances where we don’t want to rely on server refreshes to produce new page loads, this is our choice. In other instances, where we need to rely on the power of the server to process things faster and prior to the page is loaded browser side, then Next.JS is the best option. Simple as 1-2-3!