Live data from Hacker News

Next.js 14

nextjs.org

51–60 of 157 posts

Re: Next.js 14

#51
post #18

Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 . Fuck 1MB of JS to render a static HTML page. Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all. Fuck spending 3 hours working out why you’re not able to use relative imag…

Svelte seems to be popular with the frontend devs I talk to.

Fun fact: Vercel “owns” Svelte too.

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-...

Re: Next.js 14

#52
We've had an awful experience with Next. There are undocumented, broken things all over the place. Migrating to the App Router was a huge mistake. 'use client' didn't work as expected, and we had to install workarounds and try out different hacks to get access to the most pedestrian features we could expect from any other web framework.

This is the broad consensus among everyone else I know using Next - they felt like the Next 13 release and the app router was a rug pull from a previously pleasant experience.

And whenever you complain about this or ask for support, some devrel guy from Vercel shows up in your replies, saying something to the effect of "Wow! That's crazy, we worked really hard on Next 13! This is my first time hearing about this!"

Edit: Since I know the devrel guys are in this thread: If you want people to keep using Next, something fundamental about how you guys write the framework needs to change. The instability and lack of documentation makes developing with your framework a massive pain in the ass - anyone I know who can is migrating off it as quickly as possible.

Re: Next.js 14

#53

It's hard to take Vercel at face value these days with all of these improvements and announcements. Are we supposed to - in hindsight - understand that odd version numbers of their codebase were really just unstable releases all along? The app server implementation wasn't really meant to be used because it was an experimental release? I'm having a difficult time not being salty about this entire situation. There are…

I stopped paying attention when someone recently told me that everyone uses nextjs because “nextjs is meta right now”. Mind you this person has been a developer for about 3 years (not that there’s anything wrong with that but it gives you an idea of whose buying into this stuff) Vercels devrel is by far the best thing that they do, miles ahead of their engineering.

So you stopped using a product because a junior engineer liked it? That doesn't strike me as the best rationale to make a decision.

Re: Next.js 14

#54
post #32

The general direction React (+ Next) is going worries me a bit at times. I might be too conservative, but I want my JS on the frontend and not hot loaded from the server. For this reason I'm much more excited about Vite/Bun/Dino/etc. Also thank god for shit like Preact.

> I want my JS on the frontend and not hot loaded from the server I'm fascinated by this. Literally, in every other HN thread in existence, you find stadiums of people shouting that they hate slow-loading SPA pages, and that all the work should have been done on the server, as God intended. Only on the release of Next.js 14 , of all things, do you find people saying that actually SPAs are great and SSR is a regressio…

You're falling for the trap Vercel laid by having RSC co-opt the concept of SSR.

People are complaining about server components and the machinery to enable them: but those are actually unrelated to SSR.

Client components are rendered on the server.

-

SSR was the sane middleground that worked since Next.js 1.0: You generated some content, and the frontend had all the Javascript and used that content to give a snappier SEO friendly experience.

Next then turned around and convinced everyone that this wasn't good enough, and you actually want to try and have the server take chunks out of the Javascript your frontend has so that a bunch of metrics that they inflated the performance of would improve.

Re: Next.js 14

#55
post #18

Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 . Fuck 1MB of JS to render a static HTML page. Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all. Fuck spending 3 hours working out why you’re not able to use relative imag…

The image component works fine when self-hosting, I use it on several production sites. What is it that doesn't work well without their cloud service?

The default bundle size is also nowhere near 1MB. Next 13 and server components entire point is to reduce the bundle size by not shipping JS that is only ever called on the server.

Re: Next.js 14

#56

Earlier quoted context omitted.

Svelte seems to be popular with the frontend devs I talk to.

Fun fact: Vercel “owns” Svelte too. https://vercel.com/blog/vercel-welcomes-rich-harris-creator-...

I know Rich Harris explicitly says, at least when Vercel ownership comes up, that he has a lot of leeway and total control of the project; is there any reason to think that Vercel will force Sveltekit to adopt similar things as Nextjs?

Re: Next.js 14

#57
post #53

Earlier quoted context omitted.

I stopped paying attention when someone recently told me that everyone uses nextjs because “nextjs is meta right now”. Mind you this person has been a developer for about 3 years (not that there’s anything wrong with that but it gives you an idea of whose buying into this stuff) Vercels devrel is by far the best thing that they do, miles ahead of their engineering.

So you stopped using a product because a junior engineer liked it? That doesn't strike me as the best rationale to make a decision.

So you start using a product just because other people tell you they are popular? That doesn't strike me as the best rationale to make a decision.

Re: Next.js 14

#58
post #52

We've had an awful experience with Next. There are undocumented, broken things all over the place. Migrating to the App Router was a huge mistake. 'use client' didn't work as expected, and we had to install workarounds and try out different hacks to get access to the most pedestrian features we could expect from any other web framework. This is the broad consensus among everyone else I know using Next - they felt lik…

I’m sorry you haven’t had a good experience. And if you more specifics if anyone on the Next team replied to you in that way, please let me know.

I’ll be the first to say the launch of the App Router could have been smoother. Definitely not the first time I’ve heard the feedback. I’m optimistic Next.js 14 is a step in the right direction based on this.

What do you feel is undocumented? I’ll get that added.

Re: Next.js 14

#59
Next.js and Vercel are the same company. This means that the projects are susceptible to conflicts of interest. For example, pushing the server side forward while degrading the client story is the exact result one may get when such conflict is in effect.

I'm sorry if this sounds too dark or unwarranted, but this playbook is too old to be dismissed.

Re: Next.js 14

#60
post #53

Earlier quoted context omitted.

I stopped paying attention when someone recently told me that everyone uses nextjs because “nextjs is meta right now”. Mind you this person has been a developer for about 3 years (not that there’s anything wrong with that but it gives you an idea of whose buying into this stuff) Vercels devrel is by far the best thing that they do, miles ahead of their engineering.

So you stopped using a product because a junior engineer liked it? That doesn't strike me as the best rationale to make a decision.

Notice how you subconsciously called Next a product.
Post reply on HN