A short follow-up to Types of APIs and Event Queues. That post covered four shapes: REST, gRPC, tRPC, and queues. There’s a fifth that side-steps the API question entirely. Instead of the server returning data and the client rendering it, the server returns rendered HTML and the client swaps it into the page.
React Server Components is the React-native version: components run on the server, render to a serialised tree, and stream to the client. The “API” between server and client is the component tree itself - no REST endpoint, no schema, no client-side fetch logic. Next.js leans on this heavily.
The same idea exists elsewhere. Hotwire Turbo (Rails, but framework-agnostic) sends HTML fragments via Turbo Frames and Turbo Streams. Phoenix LiveView (Elixir) keeps a stateful socket open and sends DOM diffs. Laravel Livewire does the equivalent for Laravel. HTMX is the framework-agnostic version that works with any backend returning HTML.
The benefit is that you’re not maintaining a client/server schema, a JSON serialisation layer, or much client-side state at all. The cost is that the same backend can no longer serve a mobile app or third-party integration without putting a real API in front of it.
These approaches work best when the server owns the UI and the client is mostly a renderer. As soon as you need a second consumer that isn’t a browser, you’re back to REST, gRPC, or tRPC.
I built the same live-search feature in all five (HTMX, RSC, Livewire, Hotwire, LiveView) to compare them side by side: One Live Search, Five Stacks. Code: github.com/danieljohnmorris/live-search.
HTMX
RSC