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 like the Next 13 release and the app router was a rug pull from a previously pleasant experience.
And whenever you complain about this or ask for support, some devrel guy from Vercel shows up in your replies, saying something to the effect of "Wow! That's crazy, we worked really hard on Next 13! This is my first time hearing about this!"
Edit: Since I know the devrel guys are in this thread: If you want people to keep using Next, something fundamental about how you guys write the framework needs to change. The instability and lack of documentation makes developing with your framework a massive pain in the ass - anyone I know who can is migrating off it as quickly as possible.
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 <html dir="rtl"> in the root layout.
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.
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)?
Not trying to be offensive here and you're getting a lot of flak already, but these two issues are pretty self-explanatory...
It's a matter of configuration, it feels bad in the first one that a configuration is not possible if so desired and even worse having to jump through hoops in the second one because the edge runtime is enforced which one may not care about if all that's done for hosting is `next build` followed by `next start`
- 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.
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.
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....
I'm part of the team from inlang, we are developing solutions to make i18n both easier and more efficiently (e.g. with a web editor, vscode extension and CLI to automate your workflows). Our ecosystem is agnostic to every stack which means it can be integrated with every tech-stack out. We even have our own i18n library called paraglideJS.
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 relative image paths in MDX files and have to shove everything in /public.
- Fuck fighting five layers of configuration and bundlers and libraries and GitHub issues to try and load a WASM file without having the whole thing break.
These were both issues we had to deal with, and similarly lost many hours to trying to resolve.
At one point you guys seemed to have shipped a release that, for some large fraction of users, caused the devserver to start OOMing rapidly. When this started happening to me, I spent about a day trying to debug it, since I assumed that such an a huge and imminent issue would arise from my mistake, not the web framework's. I eventually texted a friend of mine about the problem, only for him to tell me that they had been having the same issue, and linked to this thread.
Working with a web framework that's so unstable that fundamental features like the devserver break periodically isn't fun. I stop trusting the web framework, and when a bug arises I find myself having to check both my own code and Next's. Now this applies to some degree with any open source framework, of course - there's bugs in everything. But I have so little trust for Next at this point. We've collectively lost weeks of eng hours to just dealing with quirks of Next.
Right now we're really affected by the fact that the recommended way to cache database connection objects is broken in our repo (and some other users' repos, evidently).
This is another example of something where I naively assumed that the error was on my end, and spent days trying to debug our database configuration, hosting provider, etc, before realizing that at some point something broke and the recommended way of persisting these connections on the global object doesn't work anymore. What's the point of using a framework if I have to question whether it's working correctly every time an error arises?
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.
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.
Correct, I'm not sure what problem you're having but here's an upbeat response nicely stating it's not Vercel's fault, and/or explaining why it's not a real problem.
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.
Remix is like the Next.js Pages Router + a helper similar to Server Actions. It does not support Server Components (what the App Router uses) and they're exploring using RSC in the future. So definitely different.
For example, `getServerSideProps` in Next.js is the same as a `loader` in Remix.
Astro probably, if they want to keep using React components.
Otherwise they might also be looking at Nuxt, Sveltekit or Solidstart, but if they're switching top-level frameworks they may as well use Astro because they can mix and match React/Vue/Svelte/Solid
This is the broad consensus among everyone else I know using Next - they felt like the Next 13 release and the app router was a rug pull from a previously pleasant experience.
And whenever you complain about this or ask for support, some devrel guy from Vercel shows up in your replies, saying something to the effect of "Wow! That's crazy, we worked really hard on Next 13! This is my first time hearing about this!"
Edit: Since I know the devrel guys are in this thread: If you want people to keep using Next, something fundamental about how you guys write the framework needs to change. The instability and lack of documentation makes developing with your framework a massive pain in the ass - anyone I know who can is migrating off it as quickly as possible.