Why I Migrated From Next.js to Create React App
Note: If you are looking to convert a Next.js application to React.js, check out my other article on how to convert Next.js to React.js.
Let me start by saying I’m a big fan of Next.js. It’s an amazing framework for building React applications, especially when you need Server-Side Rendering (SSR). One day, I’ll write an article covering all the great things about this framework, but luckily a lot of people are already doing that.
Instead, I’m now going to explain why I migrated one of my many side projects from Next.js to Create React App. Note: If you don’t care about the background story, scroll down and go straight to the conclusion.
Start Free
When you have many side projects (that don’t make you any money), it’s nice if you can host them for free. I have a Ruby on Rails project hosted on a custom domain on Heroku that’s already costing me more than 30 dollars a month, which is fine — if you have just one project or if that project is making you some money… The cool thing about building a React application with Firebase and Firestore is that you can build a full-stack application and go live without any costs (except for the custom domain name). I did that with side projects like FlowReads and MakerMove. I also made React Milkshake, a boilerplate for creating apps with this stack. For a new side project, I was going for that same approach but with Nextjs, and although that’s working nicely, there was one issue I ran into.
Deploying on Vercel
The best place to deploy your Nextjs application is Vercel (formerly Zeit). Although you can start for free, I had to upgrade to the team plan (starting at 20 dollars a month) if I wanted to keep my current project live. With Next.js, you can choose whether you want your pages to be statically generated or server-rendered. If your page is server-rendered, it means that a serverless function is created for your page during the build. The team at Zeit just decided to limit the number of serverless functions to 12 — and my application had 14 pages. That meant I could no longer deploy this application — it would fail during the build process due to this limitation. I can understand the decision to limit the number of serverless functions on the free tier, but the most frustrating part of this is that my site was already deployed. After Zeit has added this limitation I couldn’t deploy any changes without upgrading! You might be thinking “But why are you server rendering every single page? Couldn’t you just statically serve at least a couple of pages?” That’s what Zeit also recommended and it’s exactly what I wanted. The only problem is that with my current implementation (using Redux), I can’t. Let me explain.
SSR vs SSG
With Next.js you can use getIntialProps (or since version 9.3 getServerSideProps and getStaticProps) inside your page components, which determines if a page should be server-rendered of statically generated (read more about that here). If you don't need any data inside your page it will be statically generated, but when you use getInitialProps inside _app.js all your pages are server-rendered. You will get this warning message when building your application: "You have opted-out of Automatic Static Optimization due to getInitialProps in pages/_app." Now, when you use Redux as your state management library, you probably use next-redux-wrapper, so you don't have to implement anything complex to make your client state of the store in sync with the server, etc. At least, that’s what I did, and here’s the problem: This library calls getInitialProps on your _app.js file, so all your pages will implement server-side rendering. To be honest, my application didn’t need server rendering, because everything is behind a login screen. I basically only used Next.js because I wanted to experiment with it. I probably had more options than to just refactor my project to CRA, but I figured the hassle that can come from server-side rendering (even with Next.js) is not worth the time for a project that doesn’t even benefit from it that much. I also like to host things for free as long as I’m still in the development phase and with Next.js I’m not sure I can.
Conclusion
If you use redux inside your Nextjs application (with next-redux-wrapper) and have more than 12 routes, you will need to upgrade to the team plan if you host your project on Zeit. If you don’t need SSR, are using redux, and also want to host it for free, you probably don’t want to go with Next.js. Also, if you want to use the SSG options of Next.js, you should not go with Redux. Otherwise, I can recommend you give Next.js a try because it’s a really good framework!