[yurishimo]

I think we're at an interesting time for React routing. It seems like a ton of shops are standardizing on Next.js as a base for new projects, especially if you're building a pretty vanilla web app.

Since Next takes care of routing for you, the need for projects like this operating at huge scales is diminishing. I'm glad they still exist for teams that want/need to own the entire application stack, but there are benefits from the community standardizing too.

At my job (dev consulting agency), we're about to embark on rebuilding an in-house framework onto Next.js to take advantage of the larger community tooling and to simplify onboarding of new hires.

React Router has so far made it through 6 iterations, it wouldn't surprise me if v7 was some sort of drop-in plugin replacement within Next. It could open up some areas for more complex navigation requirements without some of the hacky workarounds you need in Next currently.

Interesting times indeed!

[sph]

I'm not sure about that, Next.js' routing is very limited compared to React Router, so much so that I actually spent some time evaluating whether it was worth introducing react-router and skipping Next's half-arsed implementation of a router in a project at work.

I've been very vocal against Next multiple times recently, so I'm definitely biased, but I wouldn't use it for anything more than a basically static web app. Its whole API is very basic, and quite shallow and underdocumented when you need to go a little deeper than "compile this React component into a static html page" and filesystem-based routing.

Not that I'm a fan of React Router either, as they felt they needed to break their API contract five (!) times in a couple years of existence, but at least it presents some surface area and depth in its API if you need to build an slightly more complex app that's more than a static site.

[steve_adams_86]

Absolutely. Next’s router kind of kneecapped a feature we were building out recently and we had to adjust our implementation accordingly.

The router is so deeply entwined with getServerSideProps - we couldn’t find a way, including using shallow transitions, to push to the same path without triggering rebuilding the page due to a request to next/_data which returned the corresponding server side props.

Amongst other things. It’s a wonderful framework, there’s no question. The router is definitely not its strength though.

[leerob]

> Next.js' routing is very limited compared to React Router

What specifically do you find is lacking?

> I've been very vocal against Next multiple times recently, so I'm definitely biased, but I wouldn't use it for anything more than a basically static web app. Its whole API is very basic, and quite shallow and underdocumented when you need to go a little deeper than "compile this React component into a static html page" and filesystem-based routing.

Could you be more specific? Next.js was originally designed for server-rendered React apps, so I'm wondering how you landed to using it only for static web apps.

Especially would love to hear more about what you think is missing from the docs.

[wdb]

Wondering if Remix will be a good alternative for Next

[n42]

Next's router is the only thing that holds me back from fully embracing it. It sucks that I have to give up every other awesome thing the framework offers when I have a project that does not fit with their router. Hoping something changed in the last year and someone can point me to a solution

[Griffinsauce]

I'm curious: what specific problems are you running into?

[dbbk]

Nested routing. It's basically unusable for a master/detail view, which is common in dashboard apps.

[leerob]

Have you seen this? https://nextjs.org/docs/basic-features/layouts

[nsonha]

So just use next with react-router?

[presentation]

Kinda defeats the purpose of NextJS's organization - the filesystem based routing is pretty key to their server side rendering logic and the cornerstone of their sensible defaults for making performant applications out of the box, vs just having a wildcard route that runs React Router - might as well just use CRA in that case, no?

[nsonha]

> might as well just use CRA

Why would anyone use CRA when there is next? Either I write my webpack config, or I use a comercial tool with sensible default, and the flexibility to mix and match single page and SSR in the future.

[presentation]

There are many reasons, but what I was saying is that if you don't use the routing, then a lot of the value of NextJS disappears.

[leerob]

Could you share the reasons you don't pick Next.js? Are you only finding value in the file system routing?

[dbbk]

I'm not sure you can, their router is how they handle data fetching for server-side rendering

[bredren]

What do you think will become of CRA, given next’s growth?