I have yet to reach the limits of doing a Vite create and installing react router myself for the several entirely client side apps we manage. It has sane build defaults and for whatever definition of ‘works’ is possible in JS, ‘just works’. If it becomes too complex for that basic setup it usually means we’ve over-complicated something.
Where we have a need for server side, nodejs just never felt natural for us so we stuck with java springboot or flask/fastapi as appropriate.
ever since react router got merged with remix to become react router v7, I looked around for simpler version, landed on Wouter which is fine.
I'd love to hear more about what motivated the switch. All the additions to react-router are, afaict, opt-in. React-router has 3 "modes"[0] and the declarative mode seems pretty much exactly what the classic library is like with some extra components/features you don't have to use
Thought I've enjoyed the code-splitting and access to SPA/SSR/SSG/etc strategies that come with the "framework" mode
[0] https://reactrouter.com/start/modes
I'm using the React Router v7 in framework mode, fetching data directly from the database in server-side components. So far, it works reasonably well as long as we avoid mixing server code with client components. However, although it offers the convenience of writing frontend and backend code together, the mental burden added by this approach makes me feel it is not worth it more and more often.
Yep, declarative mode is what I use, tried the data mode with loaders and it never really agreed with me as a pattern.
I’ve been using Wouter on multiple medium sized projects for 3-4 years now. I’m never going back to react-router if I can avoid it: a hellhole of API churn and self promotion
Dang, looks like wouter does the same thing as react router v6+ and nested routes don't get all params / paths of the route. ~~Also doesn't have react router v5's route-string typescript parsing.~~
https://github.com/molefrog/wouter?tab=readme-ov-file#route-...
> Also doesn't have react router v5's route-string typescript parsing.
It does, assuming you're talking about automatically parsing "/foo/:id" and getting a typed "{ id: string? }" route params object out of it? Wouter does that when using typescript.
Thanks for the correction, after looking at the types I'm guessing it's this bit: https://github.com/molefrog/wouter/blob/v3/packages/wouter/t...
Yep! That's the type. It used to be a lot more complicated if I remember correctly, but looks like the author is importing a type from that "regexparam" package to do it now.
I've been using wouter in all of my projects for years after being burned by some react router migration bullshit eons ago.
TanStack is the sane option here, whether their router or their start product.
wouter is great until you need hash routing and then it's shite.
I’m kind of agreed on this but — many times now I’ve also wanted static site components in my app too, and in a standard express+react app that gets awkward.
I think there must be a better way. I don’t think it’s next.js and I’m not convinced it’s Astro either. There’s still room for new ideas here, surprisingly