Live data from Hacker News

Next.js is infuriating

blog.meca.sh

181–190 of 602 posts

Re: Next.js is infuriating

#181
post #74
post #59

Earlier quoted context omitted.

I wouldn't say I agree with those circumstances, but even if they did indicate a match with Next.js, they are not worth the reduction in productivity and maintainability that comes with it. I use Gleam's Lustre and am not looking back. Elm's founder had a really good case study keynote that Next.js is basically the opposite of: https://www.youtube.com/watch?v=sl1UQXgtepE

this is a really interesting talk - thank you for sharing!

Via Gleam's discord:

https://discord.gg/Fm8Pwmy

There's some good stuff there

Re: Next.js is infuriating

#182
post #148

Earlier quoted context omitted.

First off, since the sentiment here is really negative, I'd like to say that next.js is actually really good for what it does. You've done a great job at building the software that powers millions of websites at this point. I think a big part of the negative sentiment derives from the fact that detailed documentation and reference documentation almost non-existant. The documentation mostly tells you what exists, but…

Don't you find it problematic, as a framework that's 8 years old to already have reached version 15.x? Assuming they follow semantic versioning and those are 15 different backwards incompatible upgrades?

Don’t think it’s semver.

Re: Next.js is infuriating

#183
post #152

Earlier quoted context omitted.

I have a monstrosity of a Vue 3 project at work and I far prefer it to any "elegant" React codebase I've ever had the displeasure of working with. Boggles the mind that React still has any mindshare to me, Vue and Svelte are both superior to it in pretty much every way except for availability of component libraries (which isn't so relevant in my line of work), and a slight edge in terms of TypeScript support (mostly…

I think React is fine, the problem is that every single react app I've inherited is ass - people just do everything incorrectly and overcomplicate simple things. Components with like 5 different useEffects, huge global state causing all kinds of bugs, way too much frontend logic in general. The amount of JS code that exists just to mimic things you can do with HTML and CSS is staggering. Everyone complains that react…

> It's their code that's slow and horrible, react is snappy as hell when you use it properly.

That's the problem though, it's hilariously easy to shoot yourself in the foot with React. If almost every project makes the same common mistakes, it ceases being an issue with the people using it, it's a broader problem. With Vue or Svelte you'd have to try damned hard and go out of your way to mess up in similar ways, because the idiomatic way of writing Vue, especially with Options API, is so simple and straightforward. How many articles do we have out there begging people to please stop using `useEffect`, for example?

Plus, React's reactivity model is terrible and a source of a lot of performance pitfalls. Vue's and Svelte's Proxy/Signals-based approach is much more performant out the gate, and in the case of Vue the diff reconciliation algorithm is a lot better than React's, which itself will already prevent a bunch of useless re-renders compared to 'standard' React apps.

Re: Next.js is infuriating

#184
post #66
post #5

Heard and appreciate the feedback. We’re well aware of the DX papercuts in Middleware. With 15.5 we made a big step in supporting Node runtime[1] which addresses a slew of issues people have reported over time. If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It…

Since you're here — I'll just pipe in. Here in this article, the author, failing to comprehend the domain differences, is applying the same approach to call a function everywhere. Of course it won't work. The fallacy of nextjs is attempting to blend function domains that are inherently different. Stop doing that and you will be fine. Documentation won't work, it will be just more confusing. Blending edge and ssr and…

Sounds like you wouldn’t be a fan of React Server Components in general then since blending domains is its whole point.

Re: Next.js is infuriating

#185
The app router is certainly challenging. This is why we stick to the page router and it works really well. There are some cases where the app router comes handy though.

Honestly, nextjs is not that bad and I would go as far as saying that it is perhaps the best web framework I have ever experienced but it does come with its own problems which might be overwhelming for beginners.

Re: Next.js is infuriating

#186
post #138

Earlier quoted context omitted.

Having front-end and backend in the same language and mono repo is such an outrageous productivity booster for me. Obviously the opposite may still be true if you've got big, separate frontend and backend teams but if you just want to ship.. I wouldn't have it any other way.

You can have a monorepo with any tech stack you'd like. You can write your front-end and back-end in the same language. No shade to you for finding a productive setup, but Next.js tightly couples your front-end and back-end, no question.

I don't use next.js really any more. That's exactly what I do.

Re: Next.js is infuriating

#187
post #148

Earlier quoted context omitted.

First off, since the sentiment here is really negative, I'd like to say that next.js is actually really good for what it does. You've done a great job at building the software that powers millions of websites at this point. I think a big part of the negative sentiment derives from the fact that detailed documentation and reference documentation almost non-existant. The documentation mostly tells you what exists, but…

Don't you find it problematic, as a framework that's 8 years old to already have reached version 15.x? Assuming they follow semantic versioning and those are 15 different backwards incompatible upgrades?

Most of our upgrades have been fairly painless. Yes, they're not CI-succeeds Dependabot merges, but usually it's basically running the auto codemod and you're done, though I do always scan through the release notes and migration guide. That seems justified for the backbone of our application.

Re: Next.js is infuriating

#188
I have no major problem with Next running on Dokploy. I don't use lots of its functionnalities, just some SPA routes and dôme RSC routes.

That's fine. It works fine.

Re: Next.js is infuriating

#190
I think “middleware” is a bit of a misnomer in Next.js. It’s really an edge function that runs before your request hits the app -- quick header checks, routing, and other lightweight guards. It runs on the edge runtime, not on the app server.

The post's author seems to conflate the edge runtime with the server runtime. They’re separate environments with different constraints and trade-offs.

I struggled with Next.js at first for the same reason: you have to know what runs where (edge, server, client). Because it’s all JavaScript, the boundaries can blur. So having a clear mental model matters. But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.

Post reply on HN