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