React Router vs Flow Router

This is really interesting. Will be looking into Elixir/Phoenix as a possible replacement to the Meteor stack.

I really want to discuss more about Phoenix with Meteor users but I think this is not the right topic, can we create one ?

3 Likes

No, I haven’t tried flow router 4.0. The releases and branches are super confusing, the releases are jumping between 2.x and 3.x, I don’t even know what 4.0 is.

I just want something that works well and is supported by the community, however, flow router has worked great for me – I have complaints.

The different flavors of SSR that you are mentioning are confusing me. And then when you add code splitting, it makes it even more complex (have you seen https://github.com/thereactivestack/kickstart-hugeapp)

The fact that Meteor, i.e. MDG doesn’t address these issues (SSR, code splitting) is unfortunate!

I don’t know if I can explain reactivity in the context of the router, I just understand the general principle, that when any reactive variable is modified, it automatically re-evaluates any code that depends on that variable. For example in a React component you can have getMeteorData() and when any data accessed changes it triggers re-rendering of the component.

So, that much I understand. I just can’t picture routes (and therefore potentially the entire UI) changing in response to reactive variables, so I presume it’s something else. @arunoda?

@ryanswapp, @jacobin, @SkinnyGeek1010, @3even, @skini26 and the other guys, interested in Phoenix, lets move here.

1 Like

React works differently. It’s okay to rerun whole component again and again. Invalidating getMeteorData is okay.

Also, it’s much better if we pass route params as component props. We could do in FlowRouter and that’s recommended for React.

React Router does it all the times.

It’s a little late for a reply, but, maybe Meteor isn’t meant for apps that have millions of users. I’m building apps that are used internally by just a few users. It’s a completely different market, so use whatever tool is appropriate for your project.

1 Like

I realize I’m very late to this conversation, but I’m wondering how flow router and react router compare today. Any thoughts? I’m starting to work on a new project and I wanted to get a quick rundown on how these two routers compare.

1 Like

Agree. This thread lost touch with the original topic. Is there any consensus at all between Flow-Router and React-Router?

My personal opinion after playing around with both for the last few weeks is that it depends on if you want SSR or not. Flow-router does have SSR support, but it made some weird stuff happen sometimes (such as randomly re-rendering and going into a rendering loop) but React-router was more consistent for me on the SSR side of things.

I ended up sticking to Flow without SSR myself though, as SSR is fairly intensive on the server and I’d prefer to focus on optimization elsewhere. It also feels more like ‘Meteor’ to me, whereas React-router doesn’t.

Just personal preference really!

I used both.

FlowRouter will allow you to have the best Meteor integration. Version 4 will have a lot more seamless SSR.

React-Router has SSR capability but it’s implementation is very generic and you’ll have to do all the SSR wiring yourself. More interestingly, I will choose RR over flow when I need to have heavily nested UI (like Gmail for ex) or complex multiple layouts… it really shines at this.

FWIW, I think SSR the entire app is just a fad. Unless you have megabytes of JS the client load time reduction is not worth the cost (in time). A service like prerender.io is free or $15 a month for larger sites and it solves the SEO problem in 5 mins.

3 Likes

One of those is recommended by MDG. The other is not.

Since you’re building a Meteor app go with what MDG recommends. That is FlowRouter.

@SkinnyGeek1010
May I ask how you are running prerender.io with Meteor? Are you using a package (dfischer:prerenderio)?
I’ve spent the day with it and no success.

P:)

We’re using that pre-render package currently on Atmosphere and it seems to be working great!

Coming back to the ReactRouter conversation, I personally don’t like the idea of tying my view tree to my URL hierarchy or passing through URL data through mixins and invisible context, but to each their own!

I was using flowrouter, but I decided to put some effort into reactrouter when I learned flowrouter relied on browserify(at least for now).

while I’m still exploring react router, I’m discovering

  • doesn’t depend on meteor packages
  • large userbase and community, it has a much stronger momentum, and is more likely to have support for edge cases I may encounter later
  • I haven’t tested it yet, but according to thereactivestack/webpack there is a package called https://github.com/nfl/react-helmet which should help react-router-ssr with automatic wiring for SSR, although I don’t know if it is just as much a resource hog as it is said flowrouter ssr is, which I also haven’t gotten around to applying yet

I still use both, for different branches as I test and stay on top of various concepts and approaches, but yes if you learn flow-router, you can use it with both blaze and react.

  • however, the edge case anticipation argument for choosing react, if you are on react and redux still holds, as there are likely more momentum to make sure you have a road ahead tomorrow as well.
1 Like

Okay. Let me update a bit about FlowRouter.

ReactRouter is mostly a UI router. It’s hard to use from JS.
It works pretty well. I used it for couple of apps (not production).

On the other hand, FlowRouter is router on JS. Just like Blaze, it can render React.

Feature wise, both are the same. Both address the the same problem in different ways.


FlowRouter SSR, we are using a pretty different approach for SSR. It understand meteor subscriptions and fetch the data needs.

React SSR is very CPU heavy. So, you must cache. FlowRouter comes with a built in cache.

You might say ReactRouter has a much larger base. So do we. We use a very mature project called page.js under the scene. FlowRouter is a wrapper around it.

But, if you are trying to switch from Meteor later on, you must use ReactRouter. Otherwise, FlowRouter is a good choice, because we try to get the benifit from a good Meteor integration.


About, split file loading. You don’t wanna worry much about it. With FlowRouter SSR, you could render your app to the user in first 100KB even before loading any JS. Try https://kadira.io

4 Likes

I haven’t tried it on Meteor yet (just nginx) but was just planning on using the Meteor package.

@arunoda Is there any way we can use FlowRouter + ReactLayout with npm React instead of Meteor’s React?

And if not, would you suggest using FlowRouter with React without ReactLayout? After reading the documentation, im not entirely sure how to approach rendering React layouts in Flow Router without ReactLayout. This is all related to Meteor 1.3-beta.* in case that makes any difference.