I haven't really given the routing issue too much thought regarding ReactJS.NET. I assumed it would work just as well as my isomorphic apps in NodeJS; one route

I haven't really given the routing issue too much thought regarding ReactJS.NET. I assumed it would work just as well as my isomorphic apps in NodeJS; one route in server-side land that handles all URLs and returns a View that contains the server-side rendered React app. I maybe missing something for why that wouldn't work in ASP.NET land but like I said, I haven't worked with it that much. react-router is all right and they've got server-side rendering working but it's still missing one very important facet that is required for most isomorphic apps; the initial server-side render should be capable of fetching whatever data is needed is fully render the page. Right now the best you could do is deliver a page with a spinner if the page requires some data on the initial render. Andrey Popp's react-router-component solved this issue by using react-async which uses fibers to allows for getInitialState to work asynchronously. The react-router guys think the "fibers stuff is stupid"[0] but they're still working on their own solution to the problem. The only reason I'm still keeping tabs on react-router instead of abandoning it for react-router-component is that it doesn't look like Andrey Popp's is going to be maintaining react-router-component and react-router seems like the only other game in town when it comes to routing in React. [0] https://github.com/rackt/react-router/issues/57#issuecomment-49193293 https://github.com/rackt/react-router/issues/57#issuecomment... P.S. I don't know that much about node and fibers to understand why fibers is stupid but it solves the problem and from what I read about fibers, it seems like the node community just don't like it because it resembles threads and they don't like threads in node.