I warn everyone away from next.js. Unsurprisingly V0 has a real shot at massively increasing its adoption because people don’t know any better.
What are some salient counter points for choosing next.js? I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect. If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.
I've been building SPA apps for years with express and React. For a recent project we decided to use Next.js and self host. The biggest benefits have been
1) having the middleware contained in the same runtime and therefore not having to set up multiple projects and hosting for each. We just build a single docker image and put it in ECS.
2) having things like routing, bundling, linting, etc. already included. There are some downsides--like I would rather have biome out of the box than prettier/eslint, but most the developers haven't really cared.
There is a lot of magic and complexity under the covers that I haven't fully groked, and from that perspective I have reservations about it, especially after the recent CVE. As an example of the complexity, I had to set up Sentry, and while Sentry does have a package specifically for next.js, it was still tricky to ensure we were capturing errors with appropriate context in every possible spot.
It's possible as our project matures we'll hit some roadblocks that will make us question our decision to use next.js and self host, but overall our dev team has been productive with it.
>What are some salient counter points for choosing next.js? ... If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.
Well there are alternatives to Next.js that handle SSR. Remix for example. That's a popular one.
For a smaller project I wouldnt be afraid of rolling your own with Vite. It's pretty simple.
And for any developer I'd really recommend implementing SSR yourself with an express server or whatever. It really increases your understanding of how frameworks work.
Remix unfortunately does not have (built-in) static export. Plus, the big rename that Remix is now "react-router" does not help their brand. Lot of people don't associate react-router with being a SSR framework.
> Maybe people should rediscover the joys of just FTPing files on a cheap host.
Trouble is that the reason we got away from that model because applications started to become so bloated by frameworks that it took ages to see them start up, thereby necessitating a bunch of hacks to see them respond in a reasonable amount of time, with that eventually evolving into services like Vercel that try to hide the hacks behind a "just upload it" service.
So, first, people would have to rediscover the joys of not creating monstrosities. But in an age when someone might consider Nextjs... Good luck with that.
Actually, I do exactly that and Next.js does have support for static exports. I write the SPA in React/TypeScript/Next.js and export to static html+js+css+assets. Those I can simply sftp to a target static webhost. All the logic is in a REST backend that is written in .NET/C#.
Unfortunately, Next.js dials back static export support with every major release, but it is still usable to create a 100% SPA with static export.
> But, man, at that point you're bringing a bulldozer (with a super uncomfortable operator's station!) to drive a nail.
I think I do exactly the opposite. Having no SSR but everything be statically exported allows me to get away with cheaper hosting on the backend side (the REST API is on a cheap VPS). Static exported SPA means, the user's browser does all the heavy rendering. Plus, no AI bots or search engines contribute to my server's load.
Additionally, the site is fast. Not sure if you know how Next.js works, but since the initial load is already prerendered and just static html+js, it loads instantly. Then hydration happens in the background, unnoticed by the user and the actually JS takes over. JS+CSS are chunked where possible, and Nextjs employs a neat trick: It pre-loads the js+css for the next page once you mouse hover over a link - whether you click it or not. Also increaes the user-perceived speed. Plus, since all js chunks have its sha1 hash in the filename, they can be served with long caching times (even immutable, so cached forever) - once you loaded the website, recurring visits will be blazing fast.
If you want to try it out, the url is https://lockmeout.online - although I do not use a CDN and host verything on a cheap hetzner VPS - hence loading time might be higher outside europe.
> Having no SSR but everything be statically exported allows me to get away with cheaper hosting on the backend side
Building a static website is very reasonable. Using the monstrosity that is Next.js to build a static website seems like super overkill, and I am not sure it offers a good developer experience to justify it[1].
[1] My experience with it had a need for dynamically driven pages, so it may just be that it's horrid design is only a problem once you move past static page generation.
You confuse a static website with a statically exported webapp. The site I do and posted a link to has a user/login section with lots of interactivity. Plus, there are features like using the webcam for scan QR codes (using a wasm library to read QRcode in JS from a media stream), receiving push notifications (and be a PWA on iOS), generating customizable print cards, etc.
Just having conventions around routing, and a "just works" build & lint is nice to avoid a team bikeshedding their own solutions. (Please don't suggest react-router... which seemingly reinvents itself every couple years).
API routes in same codebase that can use same TypeScript types instead of these typegen tools is really nice too.
I'm very much in the camp of not fiddling with build, routing, hydration, state, etc. as they end up being a distraction from just making the thing you set out to make.
As mentioned on another reply, it is favoured by many SaaS vendors as the only extension framework for their products.
Using something else, means not having support, and spending time yak shaving instead of coding the real solution.
From Java/.NET ecosystem point of view, Next.js is the framework where I feel at home.
I work with agencies that have partner agreements with Vercel/Netlify, which makes it a good option for SaaS products that are in the MACH architecture space.
There is such an exaggeration about the need/utility of SSR. Google is dead for new projects, if one is optimizing their stack based on the easiness for Google to crawl it, I think they are making a terrible architectural decision for no return. Deploying a React/JavaScript app is much easier without Next.JS.
What are some salient counter points for choosing next.js? I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect. If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.
Anything else?