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
I feel like a while back you could just as easily have said this about iron-router and your confidence would have been misplaced.
In terms of the API contract, can the same contract be said about atmosphere? Will that be around indefinitely? Will flow-router work well with Apollo? I don’t think people are too worried about the ability to use flow-router, they are worried about whether it has a future. About whether it’s reasonable to invest in it for the long term. And if not, what should they invest in.
Great question!
So would I move to React?
But have alternative for AutoForn, Tabular.. for React!
First I’ve heard that Iron-router is broken. Apparently my app didn’t get the memo. We are using Iron-Router in a mass audience eCommerce app running on the latest version of Meteor.
3 Likes
Then do something about it. How about if everyone who is using Flow Router contribute $30 per year to a FlowRouter maintenance fund. I’ll manage the fund and ensure that the funds are spent to keep FlowRouter working with Meteor. You guys can complain until the cows come home that someone else isn’t solving your problems.
One of my apps uses these package (below). I wouldn’t be surprised if 80% of them are no longer being maintained, but that hasn’t stopped us from running a business which serves thousands of customers in over 100 countries.
underscore@1.0.9
less@2.7.5
http@1.2.9
email@1.1.17
accounts-password@1.3.0
accounts-ui@1.1.9
jquery@1.11.9
reactive-var@1.0.10
reactive-dict@1.1.8
amplify
random@1.0.10
promise@0.8.4
ecmascript@0.5.8
react-template-helper
# Community packages
# =======================================
255kb:meteor-status
maxkferg:bitly
dferber:prerender
aldeed:template-extension
nemo64:bootstrap
aldeed:autoform-select2
#natestrauser:select2
aldeed:autoform
aldeed:collection2@2.3.3
lepozepo:accounting
useraccounts:bootstrap
useraccounts:iron-routing
raix:handlebar-helpers
meteorhacks:kadira
cottz:iron-query
tmeasday:publish-counts
manuel:reactivearray
wylio:mandrill
abhiaiyer:meteor-twilio
natestrauser:animate-css
pfafman:font-awesome-4
mizzao:jquery-ui
benmgreene:jquery-sparklines
chrismbeckett:toastr
iron:router
momentjs:moment@2.9.0
#enteye:spinner
sanjo:jasmine
anti:fake
konecty:mongo-counter
msavin:mongol@1.0.8
matb33:collection-hooks
meteorhacks:ssr
zeroasterisk:throttle
zeroasterisk:throttle-accounts
#okgrow:analytics
gadicohen:reactive-window
meteorhacks:async
peppelg:bootstrap-3-modal
edgee:slingshot
peerlibrary:aws-sdk
#nolimits4web:swiper
meteorhacks:fast-render
gadicc:blaze-react-component
msgfmt:core@2.0.0-preview.21
msgfmt:extract@2.0.0
msgfmt:ui@2.0.0-preview.11
msgfmt:react
manuel:viewmodel
force-ssl@1.0.12
# Our packages
# =======================================
whiterabbit:cloudinary
whiterabbit:filedrop
whiterabbit:saasu
whiterabbit:flot
#whiterabbit:clientstripe
whiterabbit:stripe
whiterabbit:shared
whiterabbit:cart
whiterabbit:statemachine
whiterabbit:winston-papertrail
whiterabbit:helpscout
whiterabbit:paypal
whiterabbit:jspath
whiterabbit:select2
whiterabbit:phoneverification
whiterabbit:referrals
whiterabbit:slack
whiterabbit:s3functions
#whiterabbit:capture-webpage
#whiterabbit:phantomjscloud
whiterabbit:diffbot
whiterabbit:wre-products
whiterabbit:package-forwarding
# Anti packages
# =======================================
anti:modals@0.4.0
#velocity:html-reporter
#meteorhacks:zones
#npm-container
meteor-base@1.0.4
mobile-experience@1.0.4
mongo@1.1.11
blaze-html-templates@1.0.4
session@1.1.6
tracker@1.1.0
logging@1.1.15
reload@1.1.10
ejson@1.0.12
spacebars@1.0.12
check@1.2.3
standard-minifier-css@1.2.0
standard-minifier-js@1.2.0
shell-server
2 Likes
Went through all the postings - another gloom and doom post
So @diaconutheodor mentioned in another post that he coule handle flowrouter. We’ll help him likely.
I wouldn’t say that Blaze is dead (are you watching the repo?) but certainly Vue with its router can become a solid option. If and when …
And if you are watching what’s happening with redis-oplog you should be getting super excited. Other than rethinkdb (which is dead) or building your own stack, we are talking very solid scalability of reactive apps!
My concerns are elsewhere
- Maintenance of the mobile infrastructure - the built-in webserver and the build framework
- The build tools - it has to download binaries every time there is a meteor update. We need to replace with locally compiled ASAP to reduce reliance on core devs – WHEN DO WE MOVE TO NPM?!
- Managing the community - sorry to say, despite my and others’ best efforts, the steps taken by MDG are not sufficient. Maybe get some one else to lead this from MDG side?
2 Likes
Yet another abandonware. What if MDG takes over this project, there is no in-core/base package about routing for Meteor though.
That was kind of my point with my earlier comment
I’m not a very good developer but I try to contribute by digging as deep into issues as I can: https://github.com/kadirahq/flow-router/issues/551
I’d be more than happy to contribute $$ to a fund to keep flow-router alive, or bug bounties on issues relevant to me and others.
1 Like