Migrating to Next.js from Create React App
nextjs.org
nextjs.org
But it is insanely productive if you want to do a mixture of static rendering/server rendering/client rendering. The abstraction leaks here and there, but mostly it holds up, and more importantly almost all of your code can be shared. If you want to do just one of the three, there are better options. But if you're doing client-side + one or both of the other two then it's amazing, and I don't know of anything better.
What are the chances that I build something that is on par with something stable worked on by dozens?
There’s a slew of features that I have zero interest in building, maintaining, and fixing while I could build the actual product instead.
Going between each of these modes for a given top-level page is a matter of changing a few lines of code; child components will Just Work(TM) in all of the above contexts without modification.
None of this is impossible to do yourself, but Next makes it absolutely breezy, plus additional features like hot-reloading during dev, code-splitting on a per-page basis, and prefetching of those split bundles. You can also do crazy stuff like statically render all your pages so that the first page the user hits (regardless of which one it is) will get fetched as HTML, but then have all further navigation happen totally on the client side, where the same React code is getting run on the client that was used to statically render all the HTML at build time, so there's no worry about inconsistency.
Frankly, in a hand-rolled site I wouldn't even bother doing some of the fancier stuff Next does, even if I knew how and knew it would be beneficial, because it would just be so darn complicated. But when it's this effortless, I can casually do it wherever it makes sense to (or experiment to find out whether or not it makes sense to!).
As for the TypeScript types, there are just several parts that are not as thoroughly typed as they could be; there are some `any`s, and just yesterday I got bit by passing an invalid event name to router.events.on(). The first argument is typed `string` when it could have been a union type with the exact event names that are valid, which would have caught the error before it got to our QA environment. Just stuff like that.
I should note that we aren't on the latest version of Next, so it's possible the situation has improved. And assuming it hasn't, I've thought about submitting a PR myself with some improvements to the declarations.
Overall, though, it's a great framework!
Razzle[0] seems like a workable alternative if you need static exports for optimizations such as link unfurling. Still looking for something that isn't based on Webpack (ideally esbuild or swc)— would appreciate links in replies.
Next.js may switch away from webpack (to swc) at some point in the near future (they recently hired the developer of swc).
Razzle is a far more hands-off approach, one of those tools that get out of your way, and disappears when you're using it. That has great value because it doesn't dictate how you write your application.
In contrast, Next.js is a framework, with its own universe of conventions, conveniences, ways to do things. It has a lot more functionality out of the box. Excellently documented, too.
I'd say Next.js provides great value in a team environment, to have a common, consistent and simple build configuration as well as application structure.
There's much to love about Next.js, but the only thing that bugs me is how they do opt-out telemetry. I have a postinstall script that runs "npx next telemetry disable", but it feels dirty.
---
As for "bloated Next.js projects", surely that's not the fault of the framework. It does its best to produce a lean production build, so the bloat is up to the user. (Unless you mean the size of the node_modules folder during development.)
I ended up making contexts that contained generic cross-platform implementations of stuff like links and dynamic components, that shared code could consume in order to function on both CRA and NextJS simultaneously - this made it possible to move things incrementally.
As for Next, I’ve played around with it and I liked the built-in support for Head, Image and Link. The SSR and lazy loading is amazing and should be the default for every tool, I hate that CRA does not support this out of the box. I was surprised when I tried to export my test and I couldn’t find an output folder though, and even more surprised and disappointed when I found you had to do `next build && next export` which immediately threw an error because the default loading behaviour of the Image component relies on Vercel hosting to work.