When comparing Next.js and React on Rails (React integrated into a Ruby on Rails stack), there are some interesting trade-offs regarding npm packages in addition to the expected architectural trade-offs and performance considerations. Let’s break these trade-offs down:
1. Packages: Size vs Number
Due to Next.js’s high variety of functionality, it can take the place of multiple packages. However, this comes with trade-offs:
- Baggage: In order to upgrade an aspect of Next.js’s functionality, such as routing, you will be required to upgrade other aspects of Next.js functionality as well. This can result in large PRs that are difficult to review. With multiple packages, each dedicated to a different aspect of functionality, smaller & focused PRs are easier to create.
- Churn: Next.js’s high variety of functionality also requires a higher pace of upgrades on the bleeding edge. Not only does this make for more changes you are required to make just to complete desired upgrades, but it also increases the chance that your code base will be out-of-date with online resources. Next.js’s documentation in their repository is updated in line with changes, but their documentation website is aimed at the bleeding edge.
- Source Code Complexity: Next.js’s source code is highly complex and written in Typescript, which makes modifications through patching or forking more difficult.
- YAGNI (You Aren’t Gonna Need It): Next.js brings a lot of built-in features (like server-side rendering, API routes, static site generation, image optimization) that might feel overkill in certain cases. If you don’t need these advanced capabilities, you could end up with unnecessary complexity in your app. In this case, React on Rails might be simpler as Rails would handle your back-end logic and React would just serve as a front-end layer, keeping things lean.
2. Architectural Concerns
-
Fullstack Monolith (Rails + React):
Ruby on Rails is often viewed as an opinionated framework, where everything tends to work together in a “monolithic” style. For many startups, this simplicity is highly attractive. If you’re just getting started and want to reduce initial overhead, React on Rails could be a great choice because Rails handles both the backend and the front end in one place, which minimizes setup complexity. Plus, Rails has a ton of built-in functionality like database migrations, authentication, and routing, so you don’t have to reinvent the wheel. -
Separation of Frontend & Backend (Next.js + backend framework):
With Next.js, you get more flexibility. It naturally facilitates a separation between the front-end (React) and back-end (Node.js, APIs, or any backend solution). This could mean developing and scaling each part of the stack independently. This architectural decision has its pros and cons: on the one hand, it gives you more flexibility in terms of backend technologies and scaling; on the other hand, it may add more complexity in terms of communication between the front-end and back-end, API management, and deployment.
3. Performance Considerations
-
One of the standout features of Next.js in recent versions is its use of SWC (Speedy Web Compiler), a Rust-based compiler designed to be faster and more efficient than Babel. SWC handles tasks like JavaScript/TypeScript transpiling and minification, and it is tightly integrated into Next.js to improve build performance significantly. Next.js also supports Turbopack as an experimental feature, which might make it an attractive option for developers looking for cutting-edge bundling and fast HMR (hot module replacement) during development.
-
The React on Rails tech stack has also made significant performance improvements by adding support for SWC and esbuild loaders as an alternative to Babel for JavaScript/TypeScript transpiling. This enables users to utilize Webpack’s vast ecosystem of plugins, loaders, and configuration options that have been fine-tuned over the years and still enjoy the latest in Javascript compilation performance. This, in combination with ReactOnRails’ recent implementation of React Server Components, places the ReactOnRails/Shakapacker tech stack close behind, if not alongside, Next.js in terms of performance.
Side Note: While certainly not the first trade-off to come to mind, I’d be remiss not to mention that Next.js is heavily optimized to work with Vercel web-hosting, offering features like automatic serverless deployment, edge caching, and built-in CI/CD pipelines. On the flip side, deploying Next.js elsewhere (e.g., on AWS, DigitalOcean, or your own infrastructure) might require more setup and manual configuration.
Conclusion
The decision between Next.js and React on Rails largely depends on which framework is your primary focus:
-
If you know that you want to use React, but are not committed to a particular backend framework, then Next.js is an excellent option for a frontend, as it can be used in combination with any backend framework or even as a monolith with its Server Actions.
-
If you know that you want to use Ruby on Rails for your backend, then Shakapacker with ReactOnRails or maybe even Vue might be your preferred option for some of the reasons stated above.
In either case, Shakacode offers years of experience in setup and customization for both these frameworks, in a cost-transparent & negotiable package!