What's the big attraction of file system routing?

[unleashit]

I've superficially eyed this project for a while but every time I consider it I get turned off by the default file routing. Why has file routing become seemingly dominant in the React world? Is it really because of the 5 minutes saved by starting without a little boilerplate or am I missing something else? How are the hacky naming conventions, forced file structure, lack of flexibility, etc. better than say traditional React Router with nested routes when needed?

Until recently, I actually avoided Next.js for years in part because of file routing so I'm curious! This project seems to be premised around offering more flexibility which sounds like a good thing, yet it still defaults to file routing (I'm aware there is an option to use a dynamic router, but it seemed there were caveats last I checked). This isn't meant as a complaint or a put down on the project (which seems great), just curious.

[brillout]

What I like about Filesystem Routing is that it gives you a rigid structure. It's Convention Over Configuration.

That said, being able to define the entire Vike interface in a single file is on the radar: #341. Is that what you want?

Why do you have such a strong preference? The more I know why users want something, the better we can prioritize accordingly.

As for flexibility, why do you think it would be more flexible? Do you have concrete use cases in mind? I'm genuinely curious. And, yes, flexibility is a top priority.

[unleashit]

Appreciate the reply and thanks for all of the time you've invested into this. I recently built a smallish project in Next.js, so I had a chance to get a feel for file routing. I can't say I hated it exactly or would die on a hill over a routing pattern, but I guess I just don't get the hype. I agree that structure can be good (people do all kinds of crazy stuff), but at least in my opinion I'd prefer if it were something framework agnostic. That said, I can't speak for Vike but I wouldn't say the overall file structure of Next.js has that much a convention benefit. You can try to colocate everything together in the app directory, but I doubt most people do and they end up having to make all kinds of bespoke structures outside of the routes.

Aside from that, I like the separation of concerns when it comes to routes. Filesystem routing is a touch faster to bang things up, but it weds a lot more to the framework. It's much easier to move a frontend (or a backend) to a new framework without file routing. Lastly I haven't explored this one very far, but it seems a lot less clean to define dynamic routes aside from route segment params, etc. (I think you have to do a catch all, then write a bunch of code on a page.tsx).

Thanks for sending the single file config idea. That seems pretty promising I think! Would it be nestable? One of the nice things about React Router (or an express.js with an express.Router(), etc.) is that you can colocate child routers with sections of the app.

[unleashit]

Thanks for your thoughts. It's pretty apparent my opinion goes against the grain on this and plenty of other things when it comes to the general direction of JS development. Thought I'd reach out to try to understand file routing in particular, because it's not just this project and Next, but also Tanstack Router, Astro and I believe Remix and others too.

Nested Layouts are on the radar... In the meantime see the workaround at...

Cool, looks like you more or less already support them which is the main thing. My only nitpick would be it seems a bit complex, and in an ideal world prefer organizing things a bit differently.

But I disagree with a lot of the current approaches (e.g. recursion-based nesting and component-based nesting are unnecessarily convoluted)

That's a helpful takeaway coming from someone who obviously has deep experience in the area. Could the recursion issue (I'm assuming performance is the concern?) be solved with caching (possibly build time)? Yeah, I also see the downside of the boilerplate you get from components as routes... BUT... I do love the pattern of HOCs as route middleware, especially for stuff like auth. In Next.js I missed that, and also had a dislike of the difficulty of wrapping a group of routes/pages server side (middleware is their solution, but there's no ssr context, codesplitting is always per page, etc.) The latter is going off topic, but one of the things that looked nice about Vike (at least when I looked at it a year or so ago) was it seemed better designed to work with a custom server. On Next.js, you lose some important features.

Anyway, I realize its useless to fight progress. Just sometimes helps to ask the question is the progress really progress I think! I do think overall projects like Nest and Vike are headed in the right direction. Just have some issues with some of the opinionated choices the industry (well two companies in particular... ) has been more or less hoisting on us in recent times.

[brillout]

In my experience, the most fruitful discussions are when users describe their pain points. Only the maintainers can decide what a good design is, because only they have a holistic understanding.

So my question to you is: what's your pain point with the current Vike design? I'm happy to hear critical feedback.

[unleashit]

Yeah of course, I'd agree a lot of things, necessary tradeoffs, etc. aren't obvious to causal users.

Unfortunately I'm not currently in the best position to give much feedback on Vike since I've only casually glanced through the docs. Once I give it a try, I'd be happy to circle back. But for now if you're interested, here's a short list from one person who has been doing SSR React on and off since it was a thing would really love to find in a SSR framework. Vike may or may not already support some of these:

• early http streaming, but with the ability to delay it if needed to set headers/cookies lower in the tree and/or to await a server context
• per route/component choice between islands, server components and something similar to the original Next.js getInitialProps (isomorphic) behavior. Islands are best for 100% static content (no rsc content sent over the wire), server components for serverside dynamic content without external API, old school getInitialProps when it makes no sense to have an extra hop to a "frontend-as-backend" on the way to an API.
• option to disable (or selectively disable) automatic code splitting. It should be possible to configure it so multiple common pages are bundled on first load. Lazy loading is not always a better solution
• declarative routing that supports middleware (3rd party is fine)
• SSG/ISR

The second one is obviously complicated and currently you pick the framework that supports the use case. But many projects would benefit from at least two out of three and maybe all three.

[brillout]

1. Yes that makes sense and that's the plan. I'm actually currently working on these features. The stream is delayed if the page is crawled by a bot so that meta tags aren't delayed.
2. Currently vike-react does old school hydration. The plan is to eventually also have integrations vike-react-server-components and vike-react-islands; the user can install all three and then toggle between the three on a page-by-page basis simply using a setting. Although most users will pick the officially recommended one: the idea is to give expert users the choice while providing a beaten path for users that don't care about these kind of things (yet).
3. Rollup already supports configuring code-splitting, it may already fit what you want.
4. I'm not sure what you mean with "route middleware", but Vike supports route guards to protect one/some/all your pages.
5. Pre-rendering (SSR) is supported, and ISR is also supported over vite-plugin-vercel.

Btw, in case that's something you'd be interested in, contributions are welcome. If you're interested in islands and RSC there is a neat oportunity to contribute. Vike core is agnostic and enables a rich ecosystem of integrations. The vike-react integration is less than 500 LoC.

[unleashit]

It's interesting and cool that you're tackling these things, not to mention across frameworks. The complexity of js SSR is getting pretty insane!

Progressive steaming/hydration is complex but worthy IMO. The charts over at this older post make clear the advantages of both of them together. Side note: I wonder if browsers could eventually offer some native support for inserting the delayed Dom parts?

What I meant about wanting the option to delay the stream wasn't just for head tags (BTW what do you think of [React Helmet Async](https://github.com/staylor/react-helmet-async for meta data) )? But additionally to populate a global context/store that either the <head> or the initial flush(es) might wait for and depend on. Ideally, you'd want to make minimal use of this because it brings back a "waterfall". But in the case of dynamic meta tags, auth, localization, etc. it might be cool to let components add certain promises to a queue that would resolve prior to starting the stream. This old boilerplate had a simple way of getting the relevant promises for the route without having to render React twice: https://github.com/sekoyo/universal-react/blob/master/app/Router.js#L53-L79

I'm not sure what you mean with "route middleware", but Vike supports route guards to protect one/some/all your pages.

That's part of what I meant yes. In React Router what I'm calling route middle might look like (handled slightly different in newest version but close enough):

    <Switch>
      <Route path="/public">
        <PublicPage />
      </Route>
      <PrivateRoute path="/protected" redirectTo="/login">
        <ProtectedPage />
      </PrivateRoute>
    </Switch>

<PrivateRoute> is an HOC that checks auth and returns either <Route>{children}</Route> or redirects. But it could also do anything else.

The anything else might actually be a little on the vanity side, but it can be convenient to wrap a route or group of routes with more than just auth. With a file router, at the least the one in Next.js, you would as far as I know need to use their edge middleware (which has a different runtime, costs, etc.). Anything common has to be repeated for each page. They now have layout.tsx which can wrap multiple routes, but they can't pass props to the pages (and it doesn't wait). In Vike route functions seem the closest thing to "route middleware", but you don't allow async functions in them and (for reasons I'm sure are good but I don't yet understand) they can be a performance bottleneck.

Perfect is the enemy of good though, and I suppose it's always possible I'd fall in love with file routing after using it a bunch. I'm not ready at this point to contribute, but next time I have a small personal project I'd like to give Vike a whirl. At that point I could be in a better place to look at the source code and who knows, if there's something I can add I would be happy to try. In any case it's kind of you to take the time to chat with your users (or potential users)! It's cool you're working on these things.