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

121–130 of 147 posts

Re: You should know this before choosing Next.js

#121

Post by lenkite »

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.

Re: You should know this before choosing Next.js

#122

Post by littlecranky67 »

nonethewiser wrote: post #67
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…

>What are some salient counter points for choosing next.js? ... If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase. Well there are alternatives to Next.js that handle SSR. Remix for example. That's a popular one. For a smaller project I wouldnt be afraid of rolling your own with Vite. It's pretty simple. And for any developer I'd reall…

Remix unfortunately does not have (built-in) static export. Plus, the big rename that Remix is now "react-router" does not help their brand. Lot of people don't associate react-router with being a SSR framework.

Re: You should know this before choosing Next.js

#123

Post by littlecranky67 »

9rx wrote: post #107
arkh wrote: post #89

Earlier quoted context omitted.

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

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

Re: You should know this before choosing Next.js

#124

Post by akvadrako »

wirybeige wrote: post #78
dirtbag__dad wrote: post #47

Earlier quoted context omitted.

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.

Do you use it on vercel, maybe?

I had the same experience of slow refreshes on the NextJS project I worked on (running locally) and the other seasoned NextJS developers didn't think it was unusual.

Re: You should know this before choosing Next.js

#125

Post by mdhb »

9rx wrote: post #98
jFriedensreich wrote: post #52

I was always highly sceptical of vercel even though or maybe also because i really love the design and public appeal they are going for. But something about everything they do and talk about gives me the creeps, something is telling me that they are not genuine and keeping something. Its maybe the same feeling when you talk to a really pleasant to talk to person who you just know is a psychopath making the heir on yo…

I find the problem is that Vercel has great product vision, but is weak in the engineering department, so encounters end up in some kind of uncanny valley.

I think it’s literally the other way around. The CTOs previous role was in charge of Google’s search experience.

Re: You should know this before choosing Next.js

#126

Post by rco8786 »

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.

This is an excellent way to frame it

Re: You should know this before choosing Next.js

#127

Post by 9rx »

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

Earlier quoted context omitted.

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

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.

Re: You should know this before choosing Next.js

#128

Post by 9rx »

mdhb wrote: post #125
9rx wrote: post #98

Earlier quoted context omitted.

I find the problem is that Vercel has great product vision, but is weak in the engineering department, so encounters end up in some kind of uncanny valley.

I think it’s literally the other way around. The CTOs previous role was in charge of Google’s search experience.

> I think it’s literally the other way around.

Aside from the "appeal to authority", what suggests to you that they are strong in engineering?

> The CTOs previous role was in charge of Google’s search experience.

Google search also having decent product vision, but poor engineering execution, sounds about right. I don't know how many times I've heard people say they want to use Google search but have to resort to silly hacks, like adding "site:reddit.com", just to get anything useful out of it.

But, to be fair, he in particular only worked on "Google Search on Desktop" which probably isn't the search results department. The one text input box and two buttons did stay centered. I suppose some do say that is the hardest problem in engineering, but I'm pretty sure they are joking.

Re: You should know this before choosing Next.js

#129

Post by qudat »

arkh wrote: post #89
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.

I built a static site hosting platform specifically to bring back the feeling of simply copying files to a server to “deploy”

https://pgs.sh

Re: You should know this before choosing Next.js

#130

Post by floydnoel »

matt-p wrote: post #53
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…

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 use Vite and built my own router. Works great and i can do a whole SPA with just that.
Post reply on HN