Our great sponsors
-
-
Next-JS-Landing-Page-Starter-Template
🚀 Free NextJS Landing Page Template written in Tailwind CSS 3 and TypeScript ⚡️ Made with developer experience first: Next.js 14 + TypeScript + ESLint + Prettier + Husky + Lint-Staged + VSCode + Netlify + PostCSS + Tailwind CSS
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
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.
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?
Just update my free and open source Next.js Landing Page template to version 14 without any issue: https://github.com/ixartz/Next-JS-Landing-Page-Starter-Templ...
Just update my free and open source Next.js Landing Page template to version 14 without any issue: https://github.com/ixartz/Next-JS-Landing-Page-Starter-Templ...
For anyone looking for a better alternative to the current web dev landscape:
use hyperwave. https://github.com/tireymorris/hyperwave
It allows you to build full-SSR apps with Tailwind and JSX, has support for SQLite and HTMX, and is in general a great return to how web dev used to be / should be.
> Next.js is still the only actual implementation of RSC
Here's one https://github.com/dai-shi/waku. Also, Redwood is "all in on Server Components" https://tom.preston-werner.com/2023/05/30/redwoods-next-epoc....
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.