When starting a React project in modern times, you will have an overwhelming amount of React starter kits and frameworks to choose from. We hope this guide will help make this decision easier for you.
What type of app are you building?
Ultimately what type of React technology you choose boils down to what type of app you want to build.
Most apps can be put into one of two categories: Client-side Rendered (CSR) and Server-side Rendered (SSR). As we explain the differences below, think about whether your app falls into CSR or SSR.
Client-side rendered apps
A client-side rendered app is also known as a classic SPA (single page app). The browser is the client, and is in charge of retrieving data from the server, managing it inside the browser, and eventually syncing back to the server. Examples might include apps like Jira, Gmail, Evernote, essentially anything involving you (the browser operator) working in a dynamic environment. If I remove a Gmail tag, all my emails should not be tagged anymore. If I archive a Jira project, perhaps I can no longer see tasks for that project.
Sure, the server is ultimately responsible for archiving that project data. But if you perform that action in your client-rendered app, the client has work to do. It has to somehow figure out how to update itself for the new state. That could mean refetching the data and re-rendering.
This is where React dominates. Combined with libraries like React Router and Redux, you're able to maintain a large application right in the browser, only making server calls as needed. You can manage huge JavaScript objects, pass them around heirarchies of components in different places in the app, and manipulate them all at once.
Typical ways to build a CSR include the classic create-react-app (now not recommended) and the more modern Vite. We'll demo how to build a Vite app next.
There's one problem with this React ecosystem that's been mentioned time and again- most sites don't need all this complexity. That's where one might return to a server-rendered app.
Server-side rendered apps
Prior to SPAs, servers just returned pre-rendered HTML pages. This approach has one advantage that can't be matched by SPAs: Speed. Bots crawling sites that have pre-rendered paths can instantly index content to show on search engines. By having a fast site, you have good SEO.
Writing HTML is tedious, so what if you could still write React code and have it render on the server, prior to users accessing your site? That's where SSR (server-side rendering) comes into play. SSG (static site generation) is a form of SSR where you build you entire site at once, and render all the content you need into HTML pages at build time. Examples might include blogs, news, eccommerce, and any marketing site where the content needs to be accessed quickly by a large audience. Content may not change that often, so its beneficial to cache the rendered HTML.
Frameworks like Next.js and Gatsby are built to do just this. Next.js can actually vary the strategy of SSR, SSG and even client-side rendering on a per route basis!
So should I use Next.js? Do I need SSR / SSG?
If your app has a lot of client-side JavaScript to manage app state and no need to appear in search engine results, Next.js might not be a good fit. For this type of app, you're better off using a minimal React starter (like Vite) that queries your server API. If, however, you are building a blog, restaurant, or other app that will see a lot of traffic- you should definitely opt to go with Next.js and implement SSR. We'll also demo that in this module.
Do I need Redux?
If your app has many models rendering inside the browser that can change with dynamic user input, and updates are hard to reason about, Redux can help simplify global state management in your app. Redux can be inserted into a Next.js app, but the setup is tricky. If you think you need Redux because you have complicated global state, you may want to not focus on SSR and just start with a Vite app and later move to Next.js if you want to also add SSR. If you don't need global state that multiple components need to share data from, don't use Redux.
What if I want a hybrid SPA with an SSR?
While Next.js can handle a hybrid SPA with SSR, in some cases you might be better off just having two separate apps. Blog platforms, for example typically have the main blog (SSR content) and a CMS (content management system, an SPA). While it might sound difficult to manage two separate apps, its probably a good separation of concerns- a blog doesn't need a redux SPA anymore than a content managing system needs to be viewed by search engines. Obviously, there are exceptions- a blog could have a user login system which would effectively wrap the SSR content with a state manager for the user. If you think you need a hybrid of both strategies, go with Next.js and you will surely find a way forward.
Just start building!
We intentionally are limiting the options we are recommending because at the end of the day, you should be building your app, not deciding between technologies. Next.js and Vite are both extremely popular and well documented solutions to starting your React app. Don't worry about picking a starter that has a ton of technology packed in, you can always add React libraries in later as you need them.
We hope this lesson helped you identify what type of react starter you should use to build your project. Continue onto the next lesson for more walkthroughs of building each type of app!