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

131–140 of 147 posts

Re: You should know this before choosing Next.js

#131

Post by qudat »

toddmorey wrote: post #33
taeric wrote: post #6

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

I could totally see how you'd arrive there. Backstory: create-react was a starter boilerplate for React built and maintained by Facebook. This was when webpack was the standard and just getting a local development environment to "hello world" for React could be challenging.[1] That project was depreciated and the popularity of the Next.js site framework for react projects (plus I certainly assume heavy lobbying from…

> That project was depreciated and the popularity of the Next.js site framework for react projects (plus I certainly assume heavy lobbying from Vercel) pushed the react docs to officially suggest create-next as the new starting point.

It seems like Vercel had enough money and hype to lure react devs away from facebook to work for them. I see this as the biggest reason why react is pushing users towards vercel. Further, Vercel was able to work very closely with the react dev team when developing react server components, giving vercel a first-to-market advantage and a headstart on vendor lock-in.

Re: You should know this before choosing Next.js

#132

Post by qudat »

bearjaws wrote: post #70
super_trooper wrote: post #43

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

Just use React and any backend? If you have time for the project, you have time to learn a proper setup that every company for the past 15+ years has used. SSR is quite frankly a performance myth if you distribute your frontend on a CDN. Ultimately your cloud functions reach out to your database, that is centrally located... SEO work well without SSR for the most part.

As far as I’m concerned, SSR is completely over-hyped and adds a ton of complexity to your project. All these search indexers are all running headless chrome anyway so the SEO argument is largely false now.

Running vite and deploying a fully static site that interacts with an API is, to me, vastly simpler to reason about than a blackbox react framework (next.js) sitting on top of a black box rendering library (react).

Having a “backend for your frontend” is pure overhead for most projects. I’ve been building on the FE for a decade and have only needed SSR once and certainly never needed some hybrid static/dynamic/islands setup.

If you need SSR, you need it, but I find SPAs to be vastly superior in terms of dev speed and overall performance of an app once the JS has loaded.

Re: You should know this before choosing Next.js

#133

Post by [deleted] »

lenkite wrote: post #121
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…

If you are using next.js, you are not really introducing a library/framework as a dependency - you have technically introduced a consultancy corporation as a dependency in your product.

[deleted]

Re: You should know this before choosing Next.js

#134

Post by recroad »

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…

Why is app router so bad?

Re: You should know this before choosing Next.js

#136

Post by tealpod »

lenkite wrote: post #121
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…

If you are using next.js, you are not really introducing a library/framework as a dependency - you have technically introduced a consultancy corporation as a dependency in your product.

Very well said.

Re: You should know this before choosing Next.js

#137

Post by mikey_p »

mxhold wrote: post #49

I've always been a little uneasy about Vercel after trying to self-host Next.js on a VPS and running into a few of the little traps they seem to have set to nudge you into hosting on their platform instead. I get they have to pay the bills somehow but it does feel a bit risky to bet on their goodwill long-term. The way they've handled this vulnerability has made me even more uneasy. Vercel's initial framing of their…

This reminds me of a bad vuln in Drupal years ago (2014, I think?).

Alot of people think Acquia, being started by the creator of Drupal, has special control of the open source project, but at the end of the day they really don't have that kind of control.

So when the security team found this vuln, they coordinated with as many Drupal hosting platforms as they could, and immediately Pantheon, Platform.sh, and Acquia had all blocked the exploit at the firewall level by the time the CVE was announced.

Re: You should know this before choosing Next.js

#138

Post by lioeters »

recroad wrote: post #134
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…

Why is app router so bad?

Seemingly bad effort-to-reward ratio.

I still have several large projects on previous versions of Next.js, and I'm not motivated (financially or otherwise) to spend the effort upgrading them for no reason other than to keep up with the newest version. One project I did upgrade, I had a hell of a time solving weird compiler errors, and the compile time degraded noticeably for some reason.

Re: You should know this before choosing Next.js

#139

Post by littlecranky67 »

9rx wrote: post #127
littlecranky67 wrote: post #123

Earlier quoted context omitted.

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

> Next.js does have support for static exports. Wasn't it even originally created to produce static websites? But, man, at that point you're bringing a bulldozer (with a super uncomfortable operator's station!) to drive a nail.

> 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.

Re: You should know this before choosing Next.js

#140

Post by 9rx »

littlecranky67 wrote: post #139
9rx wrote: post #127

Earlier quoted context omitted.

> Next.js does have support for static exports. Wasn't it even originally created to produce static websites? But, man, at that point you're bringing a bulldozer (with a super uncomfortable operator's station!) to drive a nail.

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

> 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.

Post reply on HN