React can do SSR today.
It also can do fancy pinterest style routing out of the box.
For me though, it was the fact that there are hundreds of youtube videos on ReactRouter. I could only find two on FlowRouter, and honestly couldn’t understand half of what the guy said due to a very thick accent.
I want to know something is going to still be supported a year from now. There is no one guy who can get hit by a bus and suddenly ReactRouter stops being supported.
As can FlowRouter AFAIK: The trusted source for JavaScript packages, Meteor resources and tools | Atmosphere (I haven’t tried it however, as I’m developing for Cordova, where it isn’t a consideration).
I take your point about long term support, but the @arunoda is pretty committed to this and related projects, and lets be honest, how many of the packages we use are supported by a company or team vs. an individual, and what’s to say a company doesn’t drop support for something in the future.
And being open source, even if that were to happen, someone could, in principal, take over development. (Doesn’t happen very often in practice, sadly).
There are almost as many routers available for React as there are Flux libraries. It’s just that ReactRouter has won the day.
In terms of the FlowRouter dev’s level of enthusiasm there is no doubt, and it looks quite polished. However, from what I can tell the IronRouter dev was enthusiastic too.
Just got here so didn’t bother to read up on what actually occurred with ironrouter. I just looked for alternatives. Instead of jumping out of the frying pan into the fire, I merely chose a more sustainable option.
I would really like Atmosphere to list the last commit date and current PR count along with the installs on the package cards. That would help a great deal sorting through them all. I currently have to click through to the github repo on each package I look at.
I don’t disagree that ReactRouter is defacto standard in the React world, so if I’m not losing out on anything FlowRouter offers by using it (and it doesn’t bring bloat with features I don’t need), I’d certainly consider it.
The pinterest style routing looks neat if you need it, but overkill for most projects. And while watching the React Router experts in that video struggling to get their demo working was quite amusing (and they handled it very well), it hardly inspires confidence. (Although the dynamic code loading does sound very cool for large web projects).
Regarding lack of videos on FlowRouter - I’d consider that an endorsement of how easy FlowRouter is to get started. 
Hah that earned a like.
I actually prefer video tutorials these days over anything outside of IBM documentation. You get to understand what the guy is thinking. You also as you pointed out, get to see them realtime encounter and solve problems you are likely to run into.
Nesting is never a problem in Meteor routing. With FlowRouter, you can have different kind of layouts for each router.
By doing that, you can build any complex nesting feature.
You can do some cool stuff like this as well. See: How to pass reactive data to children using Flow Router and React Layout
@arunoda, thanks for explanation, but your example is not working.
I’ve tried something like:
FlowRouter.route('/demo', {
name: 'demo',
action() {
ReactLayout.render(Layout, {
content: <Content />
content2: <Content2 />
});
}
});
then in Layout component:
render() {
return (
<div>
<LayoutHeader />
<main role="main" style={ styles }>
<this.props.content content={ this.props.content2 } />
</main>
<LayoutFooter />
</div>
);
}
But, as I remember it always throw something like:
Uncaught TypeError: type.toUpperCase is not a function
It would be nice if you did an exploded description of nesting principles in your guide, because now it is not obvious
In your example, in the router you need to change <Content /> into Content. It should work (I tested).
I ended with this React.cloneElement (you can pass the params from router action, like :title or smth else as props and add another props from the layout layer (user)):
router
FlowRouter.route('/admin/permissions/:title/edit', {
name: 'admin.permissions.edit',
action: function (params) {
ReactLayout.render(Layout, {
content: <PermissionsEdit title={params.title} />
});
}
});
layout
Layout = React.createClass({
mixins: [ReactMeteorData],
getMeteorData() {
return {
currentUser: Meteor.user()
};
},
render() {
let content = React.cloneElement(this.props.content, {
user: this.data.currentUser
});
return (
<section className="admin">
{content}
</section>
);
}
});
But, you can use your variant, just remove the < and />.
Excuse me, but during our tests we had those sometimes too. Just a silly question: have you named your router.jsx so with extension for ES2015?
See my example here (at chapter: next goal): Smoothly feature up your Blaze Apps with React Components
Hello, I’m using universe:modules, so my routes file called routes.import.jsx
If you are interested, just now I’ve tried to do so:
action() {
ReactLayout.render(Layout, {
content: <Component1 content2={ Component2 } />
});
}
and it works as expected which is amazing 
Puh … this looks a bit scary to me, even that this is currently functional for you I wouldn’t use it.
Look at this short question on Github to @arunoda – so I would suggest to use FlowRouters options elements at least, like:
FlowRouter.route('/path/', {
Content1: <Component1 />,
Content2: <Component2 />,
action: function(params) {
ReactLayout.render(Layout, { });
}
});
Not sure if something like this will work for you but you may access those options via:
{ FlowRouter.current().route.options.reactComponent() }
Just my 2cents
Tom
I really hope it is featured in core, I really like FlowRouter. It’s the perfect setup of features that makes it very easy to use
Yep, the Meteor Guide is going to be built around Flow Router.
Hi @arunoda, thanks a lot for your awesome work with FlowRouter. I’m curious about one very specific use case that is very important for modern apps in my opinion: Transitions.
Currently with routing the issue is that you immediately swap out content upon requesting a new route. In order to be able to properly transition between two pages you need both contents/pages available at the same time, which currently is not possible with FlowRouter. (I’m not just talking about basic fade-animations here, material design like animations where one element might fade to become a new page)
I’ve been hacking together my own version of this (not as a package), it’s still a bit buggy though. Do you have plans for making this possible in the future?
I’m really not sure how to do transitions. I’m not an expert. It’ll definitely not going to be on FlowRouter. It won’t deal with that kind a stuff.
But, I can see it might need some help from BlazeLayout or ReactLayout. In react, I assume it does not need any support at all. Try to see how Reapp does it.
I’m open to suggestions and help.
You can use React Animations, they are easy to use.
Here is the package, showing, how this can be done with React-router. I don’t think it is too hard to create a package with the same functionality for Flow Router.
You don’t need to do the animation package/functionality yourself. Imo the only thing to do proper animations/transitions is to have both routes available at one point instead from FlowRouter. Right now you have:
It should be like this:
The way I’m doing it right now is using two different dynamic templates and always keep the current and new route in my document. Or that’s how I used to do it. It worked, just had a few issues with how I programmed it I guess. I’m not sure how easy it would be to help out with FlowRouter.
Specifically in my use case I’m using Polymer for page transitions. You have something like:
<neon-animated-pages selected="0">
<page-one>currentRoute content</page-one>
<page-two>newRoute content</page-two>
</neon-animated-pages>
And you swap the content when needed. But with FlowRouter something like this doesn’t work because you only can have one route-view active. Essentially what is needed for this approach is to keep the old current route until a transition has been finished (then removing the entire template from the DOM would be the best case of course.)
Here’s a sample animation showing why this is necessary. To do a smooth transition that goes from element a to element b you definitely need them both available in the document. (click on any of the rectangles)
So, you need to both the old route and new route. So, pause the routing until the animation is complete and then resume the route.
If that’s the case, I think that’s not something we can do. Since FlowRouter does not wait. I always think this can be implement as a special animation component. Where it tracks all the template changes and do transitions. So, router is only just a trigger.
Then 98? lol Sounds cool!