I've experimented with it. I think it's a great solution if you really want to stay with a uniform stack (as much as is possible, anyway). What I came to realize, though, is that the Razor views were just scaffolding. You would need to re-implement any such scaffolding in your client-side views. The next problem is the router.

Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers. Many Node solutions will use different routers on the client and server, but there are a growing number that can be shared.

The router is my biggest stumbling block right now in my road to React. There are a variety. There seems to be a consensus around react-router, but now we have the Yahoo contribution. There are two problems that I'm having. The first is that, if you want to use HTML5 History (instead of the dreaded hash bang), you're kind of on your own. There is usually little documentation on how best to handle this. If you do this, you have to intercept and prevent navigation, but only for the relevant local routes, of course. This is intimately tied to eventing. If you're using React, you'll probably use React events (vs, say jQuery).

The next issue is that most of the examples out there are simplistic. They will show a simple page with one component embedded that swaps out a part of the view. Any real app will require layouts, views, and components. Some of these levels will vary based on routes. ASP.NET has an elegant solution for this. I haven't seen an analogy with React + router.

I think part of my problem is that I'm still ramping up. I'm guessing that this is largely teething pains.