Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js 14

nextjs.org

Post reply on HN
Print view View original

61–70 of 157 posts

Re: Next.js 14

#61

Post by leerob »

cyral wrote: post #55
orf wrote: 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.

next/image optimization works by default when self-hosting. You can optionally use basically any image service you want through a “loader file”.

https://nextjs.org/docs/app/api-reference/components/image#l...

Re: Next.js 14

#62

Post by BoorishBears »

jowday wrote: 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…

Correct, I'm not sure what problem you're having but here's an upbeat response nicely stating it's not Vercel's fault, and/or explaining why it's not a real problem.

Re: Next.js 14

#63

Post by orf »

cyral wrote: post #55
orf wrote: 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.

How do I optimise and convert all my static image files to webp with a PNG fallback, then render them as a srcset so the client can pick the best image?

I.e everything that’s done here[1]

Oh no. You can’t. You need to set “images.unoptimized = true” and be happy about it if you’re not using a cloud image service.

1. https://docs.astro.build/en/guides/images/#properties

Re: Next.js 14

#64

Post by cyral »

samschooler wrote: post #14

Anyone using Next.js in production? Can you speak to the resources needed or optimizations to reduce said resources? I'm worried with how much lifting the server does that, it could rack up a pretty hefty AWS bill if I'm not careful.

I run a large production app on NextJS and the resources needed for it are tiny in comparison to everything else (actual backend services doing heavy lifting). Rendering some HTML on the server is not intensive.

Re: Next.js 14

#65

Post by leerob »

cphoover wrote: post #33

One weird issue I had with next 13 was radio button groups did not work. The suggested fix from a core next contributor and fb employee was to "Upgrade to a canary release"... I get that you are building all these new cool features, but that cannot put basic functionality and backwards compatibility at risk. Radio buttons have been around forever, I'd assume that they are being used by tons of websites all ove the pl…

The reason we suggest upgrading is because it’s extremely common that issues are already fixed or they cannot reproduce when we ask them to upgrade. It helps with issue triage so we can properly prioritize and fix issues.

If you can link the issue with a reproduction, I’m happy to look into it.

Re: Next.js 14

#66

Post by leerob »

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

Community Notes: Vercel did not acquire Gatsby.

Re: Next.js 14

#67

Post by CharlesW »

leerob wrote: post #45
CharlesW wrote: post #16

Earlier quoted context omitted.

FWIW, “Vercel Postgres” is a white-label of Neon: https://neon.tech/blog/neon-postgres-on-vercel

Correct. Same price and limits. It’s just making integrating it into Vercel. So you can get Postgres/Redis/object storage and more with your frontend, in one bill.

That’s great! There’s nothing wrong with a convenient integration. For me personally, even as a happy Vercel user, it makes the service more credible as a competitive option.

Re: Next.js 14

#68

Post by ervine »

leerob wrote: post #27
JCharante wrote: post #20

Earlier quoted context omitted.

I read the release notes but don’t understand what you’re talking about re: app router. They mentioned that they’re still supporting app router and pages router.

Correct, the Pages Router is very much still supported with new improvements being made. The performance improvements in this post apply there. The same APIs and features included in Next.js 1.0 still work today with the Pages Router.

Please take this seriously: stop advising in github issues to switch to App router as a solution to bugs in page router.

It's not an option for large next.js projects, and certainly does not convey what you're saying here.

Re: Next.js 14

#69

Post by garganzol »

jowday wrote: 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…

Where are people dissatisfied with Next migrating?

Re: Next.js 14

#70

Post by turtlebits »

Local development performance improvements are great, but only after end user optimizations!

This blog article is absolutely bloated, and a huge problem I see with JS frameworks.

87 requests 2.9 MB transferred 23.2 MB resources

Post reply on HN