I’ve been developing with Meteor since last Fall and have LOVED it. Props to the MDG team for their awesome work.
I started my Meteor journey by following the Discover Meteor book tutorial. This was my first introduction to Iron Router. I have built quite a few apps with Iron Router, and it seems to work well. However, I’ve seen a number of posts on different sites all stating that Iron Router is no longer being maintained and that it would be better to switch to something like @arunoda’s Flow Router. Normally, I would just wait around and see which router survives. However, I just started working on a product for a law firm that they will be selling to other law firms and I don’t want to use something like Iron Router if I’m going to need to rip it out and replace it in a few months. I’d really appreciate it if someone (who is more “in-the-know”) could address this question for me. Thanks!
Virtually every meteor app uses iron-router. I think it’s fair to say that iron router is the standard path. If you like to be on the leading edge, maybe flow router would be better, but expect the issues that come with being on the latest. FWIW, i suspect the meteor community can support multiple routing packages.
@andylash@arunoda Ok, so if I am to read between the lines (given that neither of you said anything about Iron Router dying), it is safe to say that talk of Iron Router going to the wind is premature and not true. Is that a correct assumption?
IR will work as it should work today. Meteor won’t have any major changes sooner (I hope)
So, if your are happy with IR. You can happy with it in the future projects too.
Both Iron and Flow I think are viable options at this point… Iron isn’t going to die anytime soon, the devs are just kind of busy at the moment. As far as routers go though, I think there needs to be some major discussion around improvements. Ideally for me a router would incorporate both client and server side routing while handling the server side rendering as well as action routes for forms… This would enable JavaScript to be completely turned off and your application to still function, because unfortunately there are still users out there that choose to disable JavaScript and a well integrated router would give us this small piece of progressive enhancement by default. React Router handles all of this so it’s definitely possible, but I think for Meteor this might require some modifications to things such as the core boilerplate-generator package. I can’t say for sure since I’m not an expert on how Meteor’s internals work, maybe @arunoda can comment as he has a bit more knowledge in this area.
Also, the way it looks to me is that iron:router is mostly very much feature-complete from a general needs perspective, and very widely used, so it doesn’t necessary make too much sense and there isn’t as much need to actually keep pushing the code in new directions / extending it that much further. It is mature, it works, it’s not really going anywhere (which I don’t mean in a negative sense), it certainly has a couple of caveats (like the reactivity thing) that one needs to be aware of and handle appropriately, but other than that it’s solid and should be supported and maintained for quite some time to come.
It’s so wide-spread and popular and ubuquitous in terms of coverage in tutorials and books and in the community overall that it’s going to take quite a while and a really really good alternative package for it to take any kind of dip/dive in any production-worthiness sense.
That’s really great.
But I don’t understand why chris believe in this:
In the mean time I don’t see why starting a router from scratch makes a lot of sense
Flow has fundamental changes and restrictions on how things will be. That’s why we started it.
That’s how open source works.
You can’t stick with one single solution all the time.
@ryanswapp I used to use IR, but i switched to FR and things got much easier. If FR wasn’t there I would be happy to use IR. I used it for a while and 60% of the time I liked it - it’s a decent package. The main thing I like about FR is that it is lightweight, and lets me separate how my app worked into more distinguishable pieces. Perhaps it was the design pattern based in FR that made me learn this.
IR: One thing I couldn’t stand was seeing “ROUTE /post RAN; ROUTE /post RAN” in my console. No computer - I am pretty sure I clicked the link once
This was my fault, however, not IR’s. It was my fault that I did not pay more attention to how the reactive components were working together. Imho, IR is not beginner friendly because it requires a pretty good understanding of reactivity, (mostly how they implemented reactivity) if you want to minimize stuff like this ^ With FR I don’t spend any time trying to figure out why the heck my route did X.
FR’s documentation + google + github issues was entirely sufficient. And the IR tutorials cover all of IR except the problematic part.
I can only comment on my experience:
With IR, there were too many tutorials and fact-sheets that all said different things about the same thing, and then didn’t cover the issues soaked in the relatively complex reactivity scheme that was going on. this.route? Or maybe Router.map? Or maybe this.map? Ah, it’s got to be Router.route. I don’t even know how many there are anymore.
Joking (but it isn’t wrong - that confused me the most in the beginning). I actually found IR’s syntax to be really nice, once I got the hang of it. Maybe that’s the reason why FR was an easy transition. All I know is that when it came time to test everything, FR was a lot easier, because it just worked.
