Live data from Hacker News

You should know this before choosing Next.js

eduardoboucas.com

101–110 of 147 posts

Re: You should know this before choosing Next.js

#101

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.

> Ultimately your cloud functions reach out to your database, that is centrally located...

A big difference is that your code running in the datacenter should always be well connected to the network. The user running your code out in the middle of nowhere teetering on the edge of available mobile coverage... Not so much. SSR means the user can begin after one round trip instead of, at bare minimum, two (and more realistically at least three – HTML, JavaScript, and data), which becomes significant as latency rises.

Although I would agree that the cases where you actually need that are not as common as we like to think, and even where justified a lot of developers are bound to screw it up such that the app isn't usable without multiple round-trips anyway. It is certainly something you should think long and hard about. It is not tradeoff-free.

Re: You should know this before choosing Next.js

#102
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…

The standardization of routing is the main selling point to me. react-router is such a mess at scale

Re: You should know this before choosing Next.js

#103
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…

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.

[deleted]

Re: You should know this before choosing Next.js

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

>I now just use a React SPA with Vite. To be fair it sounds like you didnt need Next.js in the first place then? SPA is more of an alternative than an analog. 6-7s for HMR is terrible though. Agreed.

Next.js' main offering is that you basically get SPA architecture but with a single browserserver round trip on first load instead of two round trips.

That's where ~all of Next.js' complexity comes from, and it should definitely be appreciated for that because it's a hard problem.

But if you don't need that, I don't see why you'd use something so brittle, complicated, and experimental.

Re: You should know this before choosing Next.js

#105
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.[2]

This is a very generous take.

Re: You should know this before choosing Next.js

#106
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…

to be fair, "thunk" is decades old

https://en.wikipedia.org/wiki/Thunk

Re: You should know this before choosing Next.js

#107
post #89
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.

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

Re: You should know this before choosing Next.js

#108

I feel that open source is truly at its best when it’s done by enthusiasts/hobbyists and not necessarily by corporations. React and Nextjs always smelled a bit suspicious to me whereas Svelte and Vue did not. There’s actually an old PG essay talking about Java where I feel a lot of what he says applies to Nextjs: https://www.paulgraham.com/javacover.html

[deleted]

Re: You should know this before choosing Next.js

#109
post #53
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…

To this day I still use pages only. Long term or for a new project I guess I'll have to look into astro or vite/express

I guess Tanstack Start is also a very good alternative to check out https://tanstack.com/start/latest

Re: You should know this before choosing Next.js

#110

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

I guess there are currently three decent alternatives: - Astro - React Router 7 (former Remix) - Tanstack Start

Astro has more focus on content based sites whereas the other two may also be used for web apps.

Post reply on HN