This front-end db should be separate of the UI/navigation. So, not Meteor

To be very fair to Meteor, they're trying hard to separate their UI/rendering layer from their front-end data layer [1]. There are prototypes where you can build an entire frontend in React from the top down, taking Meteor collections as stores and passing them down your hierarchy or just including them [2]. Still rough around the edges, but Meteor's going in the right direction here.

[1] http://info.meteor.com/blog/meteor-the-missing-infrastructur...

[2] https://github.com/jedwards1211/meteor-webpack-react

I wish Meteor nothing but the best, but React is no longer just a UI framework. Relay encroaches significantly on Meteor turf; and its optimistic update mechanism is arguably more flexible that Meteor's syncing protocol. In addition, there's React native and deep integration with tools such as Flow and Include.

There should be space for Meteor and I don't mean to be discouraging, but this is generally a good time for framework authors to internally debate how the competitive landscape has changed and the best path forward.

Unfortunately, Relay is significantly further from "just working" with push and write-once-run-everywhere-including-your-database query language, than Meteor is from "just working" with React. If you want a realtime immediate-mode-rendered web application without writing tons of boilerplate for data handling, and duplicating business logic in your server (i.e. GraphQL implementation) and client, Meteor+React has the edge today. You're right, though, that frameworks built on Relay+React will eventually catch up. I'm also looking forward to that day.