Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Word count:

complex: 9

complicated: 2

I've tried Nextjs's app router, and server/client components, and there are more footguns and gotchas than you can shake a stick at. Maybe it'll get smoothed out over time, but right now it is downright HARD to keep the mental model of your app when server and client code is constantly being intermingled, imported, and exported back and forth to each other.



I'm advising a NextJS team now and acting as a liaison to a system they're integrating with. Even the devs in the NextJS code every day get confused about what's running on the server and what's running on the client and the consequences of both.

I can see the attractiveness to a setup like this. Back when I was much more involved in actually typing out code it was always a pain to switch mentally from backend side coding to front-end side coding. On the other hand, it made it easier to reason about security. Front-end was the wild west and on the backend you didn't trust anything coming in.

Another thing, i understand the supposed advantage of having one language for both backend and frontend but i don't recall that ever being a real issue with me or the teams i worked with. Everyone seemed able to shift from Javascript (and associated Javascript frameworks) to the backend language ( Java and C# in my case) without any issues.


> the supposed advantage of having one language for both backend and frontend

Agreed that switching languages isn’t an issue. But being able to share code between backend and frontend is a pretty nice bonus


In fairness, client and server code negotiation can be an intrinsically hard problem. NextJS just tends to make matters worse more often than better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: