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

91–100 of 157 posts

Re: Next.js 14

#91

Post by orf »

kwar13 wrote: post #85
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…

> Fuck spending 3 hours working out why you’re not able to use relative image paths in MDX files and have to shove everything in public. Man this took me on a wild ride once.

Same. Another victim of the two-bundler problem?

Re: Next.js 14

#92

Post by Spixel_ »

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

We migrated to Remix a few months ago, never going back.

Re: Next.js 14

#93

Post by leerob »

ervine wrote: post #68
leerob wrote: post #27

Earlier quoted context omitted.

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.

Can you be more specific on the issue? It’s possible there’s a reason why App Router was recommended in this case.

Re: Next.js 14

#94

Post by BoorishBears »

cyral wrote: post #78
BoorishBears wrote: post #54

Earlier quoted context omitted.

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…

What is wrong with that? I agree that Next 1.0-12.0 SSR was great. But, you were always shipping a ton of JS that may never be called for components that don't have any interaction. NextJS 13 now only ships what JS is needed.

The framework is called React. As in Reacts. RSC is a standard that makes it so that, by default, a component will break your build if you try to react to state.

It's not until you brand it with a "use client" directive, which doesn't opt out of SSR despite the intentionally deceptive name, does the literal basic tenant of React work again.

The RFC literally states libraries should embed this directive to not break builds: that means Vercel managed to fund an effort that breaks the underlying value proposition of a decade old framework by default

Absolute insanity.

Re: Next.js 14

#95

Post by leerob »

ervine wrote: post #75
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…

Absolutely, this is the number one issue I have with next.js - they did a huge ecosystem-splitting update, but now recommend switching to the new paradigm for any issues with the old all while saying they are maintaining the old.

Which issue? There are certain issues that are non-issues in the App Router, and simply not possible in the Pages Router without a significant amount of foundational changes. Which, those changes are, the App Router. That’s why we’ve been focusing on making incremental adoption easy. I think there’s still room to make it smoother (hard navigations between pages/app, metadata codemods for next/head) ad well.

Re: Next.js 14

#96

Post by kavaruka »

tirey wrote: post #39

For anyone looking for a better alternative to the current web dev landscape: use hyperwave. https://github.com/tireymorris/hyperwave It allows you to build full-SSR apps with Tailwind and JSX, has support for SQLite and HTMX, and is in general a great return to how web dev used to be / should be.

this is just an hype-driven "glue code" which combines the most popular buzzwords at the moment, a framework is something else

Re: Next.js 14

#97

Post by afavour »

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…

> Can you share what are you trying to do here? Are you trying to use the same version of react for pages and why?

"and why"?! Staggering levels of negligence there.

Re: Next.js 14

#98

Post by bamazizi »

johnnypangs wrote: post #51
CSMastermind wrote: post #30

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

No that's not true! Svelte is a standalone project. Rich Harris, the founder and face behind Svelte, is paid by Vercel to work on it full-time.

From the same link above: >> "Joining Vercel enables Rich to work on Svelte full-time, giving the project its first dedicated contributor. The governance of Svelte does not and will not change – it's still the same independent, open-source project and community. With Vercel's backing, Svelte can get even more ambitious."

Re: Next.js 14

#99

Post by joduplessis »

johnfn wrote: post #32
joduplessis wrote: post #6

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…

> hate slow-loading SPA pages, and that all the work should have been done on the server

I'm not disagreeing with this actually - but I've also never been a massive fan on SSR for React. In addition - NextJS goes further in inhibiting React functionality - for instance: useLayoutEffect doesn't work at all.

Re: Next.js 14

#100

Post by cyral »

BoorishBears wrote: post #94
cyral wrote: post #78

Earlier quoted context omitted.

What is wrong with that? I agree that Next 1.0-12.0 SSR was great. But, you were always shipping a ton of JS that may never be called for components that don't have any interaction. NextJS 13 now only ships what JS is needed.

The framework is called React . As in Reacts . RSC is a standard that makes it so that, by default, a component will break your build if you try to react to state. It's not until you brand it with a "use client" directive, which doesn't opt out of SSR despite the intentionally deceptive name , does the literal basic tenant of React work again. The RFC literally states libraries should embed this directive to not brea…

The part about including "use client" by default is referring to component libraries. e.g. you don't want to import and have it break because it uses useState. When writing your own components you can decide which need to be marked as client and which don't. I don't think NextJS is doing any harm by not magically including "use client" on your own files. I agree that it is confusing to be called "use client". Maybe "use interactive" would have been better, but regardless the "use client" directive is from React so I'm not sure why it's related to a complaint for NextJS.
Post reply on HN