[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?

[presentation]

I do pick NextJS, and I like it - but what I’m saying is the file system routing is critical to other features like static props and SSR, so if you don’t use the file system routing and try to work around it by using react router on some catch all wildcard route, I think you are missing out on a lot of the architectural perks of NextJS. For instance even with new features like edge middlewares, once again its behavior is dependent on using the file system routing.

Personally I actually don’t really like the file system routing, much preferring how route structure is expressed in code with react router (I had set up a system in another project to never have any broken links since page routes were enumerated in a type that links were forced to refer to by TypeScript; I just can’t do that with file system based routing without duplicating and needing to sync paths), but I feel like I’m obligated to use it by the virtue of having chosen NextJS and wanting to make use of its optimization features, so I’m just tolerating that.

Also hi leerob :)