Live data from Hacker News

Next.js 14

nextjs.org

101–110 of 157 posts

Re: Next.js 14

#101

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.

What does vite/bun/deno has to do with keeping JS on the frontend?

They focus on the tooling and not pushing a "paradigm" like SRR. Maybe not the best examples I would admit.

Re: Next.js 14

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

If you're down with the paradigm of Next.js App Router, Remix is just a strictly better version.

If you're not you stick with pages router and get ready to fork as soon as they drop it. (Just don't ask when that will be https://www.reddit.com/r/reactjs/comments/156m504/comment/jt...)

_

Edit since I got rate limited: DevRel at Vercel replied to this trying to spin Remix not supporting RSC as a differentiator.

It doesn't support RSC because you guys managed to ship a flawed standard under the React brand and they rejected it.

It's the value proposition of RSC without the broken standard (and better performance)

Your reply is like saying an EV isn't environmentally friendly because it doesn't support E85 gasoline and yours does.

Re: Next.js 14

#103
post #5

Wait wtf, I clearly remember 13 came out of beta 4-5 months back. At this rate Next.js will be on version 20 by the end of next year.

It's been about a year since Next.js 13 - so a bit more than 4 - 5 months.

I think they were thinking of the App Router becoming stable a few months back, and that was kind of the main feature of 13 I'd argue. Personaly that's when I migrated my codebase too and was a little shocked to hear they are already releasing a new major version.

Re: Next.js 14

#104
post #47
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 we get a fuck for these automatic "stale" issue locking bots too? Ridiculous.

It really is counterproductive. If projects are going to take months to work on critical issues, they need to change the definition of "stale" to match, or just not auto-close issues at all.

It accomplishes nothing and obscures the sign posts that would help the next developer that encounters the same issue.

Re: Next.js 14

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

Ah this was me when I moved to next 13 and finally said fuck it and moved back to plain templates and some webpack (for ts for doing non ajaxy js). Even as a backend/platform I actually gave the modern JS ecosystem a really decent try (about 2 years on next/react alone). And before that I had written fairly complex fe code in typescript (granted these weren't doc oriented apps but were more like IDEs). The moment I had to serve static-ish sites the complexity just ballooned!

Re: Next.js 14

#106
post #100

Earlier quoted context omitted.

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

I pointed out that the directive is for libraries, and stated the framework React is built on reactivity. The vast majority of the ecosystem is built on using state.

Didn't realize I needed to put this together for you, but that means the vast majority of the ecosystem defaults to breaking your build.

_

And frankly, I really have to question your understanding of the topic when you say things like "NextJS is doing any harm by not magically including "use client" on your own files"

Vercel drove RSC home for Next.js. Shopify tried it (because eCommerce) the effort petered out, and then Next.js, needing a bullet in the chamber against Remix and Hydrogen went and dragged a half-baked concept antithetical to the underlying technology over the finish line.

Next.js is still the only actual implementation of RSC: Remix tried it and wrote it off for very obvious reasons... since Vercel/Next.js got to write the framework side and the implementation, there are a massive number of gaps in the standard.

Re: Next.js 14

#107
post #100

Earlier quoted context omitted.

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

I pointed out that the directive is for libraries, and stated the framework React is built on reactivity . The vast majority of the ecosystem is built on using state. Didn't realize I needed to put this together for you, but that means the vast majority of the ecosystem defaults to breaking your build. _ And frankly, I really have to question your understanding of the topic when you say things like "NextJS is doing a…

Your comment sounded like you expected NextJS to add "use client" to everything to prevent it from breaking, I misunderstood, which is what my comment was referring to. I see that you mean they funded this effort that results in other libraries breaking. You may want to consider using more precise language instead of questioning others intelligence, it really isn't necessary.

Re: Next.js 14

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

It's like the devs never tried building anything real with their own framework. Internationalisation support was dropped in the app router and the docs just tell you to DIY... but just to make the app support RTL languages you need to do some hacky things to update the in the root layout.

Re: Next.js 14

#110
post #80
post #58

Earlier quoted context omitted.

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.

https://github.com/vercel/next.js/issues/22319 https://github.com/vercel/next.js/discussions/46722 Let us take control when self-hosting, please!

Can you share a bit more about what you're trying to build? Is there a specific library you're wanting to have in Middleware versus putting it in a layout or page (which does support all of Node.js)?
Post reply on HN