This past few weeks, I’ve been busy trying to replace the web server powering our React-based single page application. After some research, the choice was narrowed down to two solutions: Nextjs and Remix.
Both of them showed good results when server rendering a couple of our more heavy routes, a main requirement for the new server.
Choosing between these two proved more difficult. Nextjs has been around longer and is more flexible, but the way Remix handles data loading and persistent layouts feels more ergonomic and powerful.
Remix does not allow you to customize it’s underlying build system, which can be annoying depending on how many custom plugins you currently use. For us it is not a complete show stopper, but it does make going for Remix a much more costly affair in terms of rewriting to please it’s compiler.
Overall, Remix is a more opinionated solution. On the client side of things, it makes solid arguments on why you should use it’s own solution instead of your preferred state management and fetching library.
But I also think there are good counter arguments to be found here. The main objection I have is the fact that I can even consider Remix as a server: the client codebase for our application is mostly self-contained, and does not depend on any specific server technologies to work.
Also, techniques for cross communication at the component level is seeing a lot of development from heavy players at the moment. If you want to avoid future rewrites, it’s probably better to wait and see what solutions will emerge in coming months and years.
For these reasons - for us - Nextjs seemed like a safer bet that is more resilient to change. Even if that change is replacing Nextjs itself.
Top comments (0)