Hoping for some opinions here. There’s a choice between flow router and iron router.
I am kind of leaning towards flow router, mostly because of the functionality of middlewares and FlowRouter.group. Also, meteorhacks seems to consistently make great stuff so that’s in their favor.
What are the benefits of each? Under which circumstances would you use iron:router, and which would be better for flowrouter?
I believe it boils down to:
Thanks @serkandurusoy.
Feature complete is very subjective.
@corvld flow-router is fast and use less resources on the clients by it’s design. We did by improving our API and removing reactiveness from the router.
Difference with IR is listed here: https://github.com/meteorhacks/flow-router#difference-with-iron-router
I spend a lot of time going 30+ routes of my application to flow-router just because I wanted to try it, when finished I realized that I’m using a lot of reactivity on the router so I take the time to pass it to the templates, had other validations did not know how to do with Flow-router so I create few local packages for that, the reason that I don’t turned back is because I’m obsessed by the performance, I was able to improve my code much in publications, routes and templates
I was referring to one of your comments from Should I be using Iron Router (or is it dying)?
Since Flow is new, we will have issues (We have some and we are fixing them) and app designing issues.
and from https://github.com/meteorhacks/flow-router#difference-with-iron-router
Iron Router tries to be a full featured solution … Flow Router is a minimalistic solution …
I definitely did not mean to sound if it is a bad thing. Or not if it is a good thing for that matter. There has been going on a lot of discussion around this exact subject, and I tried to convey the two main bullet points that many people seem to agree upon.
Got it 
…
The biggest appeal to flow-router to me, and I’m surprised iron:router doesn’t have this, is grouping routes. It seems VERY prone to error to have repetition, ie,
Router.map(function () {
this.route('Game.home', {
path: '/game/:gameSlug/'
});
this.route('Player.list', {
path: '/game/:gameSlug/players'
});
this.route('Player.profile', {
path: '/game/:gameSlug/players/:battletag'
});
});
It seems like flow-router has a very handy way to handle this in using FlowRouter.group, which you can apply a prefix to. Does anyone know if there is any way to achieve the same effect in iron:router?
The main reason I switched from Iron to Flow was Flow is UI framework agnostic whereas Iron pretty much requires you use Blaze. With Flow, I can create the project in Blaze and switch to something like Jade or Famo.us without dismantling the core logic of the app.
Are you sure that’s the case?
Check out https://github.com/iron-meteor/iron-layout and https://github.com/iron-meteor/iron-dynamic-template because you can actually switch your layout and rendering engines for whatever you like and keep iron router as a barebones router.
We changed to Flow Router and are very happy with the decision. Performance seems better too.
Another part of our decision was the active part arunoda plays in the community. Seeing the open issues in Iron Router left us wondering about the commitment.
Pardon my ignorance, but when everyone says Flow Router isn’t reactive… does that mean that if a collection changes the views aren’t updated…rendering the whole reactivity part of Meteor useless? 
Nope. What we mean is continuously updating the view (and all its dependents) based on the route parameters.
Flow router prefers leaving reactivity up to whatever gets rendered on a route whereas iron router handles reactivity by a top-down approach where it starts at the route itself.
HMMM… that sounds mighty fine to me, actually. Way more simple!
I’m confused by people claiming that lack of reactivity in the router and the ability to update things in a template as they load is a major selling point in flow router versus iron router. It seems to me that iron router can do those same things too.
If you want things to appear as subscriptions load, then use the subscriptions hook instead of waitOn in Iron router.
If you don’t want things to reactively rerun routes in iron router, then either don’t use reactive variables in the routes, or use the onRun hook to only run things once, or use a template’s onCreated or onRendered hooks to do it at the template level.
Depends on what you want to achieve. For example, if you need to run a process exactly once when a router is run, it is kind of tricky with iron router (although achievable). There are other scenarios where you’ll want to control reactivity.
But again, as @wallslide has also pointed out, iron router is also capable of doing that, only with some extra work which defaults don’t provide.
Furthermore, iron router is more like a full-featured meteor app development framework where you can basically design the whole app within the router namespace. I’ll leave it up to you to decide if that’s a good thing or a bad thing.
In the end, everyone has different preferences and both routers have merit. Both Arunoda and Chris are great devs with enormous contributions to the Meteor ecosystem.
We should be glad we get to choose 
Hi @serkandurusoy,
Like @wallslide I too am a bit confused by Flow router’s claimed differences with iron router.
I think that’s a bit misleading. It’s not extra work at all. waitOn is one option; subscriptions is another.
It’s just a different hook. Literally you do this:
Router.route('/post/:_id', {
subscriptions: function() {
// returning a subscription handle or an array of subscription handles
// adds them to the wait list.
return Meteor.subscribe('item', this.params._id);
},
instead of this
Router.route('/post/:_id', {
// this template will be rendered until the subscriptions are ready
loadingTemplate: 'loading',
waitOn: function () {
// return one handle, a function, or an array
return Meteor.subscribe('post', this.params._id);
},
So I think Flowrouter offers no advantage here.
Also in the Flow router doc it claims
In Iron Router you can use reactive content inside the router, but any hook or method can re-run in unpredictable manner.
but isn’t that too a non-issue? from iron-router guide:
onRun: Called when the route is first run. It is not called again if the route reruns because of a computation invalidation. This makes it a good candidate for things like analytics where you want be sure the hook only runs once. Note that this hook won’t run again if the route is reloaded via hot code push.
You are actually correct, but the problem is the collective
intelligence that’s built around iron router which provides almost
exlusive examples, blog posts, tutorials, boilerplates and example/open
apps all built around the paradigm that starts reactivity on the router
level.
So a typical meteor developer worklow would generally consists of
stripping reactivity off of iron router to achieve the out-of-box
behaviour of flow router.
Also, I’ve had my share of frustration with onRun running multiple
times (twice to be exact) on occasion. It was not a bug per se, but a
kind of misleading lack of proper information around non-reactive route
handling.
All that being said, I’m still exclusively using iron router mainly
because it is mainstream which makes me feel confident I’d be able to
find aid to overcome any problem. Yes, there are outstanding bugs and
feature requests, but non seem to have been a showstopper for me, yet.
But I am kind of eyeing flow router as well. And the main reasons being
its:
Again, great to have freedom of choice
Guys let me jump in: @wallslide @maxhodges
Biggest feature of Flow Router is it don’t take the control of the application. With it’s rendering decoupling and it’s reactive APIs, developers can structure his app as he wanted.
For an example, with Flow it’s pretty easy to build custom loading sections in your app. We’ve built in APIs for that.
And we’ve used a fewer amount of code in the router and it never re-runs. Because of that, we can save unwanted CPU cycles. That’s very important for mobile apps.
FR got quite nice API and I’m happy if someone could implement it on IR.
We are not fighting with IR. What we try to show is another way to structure Meteor apps.
The only problem with flow-router I’ve found (and it’s not even a fault of flow-router) is that so many third party libraries instantly assume you will use iron:router
That’s hopefully going to change and we’ll see quality packages around both, even those that support both!
For example, there’s already this one with 177 downloads: