Post

What kind of React app do you get paid to work on (not hobby projects)? - CSR, no SSR - Isomorphic SSR - RSC Again, if you don’t use React at a paid gig, don’t reply. If you maintain multiple, reply with the one that makes the most money (the product, not yourself)

9 reposts219 likes

Isomorphic SSR, but mostly CSR. Tried RSC, but found the transition in Next to be impossible to do gradually. Too many API incompatibilities. Will likely abandon Next rather than upgrade.

RSC We currently have 3 projects all on rsc. Two are just marketing sites and one is a proper app. For marketing sites it’s all good but for our app I dream about rewriting it entirely in either vue or svelte. Next really left a bad taste. One of these nights I’m gonna take the plunge…

CSR, that’s what Sanity Studio. I don’t know if starter templates and demos counts? Even if they are it’s overwhelmingly CSR across the line

RSC + isomorphic SSR (Next.js app, App Router w/ RSCs for "new" pages, Pages Router for "old" pages)

Before I got layed off, I greenfielded a CSR, No SSR React project (used Tanstack Router) Another team chose Django with HTMX for their new project. Where does that fall, Isomorphic SSR?

Maybe one day we'll have SSR/dynamic SSR & prerendering at Datadog, but as most of the content id highly dynamic, we only do CSR for now

Over my last 8 years, CSR only. Even some features should be use SSR, our team still do CSR. So I always keep an eye on Tanstack Start because of "Client-Side First, 100% Server Capable" 🥳

i write microfrontends, apps on a larger legacy page all CSR, rarely nested workflows outside of the occasional modal lots lots lots of forms

CSR and SSR. The CSR project has a much greater impact which I attribute in part to the fact that it's CSR but mainly to the fact that it's my own solo project. The SSR projects are the main job of my team but I have to say that I would do things differently if I could.

Mainly CSR, but lots of "grey area" with Next/Gatsby. Typically SSG and hydrated in those contexts. Tried one thing with RSC with Next and burned it to the ground, migrated to Svelte 😅

isomorphic ssr. i work on internal tools and there's always an ask for apis. it's easier to consume apis from a react app and less overhead with onboarding other devs that only care about enough react to get the job done.

Next.js works quite well with this setup tbh. Using the middleware and the route.ts routes that it offers, a lot of code that should be handled server-side, is handled server side.

Over my career (8 years): CSR made the most money Last 3 years alone: SSR (Next.js pages router) Last 6 months alone: RSC (Next.js app router) A small sample, but business decisions have often been driven by the general ecosystem direction.

An app I work on was #2, but it’s been going through a rebuild/migration which brings it up to a newer version of next and we’ll likely take advantage of at least baseline RSC.

SSR has been unwieldy to me. Considerably more complex imo with things progressively getting more complex each year. I haven’t done a large CSR app since pre 2017 but most of the issues I had then were around data fetching and caching and tanstack query seems to have basically solved that imo.

RSC for new projects and older projects are Isomorphic SSR. Mostly e-commerce projects, some marketing websites. Some older ones are on custom express SSR but most are NextJS with pages router and later on app router.

I'm building a single page application with some computations occurring on client side. The client has its own caches, keeps them up to date in real time by registering to some events issued by our back end, handles virtualized lists and grids in many places, deals with infinite scrolling...

Most of my work is on CSR Also if I'm building anything personal or commercial - I'll still choose CSR no doubt Will consider SSR / RSC - only for the pages that needs them

Related: This week I was playing around with RR7 and your router and I felt the impulse of starting a fork focused on SPAs Imo, all the server stuff adds too much complexity that’s not always required.