Nothing and everything. Both work and both have their bugs. But if you have no qualms adopting unmaintained libraries as a central part of your application(s) then there is absolutely no issue with using either of them.
1 Like
This actually sounds like a much better idea but I’m not understanding how this would work. Sorry I’m a bit noob. To my understanding the routing options in Meteor that aren’t client side only send to client what you tell it to render, not the entire meteor application like FlowRouter or IronRouter do. Is it possible for me to grab any router of NPM and render my entire meteor application properly with my template components and everything?
We’ve been using IronRouter for more than a year in a very complicated application and have not run into any bugs.
3 Likes
I’ll give you that not all of these are bugs, but plenty of them are issues that people have run into. When selecting an unmaintained library you need to know that these exist, and are not going to be addressed by a maintainer. If that’s not an problem then go for it. But personally I don’t think a community should advocate the use of an unmaintained library. So in the context of the question that is important.
1 Like
This is the key point. Everything, including Meteor itself, is now “abandonware” unless ppl step up and take ownership of the tech. The days of MDG working on anything non-Apollo related are (almost?) over. Nothing will improve unless the community contributes, this includes: Blaze, DDP, Livedata, Tracker, Minimongo, etc. And of course once popular packages such as Autoform, FlowRouter, Iron Router, MUP, etc., are now abandoned and stagnant. Even Atmosphere has a limited shelf life.
So we have to change our direction to React.js, React-Router and Apollo and lots of new technologies?
So really what reason remains to use Meteor?
At a time when a large number of Meteor.js stack technologies are outdated or are dying and lots of contributors left the stack and on the other hand very hard deployment without Galaxy. (For example I’m in a country that can’t transfer money to MDG for Galaxy and because of this I have many trouble with Meteor.js deployment)
So I think we can use React.js and GraphQL and Node.js or if we want stay on Meteor we forced to switch to React (and React-Router) or Angular + forced to pay money for deployment to MDG.
It’s a bad situation for my small start-up company. 
I agree with this. If you’re going:
> React => react-router,> Vue.js => vue-router,
> Angular => who knows,> Blaze => FlowRouter.
That’s about all your options atm.
1 Like
I’m quite happy with the decisions we made. We used Iron Router because FlowRouter hadn’t been invented yet, so we didn’t really have a choice. Therefore I can’t say I regret the decision.
I do wish my app was in Semantic-UI instead of Bootstrap, but two years ago when we started I didn’t know Semantic-UI, so buying Homer–a Meteor-ready Bootstrap theme–was probably the right decision at that time.
What decisions are you regretting?
Why shmuck? We’ve done it all in-house so far. Anyway, we haven’t had a compelling reason to migrate the routing package from from Iron Router to Flow Router. We could spend some time doing that, but what’s the payoff?
If I had to do it all again, sure, I’d use React-Router, but we started building that app a couple years ago.
I think the real risk is that some new version of Meteor will introduce a change which breaks Iron Router. In that case, some team, like us, who is using Iron Router for a mission critical app will investigate the issue, commit some patch, and get back to business. That’s how the community has always dealt with breaking changes for as long as I’ve been involved with it. So I just think all this talk of “the sky is falling” because the primary devs have abandoned these package is a false narrative.
It’s all open source and it’s all just code. You can make it do whatever you want. Heck, if the next version of Meteor broke Iron Router, we could just pin our app to the current version and run on that version of Meteor for a dozen years. There is always a way!
According to @sashko the only reason why FlowRouter would break post-Meteor v1.0 would be a bug in a new version of Meteor.
10 Likes
React is just a framework for UI components. Meteor can provide the data flow layer. We did a few Meteor/Blaze apps, and now we are wrapping up a Meteor/React app. Moving forward I’d be happy to use the Meteor/React stack again, but we’ll probably try Apollo and see how that goes.
1 Like
Obviously the topic question posed gets at something deeper than the title alone suggests.
MDG has talked a lot about what they will and will not be doing on Meteor moving forward. It’s clear they are trying to foster the community to take a more prominent role in developing the platform itself. They are driving those efforts and we will see where it goes.
Ultimately whether that succeeds may not even matter if the community doesn’t also step up to foster the non core ecosystem as well. So we need to ask ourselves:
How should we as a community address the FlowRouter situation?
Is it important enough to attract some maintainers?
If so how do we as a community look for maintainers and make it easier and more palatable to volunteer in such a way?
@arunoda Do you think the these packages have a future or should the community move on?
Should the community fork or try to takeover the existing repo?
If the former, should we keep the same name or change it?
If the latter, what restrictions do you have on handing over the keys?
3 Likes
No problem, I could pay if for you. PM me. If you pay me by wire transfer, bitcoin or PayPal, I could setup a Galaxy account on your behalf.
that might not matter, especially if new contributors are joining the stack faster than contributors are leaving the stack. 
A couple years ago I could only find a handful of Meteor devs. Recently I posted a job on weworkmeteor and got 50+ applicants in a few days–many of them look pretty good!
Thanks man 
. If my company decision is to stay on the Meteor.js surely we will use your help to buy a Galaxy account.
We want to make sure that we use maintained library and stack because we have a small start-up team with basic level and many times when we faced a bug on a library we only can wait until other guys fixed it and when we choose unmaintained library it’s increase my project risks.
For example recently we use nikw Meteoric and it has many bugs and unfortunately became discontinue then I switched to joey(Meteoric124) Meteoric version and It’s more better but again it’s discontinue too and now we try to switch to OnsenUI 2. So we write my mobile UI 3 times.
We don’t want to add more risk again and write my routers again and again and again because we choose a wrong library that unmaintained, outdated and full of bugs or open issues.
So I really agree with this.
1 Like
While all this is true, an app needs a router.
Its such an essential part of an app, and now Meteor has 2 that are not actively developed anymore.
Who knows, Meteor 1.5 might just break Iron or Flow Router, who is going to fix your app then? I wouldn’t start building with either router anymore.
I think the only sensible solution is if MDG starts maintaining Flow Router (which is already their ‘official’ routing solution, see docs), making sure it keeps working with upcoming Meteor releases. It’s a win for the community and for MDG. It will make sure not all devs leave Meteor behind.
3 Likes
This is the nature of projects, its not unique to FlowRouter/Kadira. For any given library/framework you use -
- it will be replaced by a new hotness in a few month/years
- it might get abandoned
- people may move on to something else
This is esp true in JS where there’s something new every week. The goal of open source is to encourage contributions or fix bugs yourself, otherwise you’re just using the product like a blackbox.
e.g. ReactRouter/Redux/ReduxSaga etc are also community maintained there’s no guarantee that if something else is popular in 2017 then they will be maintained.
This is also why many teams stick with bigger, more opinionated frameworks like Ember/Angular which may not be as attractive technically but offer users some stability and support. Although Angular is probably a bad example 
I think its pretty clear MDG doesn’t have resources to spare and have a lot of other priority tasks.
Or maybe it won’t break your app! Since Meteor v1.0 there’s no reason why a Meteor update should break FlowRouter. I wouldn’t choose IronRouter for a new project, but I’d absolutely use Flow Router. I’ve been running Meteor production apps since 0.6. There have been many break changes along the way, and we’ve always found a way around them. There are a lot of people using Flow Router. If there is a breaking change, I’ll bet dollars to donuts someone will come up with a solution in short order.
But yes, that’s a great idea: MDG should officially maintain Flow Router. They’ve always left routing up to the community, and the community has delivered some great results, but if a new version of Meteor breaks Flow Router, MDG should ensure it’s patched. What do you guys think? @debergalis
3 Likes
I see, and I sympathize with your situation. I think the more popular packages in wide use are more likely to get patched by the community, so in the case of Flow Router I personally would not hesitate to use it for a new Meteor/Blaze app. I’m very confident that someone would fix it, because too many people depend on it.
But, yeah, in the case of meteoric124/meteoric, a package with only 22 stars, there is more risk when there is only a small number of active users.
Rather than re-write your UI three times, how about if you just hire someone to patch the package which you depend on? Wouldn’t that be cheaper? There are dozens and dozens of Meteor devs on WeWorkMeteor. If your team doesn’t have the experience to maintain that package, wouldn’t it be more cost-effective to pay someone for a few hours of their time to help you out, rather than re-develop your entire UI using a new framework?
2 Likes
I disagree with this. It’s only true for big team or expert people. Someone like me and my team with lower level that switched to meteor recently can’t fix FlowRouter, Meteor, Meteoric, MUP or … . And It’s not possible for many of us.
At that time meteoric124/meteoric was the only active fork of meteoric/meteoric (nikw version) man and we haven’t any other choice in Blaze world. I think history going to repeat and now FlowRouter going to shrink to many fork then stars and active users split to some groups and it’s possible to dead project after some times.
My situation a little hard to explain man. I told a little later to you. We can’t transfer money from my country so we can’t use tools like WeWorkMeteor and hire someone for these type of tasks and here we need the most robust stack for developing.
Maybe still FlowRouter is the best choice for you but for me and my company until now in this topic I prefer to switch to React and React-Router based on @awatson1978 advise.
But I’m still waiting some days maybe someone can introduce a better solution in Blaze world.
1 Like
@sashko can you explain here how since Meteor 1.0 people can depend on FlowRouter due to Meteor’s API contract? Many people seem to think FlowRouter can no longer be trusted.
1 Like