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