Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You should know this before choosing Next.js

eduardoboucas.com

Post reply on HN
Print view View original

81–90 of 147 posts

Re: You should know this before choosing Next.js

#81

Post by lelandfe »

diggan wrote: post #24
rco8786 wrote: post #12

I was using next.js when they switched from the pages router to app router. I ended up just abandoning the project, the app router experience was that bad, and haven't really been keen on picking up next.js since then. It's always seemed clear that Vercel has been, at best, OSS- ish . Trying to play both sides of claiming to be open source but also (somewhat sneakily) building a walled garden to lock users into their…

> next.js when they switched from the pages router to app router It is react-router all over again. For those who weren't around, react-router appeared early in React's life, and lots of people were using it. But, for every major version they released, they completely changed the way of doing the routes/routing, so if you wanted to use a maintained release, you'd have to constantly refactor, often without any real ga…

I love that the "new" way to use React Router just says "Most projects start with a template"... and then gives no installation instructions for adding it to an existing project beyond looking at an already configured one: https://reactrouter.com/start/framework/installation

Re: You should know this before choosing Next.js

#82

Post by Eikon »

> The official methods for self-hosting Next.js require running the application in a stateful way, as long-running servers. While technically possible, this is very hard to operate in any real-world production environment where a single instance isn’t sufficient.

Come on, this is a patently false statement.

There's nothing inherently stateful about Next.js deployment, and self-hosting is both thoroughly documented and straightforward: https://nextjs.org/docs/pages/building-your-application/depl...

If you've worked with any modern deployment pipeline, you'd know self-hosting Next.js is no more complex than any other React application. You build it, you deploy it, you scale it with standard practices.

For many teams with existing infrastructure, self-hosting is actually simpler than migrating to a platform like Vercel. This kind of misinformation reads like someone who either hasn't actually tried self-hosting or has some agenda against the approach.

> The setup needs to be able to dynamically scale up very quickly in order to handle sudden bursts of traffic, while at the same time being able to scale down to zero in order to be cost-effective.

This is obviously a non-issue with the vast majority of deployed apps as a even a single nextjs instance will be able to trivially handle thousands of requests per second.

Re: You should know this before choosing Next.js

#83

Post by taeric »

yodon wrote: post #11
taeric wrote: post #6

I was under the impression that Next.js was the successor to React? Is that not the case?

> I was under the impression that Next.js was the successor to React? Is that not the case? You should probably read the article before posting.

Apologies, I worded my question wrong. I should have asked if that "Was not that the case?"

My memory was that the hello world, "starter" project, was to create a "Next.js" application at some point. I see, now, that they have https://react.dev/blog/2025/02/14/sunsetting-create-react-ap... documenting that they don't recommend any "starter" path. That somewhat surprises me, but I couldn't say it shocks me.

Re: You should know this before choosing Next.js

#84

Post by buffalobuffalo »

rco8786 wrote: post #12

I was using next.js when they switched from the pages router to app router. I ended up just abandoning the project, the app router experience was that bad, and haven't really been keen on picking up next.js since then. It's always seemed clear that Vercel has been, at best, OSS- ish . Trying to play both sides of claiming to be open source but also (somewhat sneakily) building a walled garden to lock users into their…

I think the fundamental problem is that next.js is trying to do two things at once. It wants to a) Be fast to load for content that is sensitive to load speeds (SEO content, landing pages, social media sharable content, etc). It also wants to support complex client side logic (single page app, navigation, state store, etc). Doing those two things at the same time is really hard. It is also, in my experience, completely unnecessary.

Use minimal html/css with server side rendering (and maybe a CDN/edge computing) for stuff that needs to load fast. Use react/vue/whatever heavy framework for stuff that needs complex functionality. If you keep them separate, it's all very easy. If you combine them, it becomes really difficult to reason about.

Re: You should know this before choosing Next.js

#85

Post by rob »

Next.js is secretly a paid framework designed to be run on Vercel, masquerading as open source, and somehow they did it in a way where even the most popular YouTubers continue to shill for them as it being the "best" framework.

Re: You should know this before choosing Next.js

#86

Post by rob »

super_trooper wrote: post #43

Well shoot. I just started a new Next.js project least week. What's everybody's go to alternative?

PHP and Laravel (free starter kits, stable.)

Python and Django (SaaS Pegasus is a good paid boilerplate, complete with a standalone React frontend example.)

Re: You should know this before choosing Next.js

#87

Post by jakubmazanec »

ramesh31 wrote: post #29
diggan wrote: post #24

Earlier quoted context omitted.

> next.js when they switched from the pages router to app router It is react-router all over again. For those who weren't around, react-router appeared early in React's life, and lots of people were using it. But, for every major version they released, they completely changed the way of doing the routes/routing, so if you wanted to use a maintained release, you'd have to constantly refactor, often without any real ga…

>It's kind of weird to me how programmers (especially of libraries like that) aren't more careful about introducing breaking changes, since the work needed to be done afterwards multiplies really quickly. Programmers, generally, always aim to do that. But the JS framework world for whatever reason has this constant obsession with reinvention. I honestly think it stems from a sort of inferiority complex that FE devs h…

> obsession with reinvention

That seems like a comment made with an outsider perspective. Various front-end libraries keep changing APIs simply because the web and related technologies keep constantly evolving.

When was the speed of change fastest and why? During 2010s, because usage of web/apps for everything exploded and browsers started to add features that designers and developer needed. If your CSS/UI library doesn't support for example CSS grid, you do what - not upgrade it and won't use modern grid at all? That's just a silly attitude.

> CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart

That maybe true, but 1) not only FE developers do that, 2) it's orthogonal to the actual reason I stated above.

Re: You should know this before choosing Next.js

#88

Post by dizhn »

koakuma-chan wrote: post #44
dizhn wrote: post #38

Earlier quoted context omitted.

I don't mind running open source js apps on their free tier. :)

No one is better than Cloudflare when it comes to free tiers.

Yup. I had to go back and check why I preferred vercel. Turns out it's a python app not js.

Re: You should know this before choosing Next.js

#89

Post by arkh »

leetrout wrote: 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 see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect.

Maybe people should rediscover the joys of just FTPing files on a cheap host.

It's not like most project will have problems running on those hosts. And if it is the case scaling is one bare metal server + nginx away.

Post reply on HN