Live data from Hacker News

You should know this before choosing Next.js

eduardoboucas.com

71–80 of 147 posts

Re: You should know this before choosing Next.js

#71
post #2

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 cos…

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.

Re: You should know this before choosing Next.js

#73

What is a good alternative, if I want to stick to React. Does any other framework support server/client hybrid rendering.

There are many Astro recommendations. I like it as well but only for more content heavy websites. If you dont have that it's not as easy to work with as something like Remix in my experience.

Re: You should know this before choosing Next.js

#76
Vercel and NextJS should not exist.

I tried next once, and I was met with a bunch of hydration errors in production. The concept is nice, but the framework just over complicates everything for some potential gain of rendering on the server, while in reality none of this is needed (just use traditional HTML rendering).

And I’m not even mentioning the fact that the entire framework was built as a nice facade to sell their overpriced cloud service because todays developers can’t write a CI/CD pipeline that rsyncs their code to a VPS and reloads whatever reverse proxy they use.

Re: You should know this before choosing Next.js

#77
As an architect who helps choose stack items, this article and thread screams very loudly not to use next.js.

Scrutinizing an oss maintainer is one of the first tasks I check off when researching tech stacks.

Even the slightest ethical concerns would exclude something from my decision making.

Re: You should know this before choosing Next.js

#78
post #14

The single reason I switched from next.js was because it was taking me 6-7 seconds on a small project to see changes I made appear in the browser during development (on an M1 Max Macbook pro with 64gb of ram). This is when using the app router, where every change requires a compilation step. I now just use a React SPA with Vite.

Yeah, this is shocking to me. I’m a backend developer who occasionally tinkers with frontend. I gave nextjs a spin and couldn’t believe the reload times on a new project. For folks who use this every day, how/why is this acceptable?

It's acceptable for me because I (and others on my team) do not have to way 6-7 seconds almost ever, it is nearly instant. On odd occasion changes can take a long time to show up, ~5 seconds, but it seems restarting the server fixes it, so not sure what that is about.

Re: You should know this before choosing Next.js

#79

To add to this, in the last couple of releases Next.js got worse for static build exports (everything is compiled and exported to static html+js+assets and put into out/) - it seems it is not a priority anymore. Their built-in image exporter (next/image) never had support for static export whatsoever (in contrast to gatsby). When I brought that up on HackerNews some time back, an employee of Vercel tried to argue aga…

next/image is a particularly poorly built piece of NextJS in my opinion.

At least the last time I used it (around a year ago), their was very little support for basic image transforms. Image resizing and cropping, for example, would always ignore the height provided and resize to the requested width. Any change to aspect ratio was done via a div wrapper and CSS, the image itself wasn't actually cropped to the requested aspect ratio.

This complaint is less about Next as many image services do it, but I've never liked the idea of an image service returning an image format other than what was requested. Deciding what image file size and format to request is a browser concern, the back end should just serve up what was requested rather than trying to cleverly decide the "best" format based on request headers.

Post reply on HN