If you are using any of our Meteor projects at kadirahq org, you may have noticed that we’ve almost stopped working on those projects.
Yes — I want to make that official. I really lost the interest of working with Meteor, and it’s pretty hard for me to support those projects for newer versions of Meteor.
So I think FlowRouter now is a risky choice for new project on the other side we have IronRouter that has many old sooooooo what a best alternative for FlowRouter now?
Why many good contributor and project lost in recent month?
I hope that @arunoda and kadira and maybe even meteor try to find a group of contributors for FlowRouter.
FlowRouter is still a solid solution, but the code base is currently split into the official released flowrouter-version and the ssr-branch, which makes the issue-board and the general state of the project a little messy, because both are used and both have some issues. This makes it hard to take over the project.
I think it would be best (for new contributors) to release the ssr-version asap, make it the official version and try to continue the work from there
Basically there are no more routers for Meteor, unless you force yourself to use React or Angular. Iron Router is already dead for a year, Flow Router is dead now that Arunoda left it.
This is another death sentence for Blaze and potentially Meteor I doubt the community will pick up the development of Flow Router (looking at the speed of progress of Blaze now, no offence to the people in charge, they show great courage picking this up), so this will force more people into the direction that MDG wants (use React/Angular) or make them leave Meteor altogether.
For example, I love Blaze big BIG time. But it is hard to justify developing with Blaze, it is just not future proof now that both the templating engine and the router are dead. Which makes me question developing with Meteor because I dislike both React and Angular.
Perhaps it’s time to move on…
(PS. Flow Router is the router of choice for MDG, but I think it should be removed now from the tutorials now.)
Blaze is dead enough that Vue people are “deliberating” about a false flag takeover “Blaze 2” under vue engine, but the vue author went through google/fb/meteor jobs, i think.
Meteor specific routers are not needed anymore (AFAIK), you could possibly leverage any router solution available at NPM. Router should only do routing, no sub handling, template rendering etc…
The important bit when using FlowRouter is actually BlazeLayout/ReactLayout (both from kadira), which renders templates the templates for the route. This should be easily done with different routers. These should be mature enough, to use without the fear of bugs (blaze layout last commit is a year ago).
really interested in this as well, as I’m also about to start a new project and have to chose blaze vs react.
I like the fact that blaze has its structure separated from its logic, and it’s generally easy to learn, but I’m not sure if it will be still around in 1 year ?
I think that’s a great opportunity though… I mean honestly… can anyone say that if Vue supported Blaze syntax, it would not be completely awesome…? lol
Bringing Blaze up to fast rendering speeds, with all of Vues extra features, would be incredible imo.
Sorry to be OOT - but it’s seeming more and more like you should just use the router that fits your view engine rather than a meteor-specific router.
Does Meteor have server-side rendering support for react-router? flowrouter-ssr does a wonderful job at that. There is an abandonware called meteor-react-router-ssr, that’s all I found.
I’m a big fan of flow-router-ssr and I’m not aware of current alternatives for SSR that look future proof.
If I was starting now, I’d be very careful with chosing flow-router-ssr since not only is the package not maintained anymore, but it depends on a lot of meteorhacks packages, such as:
meteorhacks:fast-render
meteorhacks:picker
meteorhacks:inject-data
meteorhacks:meteorx
So it does come with a number of packages you might have to fix yourself, and they can go very deep in Meteor, like meteorhacks:meteorx that is changing subscription logic. So if things break you’ll probably be on your own dealing with low level meteor thing and this ain’t no good.
I’ve been maintaining my own forks of flow-router and picker and changing them for my own needs if that’s of interest, but I can’t guarantee anything.
React-Router-SSR works as far as I know, we’re using it in Telescope. The reality though is that everything will become “abandonware” unless people are ready to take things into their own hands. The days of awesome packages like FlowRouter just popping up out of nowhere are over, imho…
Everything you’ve said there isn’t quite true. We didn’t “force ourselves” to use React; we adopted it happily because it’s awesome.
Iron Router development is dead but Iron Router still works. We have a mass-audience app built with Iron Router and it’s still working fine.
Likewise, the FlowRouter code doesn’t know it’s dead. It still does what it was designed to do.
It’s just not true that code needs to be under continual development in order for it to work. Software is a description of a machine. That machine can still do something useful even if someone isn’t constantly working on the description.
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.
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?
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.
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 doubt the community will pick up the development of Flow Router (looking at the speed of progress of Blaze now, no offence to the people in charge, they show great courage picking this up), so this will force more people into the direction that MDG wants (use React/Angular) or make them leave Meteor altogether.