←back to thread

Denial of service and source code exposure in React Server Components

(react.dev)
298 points sangeeth96 | 2 comments | 11 Dec 25 20:46 UTC | HN request time: 0s | source
Show context
chuckadams ◴[11 Dec 25 21:06 UTC] No.46237166[source]▶
I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
replies(7): >>46237234 #>>46237514 #>>46237562 #>>46237703 #>>46237856 #>>46238657 #>>46239228 #
mubou2 ◴[12 Dec 25 00:09 UTC] No.46239228[source]▶
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads.

Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.

replies(7): >>46239539 #>>46239898 #>>46239981 #>>46240135 #>>46240268 #>>46240784 #>>46240850 #
1. JeremyNT ◴[12 Dec 25 04:09 UTC] No.46240784[source]▶
Well, maybe it isn't so insane?

Server side rendering has been with us since the beginning, and it still works great.

Client side page manipulation has its place in the world, but there's nothing wrong with the server sending page fragments, especially when you can work with a nice tech stack on the backend to generate it.

replies(1): >>46241520 #
2. qingcharles ◴[12 Dec 25 06:51 UTC] No.46241520[source]▶
Sure. The problem with some frameworks is that they attached server events to things that should be handled on the front-end without a roundtrip.

For instance, I've seen pages with a server-linked HTML button that would open a details panel. That button should open the panel without resorting to sending the event and waiting for a response from the server, unless there is a very, very specific reason for it.