> Remix is specifically designed to run in any JavaScript environment so that you own your stack. It is expected many —if not most— production apps will have their own server.
Mmm.
I'm know that technically remix supports static builds (1), but it feels like a bait and switch to turn a client side library into a server side framework.
Am I cynical in think perhaps there were two projects and one of them was more popular than the other (like, 2x more popular say...), so maybe if we take the unpopular package merge it to the popular one people will not notice and we can just pretend we only have one popular package?
Maybe we should just merge all the packages in npm into one package called 'all'. That would be soooo popular, great victory!
I'm joking; but taking this to the extreme makes the point; this is unabashed and unwanted bloat for people who just wanted react router; if people wanted remix, they would use remix. If you don't want to maintain two packages, don't; but this is a bit :|
> and now Remix and React Router are basically the same thing
Mm. That's not how I would describe the difference between a server side framework and a client side one.
The difference in popularity is more like 40x, which makes your theory obviously correct, and it also makes it a no-brainer for the devs. The server-side aspect is opt-in and someone currently using react router v6 (with v7 future flags on) will not need to make any code changes when upgrading to v7. How could a new server magically appear in your application?
> 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.
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.
Mmm.
I'm know that technically remix supports static builds (1), but it feels like a bait and switch to turn a client side library into a server side framework.
Am I cynical in think perhaps there were two projects and one of them was more popular than the other (like, 2x more popular say...), so maybe if we take the unpopular package merge it to the popular one people will not notice and we can just pretend we only have one popular package?
Maybe we should just merge all the packages in npm into one package called 'all'. That would be soooo popular, great victory!
I'm joking; but taking this to the extreme makes the point; this is unabashed and unwanted bloat for people who just wanted react router; if people wanted remix, they would use remix. If you don't want to maintain two packages, don't; but this is a bit :|
> and now Remix and React Router are basically the same thing
Mm. That's not how I would describe the difference between a server side framework and a client side one.
[1] - https://remix.run/docs/en/main/guides/spa-mode