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.
OK to be honest I have no experience with Vue. But it sounds pretty good. So I guess the best recommendation is:
FlowRouter for Blaze
Vue Router 2 for Vue
ReactRouter for React
I think the anxiety about FlowRouter is unfounded. People can build with it. It works and will continue to work, and if for some reason it stops working, it’ll get fixed. But it seem others want some kind of FlowRouter support SLA That’s possible too if people are willing to fund it.
Great find. I use Veliov Meteor Mailer and I’ve contributed to it (awesome package btw). I find their devs replying very fast and to be very helpful. Last commit to Flow Router Extra was 10 hours ago, so that looks very good.
We started off with Iron Router, but ran into counter-intuitive weirdness and so dropped it. We looked at the then-nascent Flow Router, but found its API a little clunky and Arunoda’s comments about future direction at odds with our goals.
Given a bias for Express’ elegance and a belief that, yes, a router should only route — we baked PageJS into a package (along with Express for a server-side REST API). We’ve tweaked PageJS to make it more Express-like, particularly with regard to error-handling, and I expect we’ll further that over time.
Thus, I’d recommend PageJS as an easily digested library that gets you vanilla routing client-side. I’m happy to post our router package if someone’s interested in using it.
I’ve seen flow-router-extra is already mentioned here.
Thanks for everyone who already using it.
And everyone who is looking for up to date FlowRouter is welcome to try flow-router-extra. We keep all dependencies up to date, test it with every Meteor release, and publish updates when necessary.
Although it’s a fork of original FR, it’s extended with:
Latest features - ES6 Import support, latest qs and page NPM dependencies
Missed hooks - waitOn, data, onNoData and whileWaiting
Ability to preload Images, Fonts and other resources
No need to use BlazeLayout, efficient render with support of yield, layouts and with respect to requestAnimationFrame is build-in
Have you considered reaching out to @arunoda for maintenance rights in the original repo? This would avoid much of the mess associated with a transition like this (i.e migrating issues, broken links, promoting new namespace, etc.)
I personally think waitOn was one of the most confusing (and UX harming) parts of IR, so putting it back is kind of going back on one of the main reasons to use FR. I think FR got one huge thing right: The router should act as just another source of data, rather than doing things like data loading etc.
When you recommend a library, you are also recommending that library’s documentation - the documentation for flow-router-extra focuses heavily on those new hooks, which pretty significantly change how the router would be used. Anyway, if I were Arunoda I would want my project to be taken over by someone who had contributed heavily in the past and shared my vision for the future. I think that’s the difference between a fork and a maintainer handoff.
First of all, I am sorry again for you guys to see a post like this.
Things happens, so we had to move on.
Here’s my idea about the future of FlowRouter.
Future of FlowRouter
@diaconutheodor volunteered to maintain the FlowRouter and he made a fork. (That’s something I suggested).
But it seems like there are some others wanna help this project to get maintained.
So, now I think it’s better to select GitHub organization where I can transfer the repo for new development. I hope @diaconutheodor could work on this and team up with the people who could help on this process.
I won’t be shutting down the current FlowRouter guide which is on our kadira.io domain. But I think it’s better to host is somewhere else, may be the Meteor Guide.
(May be we already have similar content in the Meteor guide)
Ideas to Manage FlowRouter
My plan for FlowRouter for v4.0 was a fully managed SSR. But that’s pretty hard and I could make it work 80%. But getting the next 20% is pretty hard.
So, my suggestion is just forget about SSR for a short term. Get all other fixes in the FlowRouter SSR branch and make a release.
As @sashko mentioned, one thing FlowRouter did right is try to decouple routing from the app logic. So, I wish it’ll be the same.
