Yes. There's a continuum of routing needs in React apps. If you're not strictly an SPA, you don't need it at all; the browser already does it for you. For a lot of straightforward SPAs, the most basic "display this component based on current tab" works. Past that, a "real router" is just a small piece of code that looks at window.location to decide which component to render, and a Link that knows how to use the history API.

I don't understand why people bloody their foreheads on react-router. The thing it is doing is simple enough to re-do by hand in any application.

You see the same thing with flux implementations: flux libraries change rapidly, because there's not that much to the underlying concept and it's easy to mess with them. But most apps probably don't need flux at all.

Checkout Next.js (React based framework) if you want to worry the least about routing, and just default to a route per page model.

Next also makes it easy to do server rendering and/or pre-rendering of routes.

You can do this, but routes-per-page with parameters and working back/forward buttons with no serious deps is literally something like 15 lines of code. I think more people should just hack their own router together before introducing a dep for it.

It might be an interesting academic problem to chew on but there's edge cases there with history, route parsing, nested routes etc that are beyond beginner level I would argue. There's something to be said for using a massively popular lib like React Router that the rest of the community is battle testing for you.

* History: on modern browsers this is ~5 lines of code? Pushing URLs with pushState, triggering PopState events, and binding a popstate handler to trigger render changes.

* Route parsing: just use pathToRegexp. Yes, it's a dep, but it's an easy, well-understood one that does one simple thing you can get your head around. Or: don't use route paths with parameters at all (it's overkill for a lot of applications) and just use a trivial switch statement.

* Nested routes: why bother? The routes we're talking about are totally artificial. Having a formal, declarative route system in the first place is already a lot of "engineering". Just define your routes so they don't do that.

My argument is that the hand-hacked system that does this will be approximately as capable, future-proof, reliable and performant as the first production system anyone builds with react-router will be, the learning curve is shorter, the code you're building won't have APIs shift out from under it, and the final system will be trivial to port to react-router once that library stabilizes, if you ever wanted to bother doing that.