[tjosepo]

> it feels like a bait and switch to turn a client side library into a server side framework

And I think that's exactly what the React ecosystem needs right now.

There has been a growing split between client-side React and server-side React, with most existing React applications being client-side with no easy path to server-side that didn't involve a full app rewrite in Next.js or Remix.

The new React Router Vite plugin is that easy path to server-side React that people were looking for. If you're using React Router (like most client-side applications do), you're already 90% of the way there.

[arnorhs]

Now I appreciate the forward-thinking mode of the comment. That being said, the comment makes a lot of glaring assumptions - such as:

a) most teams/apps/projects want to switch to using server-side react (?)

b) the reason they haven't switched is not because a) but because it involves a full re-write of their code (??)

c) vite plugin would be an easy path to server-side react (??)

d) this easy path is what people were looking for

e) that somehow, all the teams out there that wanted to switch their project to server-side react, but thought they couldn't, just simply didn't realize they were 90% of the way there

I'm not really sure where to start, but let me explain some of the reasons a lot of teams / apps / people use the client-side only version of react / <insert favorite routing library>:

1. it allows teams that are pretty much front-end only, to mainain their autonomy

2. it allows people to maintain a clear split of responsibilities

3. a lot of front-end teams have no experience running server-side stuff in production

4. a lot of teams would not really benefit from server-side react - or the main benefits would be neglegable performance benefits, which might not even be perceived at all

5. a lot of people / teams have a backend-team that uses a completely different stack / programming languages - so they would not even be able to help or assist when things go badly when there are issues - or help with training the front-end people to deal with server side configuration/deployment/issues/node.js stuff (as much as we all want to pretend server-side react is not actually a node.js app, it is)

6. there's also a lot of people that just have a philosophical point of view that there should be a clear distinction between front-end and backend - and that these things should remain very clearly separated.

Now, I know these are not unsolvable - and some might be based on some misunderstanding and/or arguably wrong opinions/takes - there is a way for every team to get into some middle ground - eg. treat the server side react as kind of a front-end server or like a caching layer - but the topic is nuanced enough that it's impossible to give a concise solution in a single comment.