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

21–30 of 147 posts

Re: You should know this before choosing Next.js

#21

Post by gedy »

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…

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.

Re: You should know this before choosing Next.js

#22

Post by amadeuspagel »

> With Next.js having such a sizeable share of the market, I would expect a lot more hosting options, which would foster competition and innovation across the board, ultimately benefitting users and the web.

Would it? Or would it turn Next.js hosting into a commodity with zero marginal profit, ulimately making it impossible to fund development?

Re: You should know this before choosing Next.js

#24

Post by diggan »

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 gains except "now we're on the latest version". I, just like parent with next.js, eventually stopped using it because it was too much.

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. I'd wish people just split their new stuff into new libraries instead of changing the interface of existing ones.

Re: You should know this before choosing Next.js

#25

Post by fabian2k »

I'm not really convinced the serverless approach is a good default. It adds a lot of complexity that you might not need at all. I'm also not a fan of Javascript on the backend, but that's really more of a personal preference. But it is quite common to have backends in different languages, so the focus on server components and Next.js in the React world felt a bit like some tunnel vision to me. It was focused on an entirely different use case than mine, which is of course perfectly fine as not all features need to target my use cases. But pushing a more narrow and specialized setup as the default does seem like the wrong choice to me.

And the serverless approach very likely was the reason they used HTTP headers for this kind of privileged communication between parts of the application. Which is a terrible idea for environments where you can't be sure those headers are never set by users.

Re: You should know this before choosing Next.js

#29

Post by ramesh31 »

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…

>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 had in the the 2000s/10s which led to every single library feeling the need to invent new words to describe some CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart. So stores became "reducers", promises became "thunks", and macros became "runes", and lots of FEs got to high five themselves and add that stuff to their FAANG promotion packets while we wallowed in their mountains of meaningless abstractions in the name of "doing things The Right Way" like FB and Google.

Re: You should know this before choosing Next.js

#30

Post by rckt »

blackoil wrote: post #23

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

I was trying out Astro recently. Seems fine. And it allows you to bring in any kind of components: React, Svelte etc. Has its caveats, but it's same stuff with slightly another approach.

But anyway, I think there's plenty of alternatives. Next.JS simply took everyone's attention making it to seem like there's no other tool like it out there.

Post reply on HN