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

121–130 of 157 posts

Re: Next.js 14

#121

Post by jowday »

leerob wrote: post #115
jowday wrote: post #86

Earlier quoted context omitted.

Hard to say specifically, especially because I spent about a month trying to deal with this when we first migrated from Next 12 to 13 - but it essentially seemed that if you were using any web tech that wasn't built with SSR in mind, there were issues that were unaddressed in the documentation at the time. Someone else in these comments mentioned: - Fuck spending 3 hours working out why you’re not able to use relativ…

Extremely appreciate this detailed response.

I gotta say, your responses in this thread more or less typify the interactions with Vercel devrel that I complained about in my parent comment. Every time I, or someone I know, complains about Next or try to raise an issue on social media, you or someone else at Vercel shows up asking for more info. If we give you any info we get a polite "Ah thanks for letting us know, yeah that sucks!", and nothing is done, as far as we can see, to address the issues we brought up or course correct Next's development.

Re: Next.js 14

#122

Post by 5Qn8mNbc2FNCiVV »

orf wrote: post #63
cyral wrote: post #55

Earlier quoted context omitted.

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

You just use the image component and specify the sizes. The png fallback is provided via the server looking for the Accept header so when it supports webp it gives you webp, otherwise you get png (or jpg depending on the original extension)

Re: Next.js 14

#123

Post by leerob »

jowday wrote: post #121
leerob wrote: post #115

Earlier quoted context omitted.

Extremely appreciate this detailed response.

I gotta say, your responses in this thread more or less typify the interactions with Vercel devrel that I complained about in my parent comment. Every time I, or someone I know, complains about Next or try to raise an issue on social media, you or someone else at Vercel shows up asking for more info. If we give you any info we get a polite "Ah thanks for letting us know, yeah that sucks!", and nothing is done, as far…

I plan to look into the issues that you mentioned in your previous comment. I'm sorry that I can't get to it today, but I will follow up on those issues.

Re: Next.js 14

#124

Post by tomlagier »

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…

Honestly, I've had a great experience because I've read a lot of experiences like yours and stuck with pages router & Next 12, which works nicely for everything I've needed it to do.

There might be a point where app router is stable & smooth but it's pretty clearly not right now, so havn't really seen the need to upgrade. I think there was a pretty decent comms issue with the stability of it from both the Next and React teams, but I have a hard time faulting an otherwise fairly stable and useful framework for adding features when they're not breaking the existing stable path.

Hooks was a bit of a bumpy transition as well, but I do think that I prefer the code written with them to the code before them. I think it's OK to wait a year or two to let the rough edges get filed down when these types of frameworks release big new feature sets.

Edit: I'll note that we don't use next/image or API routes either, both of which I've seen some churn / pain with. Possible I just hit on the framework when it was in a pretty happy place and most of the new features or suggested defaults have had pain points that I havn't experienced.

Re: Next.js 14

#125

Post by afloatboat »

leerob wrote: post #58
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…

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.

I'm currently investigating the feasibility of using Next.js for a major refactor of our service and the one thing that stands out to me is how fractured the Next ecosystem is. More than 6 months after the App router was introduced the most important libraries are still in beta and don't have conclusive documentation for integrating with App dir.

For my projects localisation is a necessity. I tried both i18n and next-intl and found them both lacking in functionality, buggy and missing documentation. This should just be part of the framework or at least have a tighter integration.

The same story with next-auth.js, which confusingly still exists while promoting https://authjs.dev/. For the most basic implementation it probably works, but the app router documentation is spliced into the normal documentation which creates a whole lot of ambiguity.

There's been a lot of discussion surrounding caching for Next.js 13 as well. I personally find it confusing and the behaviour described in the documentation regarding revalidateTag/revalidatePath and client-side caching does not match my real world experience. I would love some more documentation regarding user-specific caching as well, for instance with personalised user dashboards.

It feels a bit ridiculous to release Next.js 14 today as we're still getting used to Next.js 13. And though there might not be any big/breaking changes it creates a feeling where Vercel is racing forward without keeping other library maintainers or its users in mind.

Re: Next.js 14

#126

Post by leerob »

afloatboat wrote: post #125
leerob wrote: 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.

I'm currently investigating the feasibility of using Next.js for a major refactor of our service and the one thing that stands out to me is how fractured the Next ecosystem is. More than 6 months after the App router was introduced the most important libraries are still in beta and don't have conclusive documentation for integrating with App dir. For my projects localisation is a necessity. I tried both i18n and next…

You can continue to use the Pages Router until there's broader ecosystem support for the larger React changes like Server Components. You don't need to use a library to handle localization or i18n.

i18n was part of the framework in the Pages Router, but it was limiting. We heard a lot of feedback that folks wanted better access to the raw primitives versus an opinionated i18n setup. So now you have full flexibility when using Middleware https://nextjs.org/docs/app/building-your-application/routin....

NextAuth.js just released a new beta version with full support for all App Router features, including Server Actions. It's what we're using in the official Next.js Learn course that teaches authentication https://nextjs.org/learn.

We mentioned this in the keynote today at Next.js Conf, but it wasnt in the Next.js 14 post, but next we're working on simplifying caching. We do now have extensive documentation on caching, but it kind of highlights that it's a bit much right now https://nextjs.org/docs/app/building-your-application/cachin....

Next.js 14 doesn't have new APIs to learn, so if you're learning Next.js 13 (which I believe you're referring to the App Router model), nothing changes. The major version is for semver, because there's a few small breaking changes like bumping the Node.js minimum version. We have some codemods https://nextjs.org/docs/app/building-your-application/upgrad....

Re: Next.js 14

#127

Post by hermitwriter »

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…

Underrated comment.

Re: Next.js 14

#128

Post by hermitwriter »

BoorishBears wrote: post #54
johnfn wrote: post #32

Earlier quoted context omitted.

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

This isn't the most robust characterization.

For people with medium and high end devices, SPAs are mostly fine. For those with low end devices (which is a large part of the world), SPAs sometimes don't work well and this is true of many UI frameworks.

Real human beings benefit with you ship less code. And, if people are paying for data, which a lot of people still do, this matters.

Re: Next.js 14

#129

Post by batmansmk »

leerob wrote: post #38
batmansmk wrote: post #8

Really not interesting for us. Makes what’s simple simpler and what’s hard harder. Sure for a quick prototype website with 10min only that would help, but any decently sized app that needs auth/localization/high performance in memory/offline/optimistic updates/batch fetching … all become way harder. It feels like react unchained from Meta’s constraints and it looses its appeal.

Which part of this release do you find more difficult? For applications that need those dynamic constraints, like auth and personalization, we’re working to make this even easier starting this this version. This version also includes stability for Server Actions, which includes a hook useOptimistic for optimistic updates. I agree the offline story isn’t great today and we could do better there.

Thanks for checking with us. SSR makes auth based routing harder as well as any faceted renders like localization (because now not only the cli needs to query the api, but also the rendering server, with all the CORS/security config that goes with it). Offline is obviously harder. Integrating some specific build features like css pre processors are harder too, as the SSR needs to hook itself up in the build process in very specific ways. The mixed approach with pages/ and apps/ makes it so hard for 3rd party supported libs: mantine 7 wants to sit in apps/ ad that was the only way their css preprocessor could hook cleanly with nextjs whereas the previous version wanted to sit in pages/ etc. Sharing components with our emailing platform isn’t possible anymore. It only runs on web now.

I understand the need as a business to address more use cases that buys servers. But as a current user, upgrading to a new nextjs has been mostly painful and unrewarding.

Post reply on HN