Live data from Hacker News

Next.js 14

nextjs.org

131–140 of 157 posts

Re: Next.js 14

#131
post #110
post #80

Earlier quoted context omitted.

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)?

a few more things:

- more comprehensive documentation & tutorials around your own MDX solution would be great. It feels like you put that together, but don't intend anyone to really use it in production, expecting people to go for next-mdx-remote or mdx-bundler

- fix internationalization: I've heard multiple people complain that you now can't do mydomain.com/blog/first-post & have the French version at mydomain.com/fr/blog/first-post. Instead, you need to put everything under a locale, so the English version needs to be mydomain.com/en/blog/first-post

...just in general, it would be nice to see more documentation & tutorials for next 13 / 14 and the app router. People are also not very responsive on github, it feels like you are just moving forward, without waiting for anything to be stable.

Re: Next.js 14

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

What about SSG MPAs?

Literally every other HN thread I see has at least handful of people pushing Astro.

Re: Next.js 14

#133
post #112

Earlier quoted context omitted.

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…

> Next.js is still the only actual implementation of RSC Here's one https://github.com/dai-shi/waku . Also, Redwood is "all in on Server Components" https://tom.preston-werner.com/2023/05/30/redwoods-next-epoc... .

Yeah: an pre-alpha toy project, and a blog post. Dan Abramov shipped a toy implementation too in a blog post right, I think you missed that?

When I said actual I meant it. RSC is a Next.js feature baked into React.

PS: I'm not the target market for Vercel, Mr. Robinson. I think you can skip the damage control for my comments: I don't have your reach so maybe just pretend it's an old man yelling (very truthful things) at the clouds, it can't actually hurt your PR machine.

Re: Next.js 14

#134

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…

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.

Impressive to try and moralize this, but as someone born in "the large part of the world" you're aggrandizing for the typical project made in Next... I assure you that shipping a basic non-React project will be infinitely more appreciated than what RSC is enabling when combined with the style of frontend React encourages even if you do just render it down to a string.

> Real human beings benefit with you ship less code.

Real humans beings benefit from reliable and well-made applications more.

The difference between an good engineer and a truly excellent engineer is understanding how "worse" technical choices can result in a better user experience.

Junior engineers obsess over low level metrics like how many lines of code they right, but for some reason people graduate to obsessing over how many bytes of JS they shipped and don't think for a second:

- "how much of a surface area did I just open up for bugs in my chase?"

- "how much productivity spent catching up on this new paradigm would have been better spent making what my users want and need rather than tinkering with implementation details?"

- "how is adding this convoluted multifaceted multistep approach with an unstable technology going to affect the stability of my application?"

- "how much harder did I just make it to solve the bugs I do know about due to indirection?"

You're shipping less code down the pipe but you're dragging in insane amounts more code at every step of the way from compilation to the server runtime to enable it: the net result is a buggier, more complicated, less reliable application.

Of course, when you make money off people not thinking about this stuff, you don't encourage discussion of it.

Re: Next.js 14

#135
My ongoing concern with Next is the Vercel's team unresponsiveness to page-breaking bugs coming off of features marked "stable" and in the docs.

Lately, it seems like most issues aren't even being acknowledged. It's pretty frustrating to encounter a bug in a documented use case, spend hours trying to fix it, realize it's a Next issue that was filed months ago but has yet to receive a response from Vercel, or to have reproduced and explained the issue and be ignored for months and counting.

The issue count at Next is huge, and I'm sure overwhelming, but if you're going to hype "stable" features that are beta at best, there ought to be some measure of support (or at least acknowledgment) for when they don't work.

People invest their livelihoods in these frameworks, and false claims are damaging. I'm currently knee deep in a project that can't budget a rewrite, so I'm just hoping someone at some point notices these issues and they get fixed. Not great. I've yet to encounter a project that calls features "stable" as carelessly as Next does. I've never felt so burned by open-source marketing.

If I was starting a new project today, I would stay away from Next.

Re: Next.js 14

#136

My ongoing concern with Next is the Vercel's team unresponsiveness to page-breaking bugs coming off of features marked "stable" and in the docs. Lately, it seems like most issues aren't even being acknowledged. It's pretty frustrating to encounter a bug in a documented use case, spend hours trying to fix it, realize it's a Next issue that was filed months ago but has yet to receive a response from Vercel, or to have…

I'm sorry that we haven't been able to respond fast enough. Hundreds of issues are opened every month, and the rate is increasing. We're working hard to try and triage as best as possible and hopefully hiring more folks to help out as well, too.

Could you share the issues you're running into? While there's going to continue to be bugs and things to improve in the framework (it will never be "perfect" or "done"), that does not mean that it's not stable. We mentioned in our conference keynote today that 8,000 of the top 1 million sites on the web are now using the App Router in production.

Regardless, we want to keep improving. It sounds like you have had issues with the Pages Router specifically, and not the App Router, as you mentioned budgeting a rewrite. Is that correct?

Re: Next.js 14

#137
post #107

Earlier quoted context omitted.

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.

I questioned if you understood the topic of my comment, and you replied that you misunderstood the topic. Jumping from that to somehow being an attack on your intelligence is ridiculous.

Also not sure how much more precise I can be in saying "they funded this effort" than my original comment which says "Vercel managed to fund an effort"

Re: Next.js 14

#138
post #136

My ongoing concern with Next is the Vercel's team unresponsiveness to page-breaking bugs coming off of features marked "stable" and in the docs. Lately, it seems like most issues aren't even being acknowledged. It's pretty frustrating to encounter a bug in a documented use case, spend hours trying to fix it, realize it's a Next issue that was filed months ago but has yet to receive a response from Vercel, or to have…

I'm sorry that we haven't been able to respond fast enough. Hundreds of issues are opened every month, and the rate is increasing. We're working hard to try and triage as best as possible and hopefully hiring more folks to help out as well, too. Could you share the issues you're running into? While there's going to continue to be bugs and things to improve in the framework (it will never be "perfect" or "done"), that…

[deleted]

Re: Next.js 14

#139
post #136

My ongoing concern with Next is the Vercel's team unresponsiveness to page-breaking bugs coming off of features marked "stable" and in the docs. Lately, it seems like most issues aren't even being acknowledged. It's pretty frustrating to encounter a bug in a documented use case, spend hours trying to fix it, realize it's a Next issue that was filed months ago but has yet to receive a response from Vercel, or to have…

I'm sorry that we haven't been able to respond fast enough. Hundreds of issues are opened every month, and the rate is increasing. We're working hard to try and triage as best as possible and hopefully hiring more folks to help out as well, too. Could you share the issues you're running into? While there's going to continue to be bugs and things to improve in the framework (it will never be "perfect" or "done"), that…

Hey Lee, thank you for replying. It's nice to be heard! I know that everyone is working hard, and no software of Next's ambition is perfect, much less at this stage, but all the same, I think there's a threshold for stable that isn't being met, and I think that's doing your users a disservice.

The issues I'm experiencing are for the App Router. Namely, and to keep things reasonable scoped, with parallel routes. These are being recommended for common use cases, but a lot of things are broken along their way (along with intercepting routes)... I'd recommend searching issues for the full breadth, but here are a few that jump to mind:

Server actions don't work in parallel routes unless that route was hard navigated: https://github.com/vercel/next.js/issues/54173

Parallel routes don't unmount if navigated from with anything other than router.back()... this might be a documentation issue, as I recently got this to work as expected in one case with a null page.js at the root of the parallel route: https://github.com/vercel/next.js/issues/49662

CSS Modules don't work on hard navigation... entire paths render unstyled: https://github.com/vercel/next.js/issues/52245 https://github.com/vercel/next.js/issues/56524

Speaking of CSS Modules, they import multiple times in indeterminate order. This breaks precedence and the cascade, making styles indeterminate. There are hacks that mitigate this, but even with the hacks it causes problems: https://github.com/vercel/next.js/issues/51030

These aren't exactly edge cases, and to get at the heart of my complaint, they haven't been acknowledged, or haven't been followed up on for months, despite being marked stable. I don't mean to suggest that you all aren't doing the best you can, and I certainly don't mean to suggest that you can do better technically, but as a user it's concerning to get in deep and continually run into beta issues on what's meant to be stable, and be in the dark as to when they'll get resolved, much less if the team is even aware of them.

Re: Next.js 14

#140
post #60
post #53

Earlier quoted context omitted.

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.

What's wrong with that? I have no illusions that Next.js is part of a larger strategy to get me to pay money for services. I feel the same way about VSCode and Azure, or Github and Copilot, etc. I don't have any problem with paying money for products that deserve it.
Post reply on HN