4 ms·

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 t

• tom1337 11mo ago
  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.
  • dawnerd 11mo ago
    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.
    • Frotag 11mo ago
      A lot of functionality is obviously designed for Vercel's hosting platform, with local equivalents as an afterthought.
  • Uehreka 11mo ago
    I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear anyone say they like the App Router (and this is a pretty contrarian site, so if they existed I’d expect to see them here).
    • hmcdona1 11mo ago
      I would highly recommend just checking out TanStack Router/Start instead. It fills a different niche, with a slightly different approach, that the Next.js app router just hasn't prioritized enabling anymore. What app router has become has its ideal uses, but if you explicitly preferred the DX of the pages router, you might enjoy TanStack Router/Start even more.
      • cjonas 11mo ago
        Last time I tried tanstack router, I spent half a day trying to get breadcrumbs to work. Nit: I also can't stand their docs site.
      • rustystump 11mo ago
        Tanstack anything has breaking changes constantly and they all exist in perpetual alpha states. It also has jumped on the rsc train with the same complexity pitfalls. Some libs in the stack are great but they were made pre rsc fad.
        • hmcdona1 11mo ago
          If you're using an alpha library then that's on you for not expecting breaking changes. They have plenty of 1.0+ libraries that do not receive any breaking changes between major releases and have remained stable for well over a year. Also, you're just wrong? You literally cannot serve RSC components _at all_ even in TanStack Start yet. Even when support for them is added it will be opt-in for only certain kinds of RPC functions and they will work slightly differently than they do in Next.js app router(where they are the default everywhere). RPC != RSC. Plus you can always stick to using TanStack Router exclusively (zero server at all) and you never will even have to worry about anything to do with RSCs...
    • berekuk 11mo ago
      I've been using React since its initial release; I think both RSC and App Router are great, and things are better than ever. It's the first stack that allows me to avoid REST or GraphQL endpoints by default, which was the main source of frontend overhead before RSC. Previously I had to make choices on how to organize API, which GraphQL client to choose (and none of them are perfect), how to optimize routes and waterfalls, etc. Now I just write exactly what I mean, with the very minimal set of external helper libs (nuqs and next-safe-action), and the framework matches my mental model of where I want to get very well. Anti-React and anti-Next.js bias on HN is something that confuses me a lot; for many other topics here I feel pretty aligned with the crowd opinion on things, but not on this.
• ashishb 11mo ago
  This happens in Next.js as well https://github.com/vercel/next.js/discussions/11106 https://github.com/vercel/next.js/discussions/11106
• sangeeth96 11mo ago
  This is what I asked my small dev team after I recently joined and saw that we were using Next for the product — do we know how this works? Do we have even a partial mental model of what's happening? The answers were sadly, pretty obvious. It was hard enough to get people to understand how hooks worked when they were introduced, but the newer Next versions seem even more difficult to grok. I do respect the things React + Next team is trying to accomplish and it does feel like magic when it works but I find myself caring more and more about predictability when working with a team and with every major version of Next + React, that aspect seems to be drifting further and further away.
  • stack_framer 11mo ago
    I feel the same. In fact, I'll soon be preparing a lunch and learn on trying out Solid.js. I'm hoping to convince the team that we should at least try a different mental model and see if we like it.
    • thewtf 11mo ago
      Should just use Vue.
      • bargainbin 11mo ago
        Should just use Svelte.
        • braebo 11mo ago
          Using React instead of Svelte to build an app is like using a pile of wet noodles instead of a nail gun.
• TZubiri 11mo ago
  I had this issue with a React app I inherited, there was a .env with credentials, and I couldn't figure out whether it was being read from the frontend or the backend. So I ran a static analysis (grep) on the apk generated and points light at face dramatically the credentials were inside the frontend!
  • jaredwiener 11mo ago
    Why would you have anything for the backend in an APK? Wouldnt that be an app, that by definition runs on the client? Most frameworks also by default block ALL environment variables on the client side unless the name is preceded by something specific, like NEXT_PUBLIC_*
    • deleted 11mo ago
      [deleted]
    • mcpeepants 11mo ago
      > Most frameworks also by default block ALL environment variables on the client side I’ve been out of full stack dev for ~5 years now, and this statement is breaking my brain
    • TZubiri 11mo ago
      Why would you have anything for the backend in a browser app? Wouldn't that by definition run on the client? These kind of node + Mobile apps typically use an embedded browser like electron or a builtin browser, it's not much different than a web app.
• lmm 11mo ago
  Yeah. Being able to write code that's polymorphic between server and client is great, but it needs to be explicit and checked rather than invisible and magic. I see an analogy with e.g. code that can operate on many different types: it's a great feature, but really you want a generics feature where you can control which types which pieces of code operate on, not a completely untyped language.
  • danabramov 11mo ago
    It is explicit and checked. You have two poison pills (`import "server-only"` and `import "client-only"`) that cause a build error when transitively imported from the wrong environment. This lets you, for example, constrain that a database layer or an env file can never make it into the client bundle (or that some logic that requires client state can never be accidentally used from the stateless request/response cycle). You also have two directives that explicitly expose entry points between the two worlds. The vulnerabilities in question aren't about wrong code/data getting pulled into a wrong environment. They're about weaknesses in the (de)serialization protocol which relied on dynamic nature of JavaScript (shared prototypes being writable, function having a string constructor, etc) to trick the server into executing code or looping. These are bad, yes, but they're not due to the client/server split being implicit. They're in the space of (de)serialization.
    • lmm 11mo ago
      > You have two poison pills (`import "server-only"` and `import "client-only"`) that cause a build error when transitively imported from the wrong environment. Sure, but even though it's "build time" it feels more like runtime (indeed I think the only reason it works that way is your code is being run at build time). I should be able to look at a given piece of code and know locally whether it's client-side, server-side, or polymorphic, rather than having to trace through all its transitive imports.
• jaredklewis 11mo ago
  I do think RSC and server side rendering in general was over adopted. Have a Landing/marketing page? Then, yes, by all means render on the server (or better yet statically render to html files) so you squeeze every last millisecond you can out of that FCP. Also easy to see the appeal for ecommerce or social media sites like facebook, medium, and so on. Though these are also use cases that probably benefit the least from React to begin with. But for the "app" part of most online platforms, it's like, who cares? The time to load the JS bundle is a one time cost. If loading your SaaS dashboard after first login takes 2 seconds versus 3 seconds, who cares? The amount of complexity added by SSR and RSC is immense, I think the payout would have to be much more than it is.
  • sakesun 11mo ago
    Deeply agree.
    • procaryote 11mo ago
      I've been at an embarassing number of places where turning off server side rendering improved performance as the number of browsers rendering content scales with the number of users, but the server-side rendering provisioning doesn't
• joshdavham 11mo ago
  I'm no javascript framework expert, but how vulnerable do people estimate other frameworks like Angular, Sveltekit and Nuxt to be to this sort of thing? Is React more disposed to be at risk? Is it just because there are more eyes on React due to its popularity?
  • rk06 11mo ago
    nuxt, sveltekit etc don't have RSC equivalent. and won't have in future either. Vue has discussed it and explicitly rejected it. also RSC was proposed to sveltekit, they also rejected it citing public endpoint should not be hidden they may get other vulnemerelities as they are also in JS, but RSC class vulelnebereleties won't be there
    • rk06 11mo ago
      please forgive typos in above comment. i can no longer edit them
      • joshdavham 11mo ago
        Haha don’t sweat it dude. Happens to literally everyone on HN.
• 0xblinq 11mo ago
  This is why I'm a big advocate of Inertia.js [1]. For me it's the right balance of using "serious" batteries included traditional MVC backends like Laravel, Rails, Adonis, Django, etc... and modern component based frontend tools like React, Vue, Svelte, etc. Responsibilities are clear, working in it is easy, and every single time I used it feels like you're using the right tool for each task. I can't recommend it enough. If you never tried/learnt about it, check it out. Unless you're building an offline first app, it's 100% the safest way to go in my opinion for 99.9% of projects. [1] https://inertiajs.com/ https://inertiajs.com/
  • tacker2000 11mo ago
    I am also in love with Inertia, it lets you use a React frontend and a Laravel backend without a dedicated API or endpoints, its so much faster to develop and iterate, and you dont need to change your approach or mental model, it just makes total sense. Instead of creating routes and using fetch() you just pass the data directly to the client side react jsx template, inertia automatically injects the needed data as json into the client page.
• tonyhart7 11mo ago
  turns out a separation of concern is valid approach for decades React team reinvent the wheel again and again and now we back to laravel
• dirkc 11mo ago
  I 100% agree. I didn't even bother to think about the security implications - why worry about security implications if the whole things seems like a bad idea? In retrospect I should have given it more thought since React Server Components are punted in many places!