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

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.

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.

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.

undefined

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 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?

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.

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.

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.

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?