Next.js turned out to be worse than PHP.
Next.js is infuriating
341–350 of 602 posts
Re: Next.js is infuriating
#342Just to make single "log("hello") appear anywhere, in a file, in a console, as smoke puffs in the sky.
Infuriating, frustrating, agitating AF.
Turning off logging in a production system is brain damaged move because inevitably production is when you need it the most.
Re: Next.js is infuriating
#343I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.
I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase. Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly. Infinite complexity everywhere, breaking changes CON…
Re: Next.js is infuriating
#344Earlier quoted context omitted.
Really, which ones? Because anything Java, .NET and Python, it certainly requires configuration and related infrastructure.
Log4j can be as simple as add the dependency and you're good to go. Of course, you can do fancier setups and bridge your logs wherever where it is more work, but out of the box, it's very straightforward and batteries included. I have a very hard time believing you're seriously arguing the case that some of the most commonly used languages don't have good options for logging.
Re: Next.js is infuriating
#345Still love Next but it's because I drank the Kool aid early on. Would be intimidated to learn it anew in current state
Re: Next.js is infuriating
#346Earlier quoted context omitted.
> But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer. The biggest issue is that the complexity is self-inflicted. The term middleware has a pretty well understood meaning if you've worked with basically any other framework in any language: it's a function or list of functions that are called at runtime before the request handler, and it is assumed those functions run in th…
As I have mention in another comment > If learn what is a package/module in python, try to apply that in Go without any brain power, you will complain that Go is bad. If you are using any technology, you should have some knowledge about that technology.
Re: Next.js is infuriating
#347I don't get these kind of complaints, coming from Java and .NET web frameworks, Next,js is the only sane frontend framework followed by Angular. Saying this as someone doing Web related development since 1998, glory days of Perl and CGIs.
I’m guessing you enjoyed the nostalgia when you saw directory based path convention from the good old CGI days?
Re: Next.js is infuriating
#348A lot of companies have Nextjs as a requirement, you can see it in the job posts. It's almost like React = Nextjs, where they don't even mention React. There are developers out there who are highly invested in Vercel's business. Ultimately, the dev teams are responsible for making these decisions. I've encountered issues based on Nextjs in a few projects where the best approach was to eliminate it. The outcome was ni…
Possible follow up questions:
- what led your team to want to remove it? - what was involved in removing it? - what did you replace it with? - what makes the new thing better than the old thing? - how did you evaluate that spending X days/weeks/months to remove it was worth the time that could have been spent on developing features?
I think all frameworks and tools have their time and place, and knowing when and how to use them is important.
If a company can't understand this then I wouldn't want to work for them.
Re: Next.js is infuriating
#349Don't be scared by the complaints about previous breaking changes (which BTW are inevitable when we still haven't figured out the best approaches to the server/client app architecture) - React Router's current strategy using various flags [1] allows you to prepare for breaking changes well in advance.
[1] https://reactrouter.com/community/api-development-strategy
Re: Next.js is infuriating
#350Maybe this is a good place to ask... but I was actually considering Next.js as a replacement for Gatsby.js project that is a few years old, but is growing at a steady pace. Given all the negative sentiments, what are better alternatives? I don't even use any SSR, or GraphQL capabilities. The main thing I liked about gatsby vs previous "bring your oown library(router)" are: very little configuring, nice dev server, ea…
Astro I've found to be pretty solid for prototyping, I like that it gives you control over the rendering of client side code islands and that it works with multiple rendering libraries. I don't love some of the direction they've taken lately though, and I worry that it will become bloated with things like astro db