←back to thread

298 points sangeeth96 | 1 comments | | HN request time: 0.212s | source
Show context
simonw ◴[] No.46237795[source]
React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server.

It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we've recently seen, is a risky spot in terms of potential security vulnerabilities.

replies(10): >>46237967 #>>46238102 #>>46238147 #>>46239075 #>>46240339 #>>46240602 #>>46240620 #>>46240996 #>>46241208 #>>46242116 #
tom1337 ◴[] No.46237967[source]
I was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusion whats running where.
replies(2): >>46238010 #>>46238602 #
dawnerd ◴[] No.46238010[source]
I pretty much dumped a side project that was using next over the new router. It's so much more convoluted, way too many limitations. Who even really wants to make database queries in front end code? That's sketchy as heck.
replies(1): >>46239403 #
1. Frotag ◴[] No.46239403[source]
A lot of functionality is obviously designed for Vercel's hosting platform, with local equivalents as an afterthought.