Denial of service and source code exposure in React Server Components

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.

Hotwire et al are also doing part of this. It isn't a new concept but it seems to come and go it terms of popularity

> And we're all just supposed to act like this isn't absolutely insane.

This is insane to you only if you didn't experience the emergence of this technique 20-25 years ago. Almost all server-side templates were already partials of some sort in almost all the server-side environments, so why not just send the filled in partial?

Business logic belongs on the server, not the client. Never the client. The instant you start having to make the client smart enough to think about business logic, you are doomed.

It's kinda nice.

Main downside is the hot reload is not nearly as nice as TS.

But the coding experience with a C# BE/stack is really nice for admin/internal tools.

I saw this kind of interactivity in Apache Wicket Java framework. It's very interesting approach.

Isn’t that what Phoenix (Elixir) is? All server side, small js lib for partial loads, each individual website user gets their own thread on the backend with its own state and everything is tied together with websockets.

Basically you write only backend code, with all the tools available there, and a thin library makes sure to stich the user input to your backend functions and output to the front end code.

Honestly it is kinda nice.

Also what https://anycable.io/ does in Rails (with a server written in Go)

Websockets+thin JS are best for real time stuff more than standard CRUD forms. It will fill in for a ton of high-interactivity usecases where people often reach for React/Vue (then end up pushing absolutely everything needlessly into JS). While keeping most important logic on the server with far less duplication.

For simple forms personally I find the server-by-default solution of https://turbo.hotwired.dev/ to be far better where the server just sends HTML over the wire and a JS library morph-replaces a subset of the DOM, instead of doing full page reloads (ie, clicking edit to in-place change a small form, instead of redirecting to one big form).

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.

Yes, I say this every time this topic comes up: it took many years to finally have mainstream adoption of client-side interactivity so that things are finally mostly usable on high latency/lossy connections, but now people who’re always on 10ms connections are trying to snatch that away so that entirely local interactions like expanding/collapsing some panels are fucked up the moment a WebSocket is disconnected. Plus nice and simple stateless servers now need to hold all those long-lived connections. WTF. (Before you tell me about Alpine.js, have you actually tried mutating state on both client and server? I have with Phoenix and it sucks.)

> Honestly it is kinda nice.

It's extremely nice! Coming from the React and Next.js world there is very little that I miss. I prefer to obsess over tests, business logic, scale and maintainability, but the price I pay is that I am no longer able to obsess over frontend micro-interactions.

Not the right platform for every product obviously, but I am starting to believe it is a very good choice for most.

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.

Idk about Phoenix, but having tried Blazor, the DX is really nice. It's just a terrible technical solution, and network latency / spotty wifi makes the page feel laggy. Not to mention it eats up server resources to do what could be done on the client instead with way fewer moving parts. Really the only advantage is you don't have to write JS.