The surface-level approach and APIs/conventions looks very similar, just with some slight differences that people may subjectively prefer over Remix. Personally my immediate reaction is that I prefer Vercel's convention of requiring all visitable routes to be represented by a leaf called page.js. In Remix, you can have a file anywhere in the routes that will create a navigable path segment using the same name as the file, e.g. the file /dashboard/settings.js will be visitable at the URL /dashboard/settings, whereas in Vercel this will need to be /dashboard/settings/page.js. I prefer Vercel's way of doing things, because with Remix you often end up with a .js file as a sibling of a directory with the same name, e.g. /dashboard/settings.js and /dashboard/settings/advanced.js, which means that you can't just look in the /dashboard/settings/ directory to see all of the routes with the prefix /dashboard/settings.
It's almost an exact copy aside from the conventions and names. It very much _is_ Remix. This is pretty wild. It also brings one of my gripes from Remix: parallel fetching. In practice it makes sense, but at times there needs to be a way to fetch data on a parent route first so that child routes don't fetch again. I'm sure Vercel will find a way to solve this.
Doesn’t Outlet context solve your issue? It let you share data between parent and child path. Of course it is during rendering so you can’t use parent data in your loader.
> Of course it is during rendering so you can’t use parent data in your loader.
I specifically want the parent data to perform redirects in child routes. The only solution is to manually add the redirects at the parent level (like a whitelist).
The routing is pretty similar. A concept that predates Remix, but Remix made popular again.
What sets Remix apart is how it handles network requests through its own <Form /> wrapper, which anecdotally leads to incredibly simple data handling. Even cooler, if you restrict yourself to GET and POST, your app will work without JS. Nifty, if you ask me.
Which is a bit silly, to be honest. I understand wanting to see some credit given, and it wouldn't have cost Vercel anything to do so, but this is hardly "new Remix technology" that they're copying (also the condescending "React czar" stuff is just super inappropriate, but par for the course with the way the Remix team has been talking about Remix on Twitter since the days when they were boasting about not taking VC money).
The fundamental approach Remix (and now Vercel) takes to nested routing with React SSR is fairly straightforward. It's how everyone else (not using a framework) has been doing nested routing with React SSR for, what, at least 5 years? Granted, most of us have been using React Router for our React SSR setups, and credit very deservingly goes to the React Router guys (who are now the Remix guys) for that. Remix did a great job of delivering a framework that (via a nice compiler and file structure conventions) makes this React SSR routing architecture very easy to use! But that doesn't mean that anyone else who takes this same fundamental approach is somehow copying Remix. The home-grown React SSR setup I've worked on for the last 4+ years has been doing the same thing this whole time, and while we might be "copying what the React Router community was doing 4-5 years ago," and that might even include demos or articles written by someone who went on to found or work at Remix (again, really, thanks!), I don't think we're in any sense "copying Remix."
edit: Well, I just noticed on Twitter than the cofounder of Remix (also co-creator of React Router) is, contrary to the opinion I expressed in the paragraph above, clearly claiming that he believes Remix deserves attribution for any usage of concepts which ever existed previously in React Router. I don't agree with this. https://twitter.com/ryanflorence/status/1528862791490105344
> No shame in copying but the first prototype of this started before Remix was available. It was more inspired by traditional server routing techniques (like FB used) with React Router locality with Next.js file conventions. So it's more about convergent evolution in this case.
It’s an odd claim, because people have been asking for this (nested routes) more-or-less since Next was first released. In fact, Remix is basically a compiler for the patterns we could achieve back in the days of React Router 2 and 3 (2015-2017).
The fact that the APIs looks similar seems largely inevitable based on the fact that everyone seems to be converging around defining routes using folder and file name conventions.
It reminds me of patent trolls who patent obvious software designs. I was looking for such feature long before I heard of Remix. I know he's the react-router guy, but nested views isn't exactly some novel idea - sites have been using it forever.
I definitely understand the reaction. This is an existential threat to Remix.
However, this is why I don't use Twitter. Remix is not just "an open-source project", it's a full-fledged company. This is definitely not the time (or the forum) to lay your cards out on the table...
It's a full fledged company and somehow Ryan Florence and the other guy are quite heavy handed in pushing their business which irks me. Even react router was moved to a business org called react training if I remember so that they could sell their courses. Now there is nothing wrong with earning money but this new wave of "open source" businesses is a bit yucky.
It's not the training, it's the fact that they moved the project repo under the React Training organization, and now it's under Remix... Just comes off as a cheap attempt at marketing while ruining the OSS image of the project.
IMO it's really just a matter of time before good ideas end up in other projects. It's inevitable. Obviously everyone wants their framework to be as good and popular as possible.
That is so true. It's been driving me insane since Remix was announced/opened but I couldn't quite put my finger on why. It's because overnight there was an army of people preaching the new religion of Remix all over the place, and not a single one I asked could (at the time at least) tell me why it was better/different than Next.js (a project which IMHO rose on its merit and had to fight for every inch). They had clearly never looked seriously at Next.js before because every "feature" of Remix they were excited about was something Next.js already did. After a bit they started linking to a very long blog post from the Remix creator that supposedly explained why they were different, but after 10 minutes of looking through a post that was supposed to answer my question, all I had was anecdotal performance numbers about how Remix is "faster."
In software we definitely do tend to cargo cult and worship good languages/frameworks, but the Remix "love" is (or was at least) over the top even for us.
It's weird to me: I don't use Twitter and I don't intentionally follow influencers or celebrities in the tech world. Yet somehow RF has been the center of several bouts of developer of drama I've come across. Any idea why that might be?
And remix is ripping features from Vercel. Such as they business model, and the idea of creating their own framework for it.
Additionally, I wouldn't trust ever again the guys that rewrote and broke react-router with incompatible changes like... 6 times already? And now bragging on podcasts "Remix is 10 years old because is just built on top of react-router". Bullshit, it's just the npm package name that is this old. It is so deceptive all the ugly marketing they're doing.
