In web app development, technologies come and go like the winds. Sometimes a popular technology falls by the wayside in a matter of months. Occasionally a newcomer to the field swiftly picks up market share until it's the dominant force on the market. With tech churn continually cycling the field, it can be challenging to understand which framework to pick for your next project.
One of the primary limitations of React is that it's solely focused on front-end UI creation, passing state to DOMs, and rendering UIs. As such, it's only one part of a total development environment and can't be used on its own for most use cases.
Next.js is a framework meant to work with React. It's an iteration of Node.js and is intended for server-side rendering (SSR) and generating static websites. Like React, it is open source, maintained by Vercel (formerly ZEIT).
The primary use case for Next.js is to enable a React-based site to render content on the server-side rather than solely on the client-side.
Create-React-App is a single boilerplate framework built out of various dev tools. The list of tools includes (but is not limited to) webpack, Babel, ESLint, and more. CRA is designed to be a single dev environment packaging a variety of tools while ensuring that they all work seamlessly together, are updated as one whole package, and reduce pain points and development friction to the barest minimum.
Like React, Meta maintains Create-React-App as part of Facebook Open Source. In other words, the goal is to streamline the ability to create a React app. After all, a developer should be working with code, not troubleshooting their framework.
There are quite a few differences between these frameworks, though both are built upon working with React at their core.
For those who care, Create-React-App is maintained by the Facebook Open Source movement, while Next.js is not. Next.js is created, copyrighted, and maintained by Vercel. React is also supported by Facebook Open Source, so both React and Create-React-App are generally going to be maintained at the same rate, while Next.js has the potential to fall out of sync occasionally.
That said, having Facebook Open Source maintain CRA is generally a good thing. It ensures that everything is kept up to date, functional, and fixed whenever an issue arises. In contrast, putting together your environment means you're often forced to handle updates and troubleshooting yourself.
In development, you can do rendering on the client-side or the server-side. Both methods have advantages and disadvantages.
The server-side rendering parses data from various sources, produces and renders a page, and sends the result to the user. In client-side rendering, the server hosts the directives and sends them out, where the client's device does rendering work.
Essentially, SSR is suitable for single pages, static pages, and instances where the page only loads once or sporadically. CSR may take longer for the initial load but saves time and resources in subsequent page loads and interactions.
To see a test of these two in action and which one provides better results, check out this experiment from LogRocket.
Create-React-App is, by default, solely a client-side framework. Next.js allows for both client-side and server-side rendering.
One of the foremost reasons to use Create-React-App is the simplicity of the development environment.
In some ways, you can liken it to macOS versus Linux/Unix. macOS "Just Works," with a relative minimum of fiddling around with operating system settings getting between you and the programs you want to use. Conversely, using a Linux distribution often requires more manual configuration, component upgrading, driver selection, and other tweaks and fiddling.
With CRA, you're given a set of tools and an environment to work with. They work the way they work, and you can work with them as they are.
With Next.js, you are given one framework and can use other tools with it as you see fit, but you may need to do more manual updating, troubleshooting, and bug fixing between tools.
This simplicity in CRA benefits those who want a simple tool that works when needed and doesn't break when it updates. However, if you're going to do configuration or tweaks to profiles in one of the tools provided by CRA, you aren't able to. Instead, you have two options.
The first option is to Eject your app. Ejecting breaks your project out from the Create-React-App framework; you can change configurations, add or remove tools, and generally customize everything yourself. However, you are then responsible for maintaining all of those components. Since component maintenance is the primary reason to use CRA in the first place, this is a huge downside.
The other option is to use a third-party tool like Craco. Craco is the Create React App Configuration Override. It is, essentially, a third-party recreation of the configuration options provided by the tools in CRA, allowing you to simulate changing them without having to eject your project.
There's nothing essentially wrong with using a third-party tool. However, given that one of the main benefits of CRA is that everything is packaged and maintained in one lump, adding another confounding factor that can fall out of sync can be a difficult hurdle to overcome.
React as a core library is not opinionated. Next.js, however, does include some opinionated decisions in its design.
These decisions are primarily focused on server-side routing, which is critical to ensure that you can develop a server-side app made with Next.js in a minimum amount of time.
By contract, CRA is very opinionated. They have picked the components they want to work with, and while you can use external resources with it, they don't make it as easy to manage.
In and of itself, being opinionated is not a bad thing. It is, put simply, the creators of the framework making decisions on how best to implement certain features, rather than presenting all of the options to you and letting you make a choice. If the developers' choices are in line with your needs, they facilitate development and make your life a lot easier. On the other hand, if you want a different path, you have to do more work to make it function.
One of the primary benefits of using Next.js is using APIs.
When you want to create an application that uses APIs from a third-party source, your app typically needs an API of its own. This step can be challenging to do with CRA out of the box, but Next.js is designed to allow you to set up APIs with a tiny amount of effort.
This is not to say that Create-React-App is old-fashioned or out of date. It still receives ongoing updates, and as standards change, the criteria for CRA will likely change as well. However, given that it's tied to a larger organization and requires more comprehensive testing and iteration each time an update is pushed, it's safe to say that CRA is more conservative. It will likely always be more limited than Next.JS and may firmly take a role as a beginner's tool, whereas Next.js is more robust and flexible but requires more understanding to leverage correctly.
Of course, how this will shake out in the coming years remains to be seen.
The million-dollar question is always right ahead of us. Which of these two frameworks should you choose?
In reality, you're never limited to just these two options. You have two additional options as well. The first is to pick a different framework, like Ember, Hexo, Angular, or Hugo. The second is to build your operating environment using individual modules rather than a framework developed by someone else.
In general, we don't recommend that latter option. The overhead is too high and the benefits too low; you can customize a framework more quickly than you can build your own out of whole cloth, with very little difference in your outcomes.
As for the other alternative frameworks, suffice it to say that they exist, and you can research them if you wish. Discussing them in detail is outside the scope of this post.
In the end, the choice between Create-React-App and Next.js comes down to a few critical decisions and scenarios.
If your planned app or web platform needs to be fast-loading for SEO, go with Next.js.
Being able to seamlessly and efficiently use server-side rendering – even if it's a little opinionated – is much better than trying to build an organic SEO presence using client-side rendering.
If your app is gated with authentication, Create-React-App can be a better choice.
In some instances, client-side rendering can be a security risk, which is why many apps with data handling use mostly server-side rendering. However, if you're gating your app behind authentication, you already have a wall to keep out many malicious actors, and client-side rendering can be effective. However, this heavily depends on your scenario, and you should talk to a cybersecurity specialist before making the decision.
If you need more configuration customization or used modules, go with Next.js.
Create-React-App is fine if you're willing to work within their structure, but if you want to step outside the bounds of what they have tested and refined, you'll encounter a lot of trouble and may even need to Eject. This eliminates most of the benefits of using CRA in the first place, making Next.js the better choice.
If you're trying to learn an environment without learning dozens of modules and configurations, go with Create-React-App. At its core, Create-React-App is a compelling framework for learning React.
It's a gateway to a bottomless well of knowledge. It can be excellent for small apps and pages, but eventually, its restrictions will chafe, and you'll want to move beyond it.
The truth is, Create-React-App and Next.js aren't truly comparable. CRA is primarily suitable for scaffolding apps and learning how React works and interacts with various modules and libraries. Meanwhile, Next.js is made to be the next generation of powerful dev tools and is great for businesses and eCommerce applications.
If you'd like to speak to somebody about how to best build your app with things like scalability and future-proofing in mind, we'd love to hear about your project. You can get in touch with us by sending us a message on our contact page or giving us a call. We'd love to hear from you.
Finding the “just-right” in data visualization Data visualization is everywhere. From analytics platforms to infographics, across newsrooms and social media channels, there are va…
You have a brilliant idea for a new web-based software-as-a-service product. You're all set to go. Well, there's just one problem: you need to make it. The hard part is coming up w…