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.
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.
https://github.com/vercel/next.js/issues/54708
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).
https://github.com/vercel/next.js/issues/47099
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?
Let us take control when self-hosting, please!
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.
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.
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 guess it had to be ready for the Next.js Conf event.
plugin for i18next: https://inlang.com/m/3i8bor92/plugin-inlang-i18next paraglide (i18n library): https://inlang.com/m/gerre34r/library-inlang-paraglideJs
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...)
For example, `getServerSideProps` in Next.js is the same as a `loader` in Remix.
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
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.
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.