Remix (cough react router 7 framework mode cough) is like the polar opposite of this, it's just a Request -> Response handler that you have to build your server around manually. Which I found kind of annoying at first but it does give you the freedom to do what you want.

▲

adamddev1 5 days ago | parent | next [-]

I have been frustrated with Next.js changing it's API so much in the last few years and making things more and more complex and confusing.

I am wondering about giving Remix a whirl for an upcoming forum/CMS rewrite with custom auth. Anybody else have experiences with Remix?

▲

eknkc 5 days ago | parent | next [-]

If you don't like changing APIs I'd stay away from the Remix guys. I know it is not like Next but I've used react-router, which had some API churn, later evolved to remix and then back to react-router... Backward incompatible changes are the signature of it. The documentation story is a problem too because of that. Completely different things are named the same and they are now building a new Remix, not even on React as far as I can tell.

Stick with a single version and you'd probably be happy though.

▲

chrisweekly 5 days ago | parent [-]

While the "Remix" renaming / branding is a little confusing, the React Router team has always done a fantastic job delivering a robust solution that properly leverages the web as the platform. Its framework mode (fka "Remix") is simpler and better than Next.js, and more featureful than vite-ssr. Want to mutate data? Use a form. Fetch data? Uses browser-native fetch under the hood. It's all about the fundamentals: HTML and HTTP. You can decide how much clientside JS to ship, and mostly eliminate it. OR, if you want a traditional SPA, go for it. A quick HN comment thumbed on my phone can't do it justice -- but it's very, very good. And its maintainers have a stellar track record. (No vendor bias like w/ Next.js / Vercel.)

FWIW, I've been doing webdev-related work for a living since 1998, and React since 2016.

▲

agos 5 days ago | parent [-]

their issue with breaking changes is from way before the Remix days - React Router introducing massive breaking changes at every major that required significant rewrites was already a running joke of the community

▲

avdwrks 5 days ago | parent [-]

Their documentation was also abysmal the last time I used their product.

	▲	Culonavirus 5 days ago \| parent [-]
		YMMV but the current docs seem fine to me. Though it was pretty bad during the Remix -> RRv7 transition. You can also learn a lot from their github activity (proposals/rfcs/issues). API docs have some additional docs too. New devs coming in and expecting the framework to be with "batteries included", which it absolutely is not, will also have a bad time. Node apis, ALS/context, handling app version changes on deploys, running the server app itself (if in cluster mode, e.g. with pm2, what that means in terms of a "stateless" app, wiring up all the connnections and pool and events and graceful reloads and whatnot...), hell even basic logging (instead of console.xxx) ... all of that is up to you to handle. But the framework gives you space. People new to React and/or Node will be confused as hell for quite a bit... in such a cases I would add like 3 months of personal dev time and learning to just wrapping your head around everything... React docs themselves say that you should use a framework if you're using React in 2025 - but it's not that easy. There is a cost, especially if you go the full stack route (client + server + hydration) of having everything under one "typescript roof". The payoff is big, but definitely not immediate.

▲

b_e_n_t_o_n 5 days ago | parent | prev [-]

I used it with Shopify's hydrogen framework. Wasn't a huge fan of hydrogen but Remix works fine, it mostly just got out of my way and worked. Dependency injection was trivial :)

▲

Culonavirus 5 days ago | parent | prev [-]

RRv7 is great. It does the heavy lifting of what you'd use this kind of framework for in the first place (one codebase in one language - typescript - one "stack"/lib tree - that does both the server and the client rendering), handles routing, route modules, code splitting, bundling, etc. etc.

Having to know node (or other supported server) and needing to implement your server business logic from scratch (models, db access, caching layer with redis or something, etc. etc.) is not a weakness, it's a strength.

The thing that .net tried to do for like a decade and failed to (one stack for both the server and the client), see Blazor bullshit etc. is handled here. Imagine you need a modern web app or a shop or whatever and that means React. It just does. Your backend stack is PHP or Rails or Go or whatever. Now you have to somehow square the hydration circle which you can't do without it being a massive pita (as PHP renders a page on the backend in.. well.. PHP) so you end up passing the data manually in some blobs of jsons or whatever with each request (or even worse, side to it in some fetches) that then React initializes from on the client and it's a total mess. Not to mention that unless you render the page in both php and react (try to keep both outputs the same lmao), you'll only see the full app "on the client" meaning crawlers/bots/google have to run JS on all your pages or see nonsense ... yikes.

SSR with hydration is there for this reason. You render the same React tree both on the server and on the client. The hydration process itself is made much easier by RR and its infrastructure (automatic passing of data to the client). Hell, thanks to SSR you don't even have to have JS enabled on the client if you're using just basic web standarts (see RRv7 docs on progressive enhancement and state management) and the site will work. This means even crawlers without JS runtimes will be able to index your site.