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.
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.
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
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?
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.
@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.
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.
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.
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.
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?
I don’t know why people keep saying that. MDG has a huge investment in Galaxy. Galaxy is a PAAS for deploying Meteor apps only. Under these circumstances it appears to me that there is no way MDG is going to abandon Meteor.
Apollo is the #1 thing Meteor needs right now because it brings access to mySQL, Postgres and other databases. It makes total sense for MDG to focus the majority of its development efforts on Apollo at this time. That doesn’t equal abandoning Meteor. It equals working hard on Meteor.
I look forward to reading other opinions on this important topic.
@maxhodges we don’t talk here just about Meteor core. We are talking about packages dependencies like Flow-Router.
I saw that Vue.js also very attractive. I think Vue.js and Vue-Router or React and React-Router is the future of this part and best alternative to Flow-Router because it has bigger community and more maintainer for example if we compare Flow-Router VS React-Router it’s a general results:
Github Stars:FlowRouter = 1019 < React-Router = 17956 Github Forks:FlowRouter = 129 < React-Router = 4222 Github Contributors:FlowRouter = 38 < React-Router = 344 Github Last Commit:FlowRouter = 8 months ago < React-Router = 8 days ago
So I think based on this thread until now react-router and vue-router are wins and both Blaze related router (IronRouter and FlowRouter) are loser.
. If my company decision is to stay on the Meteor.js surely we will use your help to buy a Galaxy account.