React and Remix choose different futures | Hacker News Reader

React and Remix choose different futures

laconicwit.com

64 pointssurprisetalk49 comments

> 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

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?

Yea, or Vue or Svelte?

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?

That’s subjective

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.

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 think absorbing into React Router makes more sense when you consider that a) most of Remix was just RR, and b) Remix had at most 5-10% the users that RR has[0] (probably fewer). I think the "modes" distinction[1] within React Router is easier to understand and explain than a separate framework wrapping RR.

[0]: https://npmtrends.com/@remix-run/react-vs-react-router

[1]: https://reactrouter.com/start/modes

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.

I am excited about Remix 3 and I've been following all their work for years, but I agree about the naming — when Ryan said at React Conf 2024 that Remix wasn't going away, but just "taking a nap", they should have taken the universal confusion that ensued as a sign that they should pick a new name.

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 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'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.

Of course teaching FP ideas to traditional-javascript devs is going to be tricky, but that’s less a React complexity problem as it is a familiarity problem.

If everyone came from a purescript/fp background the story would be different.

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

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

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.

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.

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

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.

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

The reason is simple.

These guys are really, really obsessed with download counts. They brag a lot about that in twitter every time they have a chance.

What they want to reuse is the package name.

So now they launch whatever bullshit they are playing with now under the “remix” package and the next day they’ll say “look… we have N thousands downloads per second!!! We are so successful”

They did this multiple times. And will keep doing it because they are obsessed with this.

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.

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.

> Why ever change it.

Because e.g. 1) defining routes using React components isn't good idea, because then you have to first render the app before you know which routes are defined; 2) It's useful to be able to specify what data a route needs. 3) React moved to hooks because they compose better; Etc. The APIs were reworked (but only a few times over many years) so they could be better. Software design is iterative and that's what the major version number in SemVer is for.

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.

It mystifies me why Mithril isn’t used more - this sounds more and more like Mithril

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.

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!

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…

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.

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.

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

The funniest thing about GraphQL is when it's set up to only allow specific whitelisted queries. Incredible.

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

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.

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?

What terrifies me about Remix 3 is Remix 4.

That is… I wouldn’t even think about using it because it’s very likely they will change their mind next year and come up with something totally different. Again.

Reply on news.ycombinator.com