> Breaking backward compatibility isn't collateral damage, it's the point.
LOL, if you say so.
Honestly, I don't know how anyone decides to build something on top of the software the react router team puts out. I went through approximately 2 major version upgrades of react router then decided I was done with it unless I had no other choice.
Why do people think being left with huge upgrade tech debt time and time again is worthwhile? There are just so many other choices out there these days. Why you'd choose this "different future" now is beyond me.
It's kinda wild to take something people really like and just keep re-writing it while keeping the same name.
They were around when Angular 1 -> Angular 2 right? No one liked that. Angular 2 is good but calling it Angular 2 when it was so different put a bad taste in everyone's mouth.
Google did that because they wanted the Angular userbase, but that alienated a bunch devs and many decided to switch to React (me included) instead.
Seems the remix/react router team is trying to do the same. They built something popular, and they want to use that to launch their new ideas.
They want to have their cake and eat it too, a built in userbase and explore new ideas. I get it, but why not use another name so people don't get confused or frustrated?
> Google did that because they wanted the Angular userbase
I'm okay with that, because when it came out I was considered part of the Angular workforce, so I was hired to work with a framework I knew very little about at the time.
I went through the same pain with React Router. I would never consider using Remix or anything else from this team. It doesn't matter how great it might be or how much I might agree with the architectural principles. Who knows what shiny new idea they'll be chasing in Remix 4? I'd have to be crazy to trust them.
This is my feel as well, I have to maintain a somewhat complex custom SSR, and each update of react-router has been a pain, basically when they moved from using regex URLs to simpler paths, it was a reasonable decision, but the docs of the new supported patters were lacking, newer docs versions are barely searchable, or directly you won't find mentions to some existing APIs anywhere.
I tried their "get started" project with the newly typed routes, and it feels too complex, and unintuitive, the purpose of a framework is to make your life easier, and it's sad to see people with this much talent missing the goal, I won't be using react-router for future projects.
React Router v4 was released in March 2017 (more than 8 years ago!). v5 was released in May 2019 with no API changes. v6 was released in November 2021 with a new API based on React hooks (this API was much better than the previous). v7 was released in November 2024 with the "Remix" APIs (most importantly the "framework mode"). So, the gaps are 4 years and 3 years - that's doesn't seem that crazy.
I know this isn't particularly on-topic, but I find it fascinating how much this sentence now jostles me.
Reading the article as a whole feels like it was written by a person, but the moment I see this, the "it's not X, it's Y" pattern matching my brain has developed for LLM speech kicks in and I suddenly feel a negative bias toward the content.
I read here some time ago an article of how LLM generated content is the new nylon/lycra. In the 80's this fabric was all the rage but now it just feel cheaper.
The same happens to me when people quote something an LLM told them as a big true.
I really like the ideas touted by the Remix team, particularly (1) use the platform, (2) favor simplicity, and (3) make code more explicit; however, their implementation has always felt ... loosey goosey ... for lack of a better way of saying it. Their plodding approach to announcing v3 at Remix Jam had the same feel—lacking any real wow factor other than, "we're done with React."
I gave Remix a serious try some time ago, but the tutorials seemed rushed and the documentation felt incomplete (some of the referenced APIs were seemingly undocumented).
I would love to see something unseat React—I've never liked hooks—but I don't think Remix will pull it off.
As an aside, I wonder what Shopify's app developers think about the move away from React. I know they're all in on React Native.
i have no dog in this fight and am friends with both but i think this is probably too much leaning into Remix's messaging. i think easier to think about it as "Complex inside" (React) vs "Complex outside" (Remix) - pull up a bunch of equivalent side by side code examples of both to see (this was basically all of react twitter in the month since remix relaunched)
of course React has let the complexity leak and leak and leak over the last 5 years so now the messaging isnt as neat
It seems like they need the self-awareness to say "if we have gotten it so wrong that we needed to drastically lift and change the foundation multiple times, then maybe we need to rethink our first principles"
I didn't know there was a new version of Remix distinct from React Router until I read this post. I thought React Router v7 was Remix merging back in, and that the Remix brand was dead.
If they're looking to have a Remix v3 distinct from React Router, they probably shouldn't have
> The latest version of Remix is now React Router v7
What is the value proposition of Remix 3 then? If it's going to be incompatible with the official React ecosystem, why use Remix instead of more performant alternatives like Solid/SolidStart that don't have React's baggage?
This is what they should have done:
what is now React Router v7 should have been Remix v3, and what is now Remix v3 should have had a new name - it's a new framework that ostensibly makes different choices, new name is a must! They told us for years that Remix is just React Router with additional framework features. That made sense.
I love the idea of converge with the web and also like the simplicity of being able to see what is happening.
I've also experienced the despair or having to debug the internals of a library or a wrapper of a wrapper of a wrapper somebody thought was a good idea to make.
But I wonder how the future in a LLM powered world could look like.
Will LLMs privilege code that require less tokens to read and to write? Will verbosity become a monetary problem? Will short implicit Frameworks take the lead?
I wonder if frameworks will start to optimize for machines or people.
> Simplicity (explicitly control when things update)
I’m not saying this is wrong, but it’s a very very weird notion of simplicity. It reminds me a bit of how C++ engineers argue that for loops are simpler than comprehensions.
I'm a React dev and have been mentoring a junior. React's hooks, when and why they run, is very unintiuative for them. Skill issue is part of it, but React's immutable prop diffing forces the use of hooks and understanding how the framework uses them. Moving to a re-render model which always rebuilds the vdom tree allows callbacks, state to be defined outside of the render method without framework abstractions wrapping them. I'm not familiar with what Remix is doing but it looks a lot like Mithril.js, and working with Mithril is really enjoyable after working with React for as long as I have.
I have no real knowledge of React from the developer side, but as an ordinary user who occasionally pokes around in dev tools to assign blame, React clearly is failing at Simplicity.
There are so many React websites where I see weird update bugs (e.g. updates for some parts of the page delayed by 3 seconds [not blocking render, the rest of the page is updating], or total wipe of something instead of incremental upgrades - weren't these the very problems React was supposed to solve?).
Mere excessive bloatedness I don't blame React for; all sorts of web dev fails at that.
===
The main question I have for Remix is: does the explicit `.update` trigger immediately, or does it wait so it can coalesce multiple updates?
React is a mess, Ivy league engineers building messy, slow, sloppy, inaccessible, full of memory leak websites should be a clear sign this is not a technology that fits most use cases.
In react's devs defense, they've said multiple times you should not use it if yours is a website and not really really an app on html, but people keep thinking their website is different and keep producing abominations like the new GitHub.
If you haven’t yet, also take a look at VueUse. It’s essentially a library of very useful utility composables that come on handy very often, and make for astonishingly clean components.
Haha I said the same thing when I saw it. `this.update` is essentially Mithril's `m.redraw`, which has been around for almost 10 years at this point, and Mithril was already popular for allowing you to use regular `let` variables as state. Everything old is new again!
Yeah, Mithril got this right over 10 years ago. Still good to see at least one big player finally catching up. React's state model has always been a pain to work with.
Well I hope Shopify will have enough third party app developers in the future, now that they have moved everything to GraphQL and Remix (and killed all the other SDKs, like PHP for example), and now that we willhave a non-React Remix soon.
Im pretty sure not many devs will switch to Remix just to work on Shopify Apps…
GraphQL is such a pain. The SDKs are usually bloated. Debugging is a nightmare. Documentation on those APIs feeling adhoc. Outside of rare use-cases, I feel like 99% of the time GraphQL is engineering overkill than a simple resource-based REST interface.
Relay (and hence GraphQL) does solve some problems that have no immediate solution with REST - over/under fetching (data masking, fragment colocation in components) and automatic cache normalisation, but they are mostly problems you would only have at scale with disconnected frontend teams working on a product. The typesafety you get from a compiler and an automatically generated schema is nice too.
I'm convinced Shopify only bought Remix since so many Shopify shops started using Next.js as an external storefront. Shopify realized their moat was dissapearing and if users could roll their own storefront, they were one step closer to rolling their own backend.
Why does every blog nowadays read this way -- quick, witty, sentences "x wasn't the problem, it was the point" (or whatever) and have these section headers that are full thoughts? Or is this just more AI slop?
> Breaking backward compatibility isn't collateral damage, it's the point.
LOL, if you say so.
Honestly, I don't know how anyone decides to build something on top of the software the react router team puts out. I went through approximately 2 major version upgrades of react router then decided I was done with it unless I had no other choice.
Why do people think being left with huge upgrade tech debt time and time again is worthwhile? There are just so many other choices out there these days. Why you'd choose this "different future" now is beyond me.
It's kinda wild to take something people really like and just keep re-writing it while keeping the same name.
They were around when Angular 1 -> Angular 2 right? No one liked that. Angular 2 is good but calling it Angular 2 when it was so different put a bad taste in everyone's mouth.
Google did that because they wanted the Angular userbase, but that alienated a bunch devs and many decided to switch to React (me included) instead.
Seems the remix/react router team is trying to do the same. They built something popular, and they want to use that to launch their new ideas.
They want to have their cake and eat it too, a built in userbase and explore new ideas. I get it, but why not use another name so people don't get confused or frustrated?
It's just exhausting
> Google did that because they wanted the Angular userbase
I'm okay with that, because when it came out I was considered part of the Angular workforce, so I was hired to work with a framework I knew very little about at the time.
It seems angular learned from it early on because upgrades have been a quiet affair since then. React seem to be set on repeatedly learning it.
React itself is still the same fundamental product, not something you can say for Remix or Angular.
Yeah, React Router keeps changing and keeps not quite feeling right. Like they make bad abstractions and then get trapped by them.
We’re looking at Tanstack Router when we get around to it.
TanStack Router builds on those failed iterations of React Router. Good software design is iterative.
I went through the same pain with React Router. I would never consider using Remix or anything else from this team. It doesn't matter how great it might be or how much I might agree with the architectural principles. Who knows what shiny new idea they'll be chasing in Remix 4? I'd have to be crazy to trust them.
This is my feel as well, I have to maintain a somewhat complex custom SSR, and each update of react-router has been a pain, basically when they moved from using regex URLs to simpler paths, it was a reasonable decision, but the docs of the new supported patters were lacking, newer docs versions are barely searchable, or directly you won't find mentions to some existing APIs anywhere.
I tried their "get started" project with the newly typed routes, and it feels too complex, and unintuitive, the purpose of a framework is to make your life easier, and it's sad to see people with this much talent missing the goal, I won't be using react-router for future projects.
React Router v4 was released in March 2017 (more than 8 years ago!). v5 was released in May 2019 with no API changes. v6 was released in November 2021 with a new API based on React hooks (this API was much better than the previous). v7 was released in November 2024 with the "Remix" APIs (most importantly the "framework mode"). So, the gaps are 4 years and 3 years - that's doesn't seem that crazy.
It's a bit crazy. Why ever change it? Imagine if Bash changed every four years, or really anything else that isn't a JS library.
Honestly, it was often that I just hated NextJS enough to deal with the schlep of the Remix/RR churn.
But now TanStack Start is a thing, so they've lost the 'only viable alternative' angle.
I know this isn't particularly on-topic, but I find it fascinating how much this sentence now jostles me.
Reading the article as a whole feels like it was written by a person, but the moment I see this, the "it's not X, it's Y" pattern matching my brain has developed for LLM speech kicks in and I suddenly feel a negative bias toward the content.
I read here some time ago an article of how LLM generated content is the new nylon/lycra. In the 80's this fabric was all the rage but now it just feel cheaper. The same happens to me when people quote something an LLM told them as a big true.
I really like the ideas touted by the Remix team, particularly (1) use the platform, (2) favor simplicity, and (3) make code more explicit; however, their implementation has always felt ... loosey goosey ... for lack of a better way of saying it. Their plodding approach to announcing v3 at Remix Jam had the same feel—lacking any real wow factor other than, "we're done with React."
I gave Remix a serious try some time ago, but the tutorials seemed rushed and the documentation felt incomplete (some of the referenced APIs were seemingly undocumented).
I would love to see something unseat React—I've never liked hooks—but I don't think Remix will pull it off.
As an aside, I wonder what Shopify's app developers think about the move away from React. I know they're all in on React Native.
> Remix 3 chose Simplicity
i have no dog in this fight and am friends with both but i think this is probably too much leaning into Remix's messaging. i think easier to think about it as "Complex inside" (React) vs "Complex outside" (Remix) - pull up a bunch of equivalent side by side code examples of both to see (this was basically all of react twitter in the month since remix relaunched)
of course React has let the complexity leak and leak and leak over the last 5 years so now the messaging isnt as neat
It seems like they need the self-awareness to say "if we have gotten it so wrong that we needed to drastically lift and change the foundation multiple times, then maybe we need to rethink our first principles"
I didn't know there was a new version of Remix distinct from React Router until I read this post. I thought React Router v7 was Remix merging back in, and that the Remix brand was dead.
If they're looking to have a Remix v3 distinct from React Router, they probably shouldn't have
> The latest version of Remix is now React Router v7
at the top of all their docs.
What is the value proposition of Remix 3 then? If it's going to be incompatible with the official React ecosystem, why use Remix instead of more performant alternatives like Solid/SolidStart that don't have React's baggage?
I haven't followed Remix 3 closely. What baggage are they taking from React apart from JSX?
Why use Solid when the developer experience of Remix 3 is so much better?
Yea, or Vue or Svelte?
This is what they should have done: what is now React Router v7 should have been Remix v3, and what is now Remix v3 should have had a new name - it's a new framework that ostensibly makes different choices, new name is a must! They told us for years that Remix is just React Router with additional framework features. That made sense.
I love the idea of converge with the web and also like the simplicity of being able to see what is happening. I've also experienced the despair or having to debug the internals of a library or a wrapper of a wrapper of a wrapper somebody thought was a good idea to make. But I wonder how the future in a LLM powered world could look like. Will LLMs privilege code that require less tokens to read and to write? Will verbosity become a monetary problem? Will short implicit Frameworks take the lead? I wonder if frameworks will start to optimize for machines or people.
> Simplicity (explicitly control when things update)
I’m not saying this is wrong, but it’s a very very weird notion of simplicity. It reminds me a bit of how C++ engineers argue that for loops are simpler than comprehensions.
I'm a React dev and have been mentoring a junior. React's hooks, when and why they run, is very unintiuative for them. Skill issue is part of it, but React's immutable prop diffing forces the use of hooks and understanding how the framework uses them. Moving to a re-render model which always rebuilds the vdom tree allows callbacks, state to be defined outside of the render method without framework abstractions wrapping them. I'm not familiar with what Remix is doing but it looks a lot like Mithril.js, and working with Mithril is really enjoyable after working with React for as long as I have.
I have no real knowledge of React from the developer side, but as an ordinary user who occasionally pokes around in dev tools to assign blame, React clearly is failing at Simplicity.
There are so many React websites where I see weird update bugs (e.g. updates for some parts of the page delayed by 3 seconds [not blocking render, the rest of the page is updating], or total wipe of something instead of incremental upgrades - weren't these the very problems React was supposed to solve?).
Mere excessive bloatedness I don't blame React for; all sorts of web dev fails at that.
===
The main question I have for Remix is: does the explicit `.update` trigger immediately, or does it wait so it can coalesce multiple updates?
React is a mess, Ivy league engineers building messy, slow, sloppy, inaccessible, full of memory leak websites should be a clear sign this is not a technology that fits most use cases.
In react's devs defense, they've said multiple times you should not use it if yours is a website and not really really an app on html, but people keep thinking their website is different and keep producing abominations like the new GitHub.
I’ve been enjoying Vue recently. Its API so far feels like an acceptable cognitive overhead over the raw DOM.
Plus, Evan You seems like a pretty stable and drama free maintainer.
If you haven’t yet, also take a look at VueUse. It’s essentially a library of very useful utility composables that come on handy very often, and make for astonishingly clean components.
Thank you for the suggestion. I'll give it a shot later
It mystifies me why Mithril isn’t used more - this sounds more and more like Mithril
Haha I said the same thing when I saw it. `this.update` is essentially Mithril's `m.redraw`, which has been around for almost 10 years at this point, and Mithril was already popular for allowing you to use regular `let` variables as state. Everything old is new again!
Yeah, Mithril got this right over 10 years ago. Still good to see at least one big player finally catching up. React's state model has always been a pain to work with.
Well I hope Shopify will have enough third party app developers in the future, now that they have moved everything to GraphQL and Remix (and killed all the other SDKs, like PHP for example), and now that we willhave a non-React Remix soon.
Im pretty sure not many devs will switch to Remix just to work on Shopify Apps…
GraphQL is such a pain. The SDKs are usually bloated. Debugging is a nightmare. Documentation on those APIs feeling adhoc. Outside of rare use-cases, I feel like 99% of the time GraphQL is engineering overkill than a simple resource-based REST interface.
The funniest thing about GraphQL is when it's set up to only allow specific whitelisted queries. Incredible.
Relay (and hence GraphQL) does solve some problems that have no immediate solution with REST - over/under fetching (data masking, fragment colocation in components) and automatic cache normalisation, but they are mostly problems you would only have at scale with disconnected frontend teams working on a product. The typesafety you get from a compiler and an automatically generated schema is nice too.
Yea, i also dont like GraphQL. Why they needed to replace the good old REST interface, which was working perfectly, I will never understand.
The tech team there seems to be making some shortsighted decisions in the last couple of years. Lets see if its going to bite them in the long run...
Automatic type a client generation that is extremely mature.
Even when using OpenAPI it’s not as good
GraphQL has validation built in, that’s another big one. For non complex and non-specialized types it validates against the schema quite well.
Query caching is dead simple and quite good
I'm convinced Shopify only bought Remix since so many Shopify shops started using Next.js as an external storefront. Shopify realized their moat was dissapearing and if users could roll their own storefront, they were one step closer to rolling their own backend.
Why does every blog nowadays read this way -- quick, witty, sentences "x wasn't the problem, it was the point" (or whatever) and have these section headers that are full thoughts? Or is this just more AI slop?