[HN Gopher] React and Remix Choose Different Futures
___________________________________________________________________
React and Remix Choose Different Futures
Author : surprisetalk
Score : 47 points
Date : 2025-12-01 18:57 UTC (4 hours ago)
(HTM) web link (laconicwit.com)
(TXT) w3m dump (laconicwit.com)
| linkage wrote:
| 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?
| tacker2000 wrote:
| Yea, or Vue or Svelte?
| davey48016 wrote:
| I haven't followed Remix 3 closely. What baggage are they
| taking from React apart from JSX?
| postalrat wrote:
| Why use Solid when the developer experience of Remix 3 is so
| much better?
| davedx wrote:
| > 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.
| dimal wrote:
| 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.
| 0x3f wrote:
| 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.
| codinhood wrote:
| 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
| politelemon wrote:
| 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.
| aloha2436 wrote:
| React itself is still the same fundamental product, not
| something you can say for Remix or Angular.
| Waterluvian wrote:
| 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.
| dobladov wrote:
| 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.
| epgui wrote:
| > 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.
| o11c wrote:
| 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?
| epolanski wrote:
| 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.
| swyx wrote:
| > 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
| lefrenchy wrote:
| 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"
| tacker2000 wrote:
| 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...
| theturtletalks wrote:
| 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.
| jadbox wrote:
| 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.
| tacker2000 wrote:
| 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...
| 0x3f wrote:
| The funniest thing about GraphQL is when it's set up to only
| allow specific whitelisted queries. Incredible.
| no_wizard wrote:
| 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
| hitekker wrote:
| 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.
| 9dev wrote:
| 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.
| d13z wrote:
| 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.
| jakubmazanec wrote:
| This is what they should be 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 make is a must! They told us for years
| that Remix is just React Router with additional framework
| features. That made sense.
___________________________________________________________________
(page generated 2025-12-01 23:00 UTC)