It's hard to take Vercel at face value these days with all of these improvements and announcements. Are we supposed to - in hindsight - understand that odd version numbers of their codebase were really just unstable releases all along? The app server implementation wasn't really meant to be used because it was an experimental release?
I'm having a difficult time not being salty about this entire situation. There are basic production requirements that haven't been addressed for years because their hosting platform provides it. You don't like the way they do logging? Sounds like you need an attitude adjustment.
I stopped paying attention when someone recently told me that everyone uses nextjs because “nextjs is meta right now”. Mind you this person has been a developer for about 3 years (not that there’s anything wrong with that but it gives you an idea of whose buying into this stuff)
Vercels devrel is by far the best thing that they do, miles ahead of their engineering.
well to me part of the reason to identify "the meta" is not to go along with it, but so you can develop tactics to counter it -- but maybe not everyone thinks that way
Really though, it's not true that "everyone is using nextjs", so it's not "the meta" anyhow. I think most developers can safely ignore it
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.
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 place. Yet hydration of SSR radio buttons was not being done properly and so you could not set a default value for your radio button...
This kinda shit is just basic. You can't add new features at the expense of basic functionality.
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.
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.
Generally, the expectation is that developers know what bugs have been fixed or can quickly check, so users aren't expected to just constantly retry on whatever today's HEAD is. That takes a lot of their time, and you already know what changes you're making so should be able to determine quickly if a bug was fixed.
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.
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?
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:
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
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.
I'll add, it's kind of baffling to hear that things are stable, there are just ton of issues you can't get to.
I'd posit that Next has a ton of users, and a ton of issues, because it prematurely marks features as stable, and then markets them aggressively. Instead of working through these issues in beta with a manageable number of early adopters with aligned expectations, Next gets more than they can handle, frustrated that features sold as production ready are not. This, to me, is a questionable business strategy, not a sound technical one.
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 regression!
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 SEO friendly experience.
Next then turned around and convinced everyone that this wasn't good enough, and you actually want to try and have the server take chunks out of the Javascript your frontend has so that a bunch of metrics that they inflated the performance of would improve.
No, we only want JavaScript for the SPAs, nothing else.
SSR has been doing just fine for the last 25 years, now we have to put up with Next.js, due to the ongoing partner agreements Vercel has been doing to push Next.js as the only framework in MACH products.
> 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.
What worries me are the partner agreements Vercel is making with several enterprise products, making Next.js the only official frontend stack for their products.
With everything else being DIY integration, and lesser tooling.
I think for me the saving grace is the pervasiveness of the React paradigm. Porting code from React to Preact (obvs), Vue3, Stencil or Solid is easy peasy because the patterns are the same. And thanks god for that.
EDIT: Honestly a web components framework with 1-to-1 likeness in API would be first class. I'd jump immediately.
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.
I think I'll be taking a step back from React/Next.js for the foreseeable future. I feel fortunate in that, for most of my projects, I can make architectural decisions such as this. Things took a turn with hooks (I have a feeling that's the general consensus, too). The nail in the coffin (at least for me) was React Server Components.
I gotta admit that its been liberating working outside the javascript/react realm. Using Go + HTMX + [insert tool here] has been a fairly easy transition. Is it a 1:1 replacement? No. Does it solve most of my use cases whilst providing a better developer experience? Absolutely.
I'm not trying to hate on React here. I just think its time to stop and ask ourselves "is this REALLY the best idea/tool for xyz?".
As someone new who started with NextJS v13.4 on AWS, I am also disappointed that AWS/GCP/Others don't support all of Vercel's features. That being said, the commenters here are being unfair and unreasonable.
NextJS 13.4+ is nothing short of incredible. Are you telling me I can get a free, faster, opinionated, React implementation with 10's of finicky/unreliable/3rd-party Node_Module dependencies now seamlessly baked in for free? With a unified/simple build process too?
NextJS is nothing short of a lifesaver for small/indie web dev teams!
I do have my struggles + bloat + bugs using AWS instead of Vercel to host, no doubt, but that's out of my own cheapness/stubbornness. Vercel is not a charity, its a business -- I'm disappointed by commenters here basically complaining they don't "work for free".
Don't use tools that have turned into a product where they have people trying to lock you into whatever platform or any service they have. These aren't just engineers trying to help other engineers solve problems. These are marketeers trying to sell you hype.
Readit News
I'm having a difficult time not being salty about this entire situation. There are basic production requirements that haven't been addressed for years because their hosting platform provides it. You don't like the way they do logging? Sounds like you need an attitude adjustment.
Vercels devrel is by far the best thing that they do, miles ahead of their engineering.
Really though, it's not true that "everyone is using nextjs", so it's not "the meta" anyhow. I think most developers can safely ignore it
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 place. Yet hydration of SSR radio buttons was not being done properly and so you could not set a default value for your radio button...
This kinda shit is just basic. You can't add new features at the expense of basic functionality.
If you can link the issue with a reproduction, I’m happy to look into it.
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.
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?
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/52245https://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.
I'd posit that Next has a ton of users, and a ton of issues, because it prematurely marks features as stable, and then markets them aggressively. Instead of working through these issues in beta with a manageable number of early adopters with aligned expectations, Next gets more than they can handle, frustrated that features sold as production ready are not. This, to me, is a questionable business strategy, not a sound technical one.
Deleted Comment
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 regression!
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 SEO friendly experience.
Next then turned around and convinced everyone that this wasn't good enough, and you actually want to try and have the server take chunks out of the Javascript your frontend has so that a bunch of metrics that they inflated the performance of would improve.
SSR has been doing just fine for the last 25 years, now we have to put up with Next.js, due to the ongoing partner agreements Vercel has been doing to push Next.js as the only framework in MACH products.
Literally every other HN thread I see has at least handful of people pushing Astro.
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.
With everything else being DIY integration, and lesser tooling.
EDIT: Honestly a web components framework with 1-to-1 likeness in API would be first class. I'd jump immediately.
I'm sorry if this sounds too dark or unwarranted, but this playbook is too old to be dismissed.
I gotta admit that its been liberating working outside the javascript/react realm. Using Go + HTMX + [insert tool here] has been a fairly easy transition. Is it a 1:1 replacement? No. Does it solve most of my use cases whilst providing a better developer experience? Absolutely.
I'm not trying to hate on React here. I just think its time to stop and ask ourselves "is this REALLY the best idea/tool for xyz?".
NextJS 13.4+ is nothing short of incredible. Are you telling me I can get a free, faster, opinionated, React implementation with 10's of finicky/unreliable/3rd-party Node_Module dependencies now seamlessly baked in for free? With a unified/simple build process too?
NextJS is nothing short of a lifesaver for small/indie web dev teams!
I do have my struggles + bloat + bugs using AWS instead of Vercel to host, no doubt, but that's out of my own cheapness/stubbornness. Vercel is not a charity, its a business -- I'm disappointed by commenters here basically complaining they don't "work for free".