Blixs

I'm a fan of RxDB. It makes a lot of sense to combine something like PouchDB with RxJS to create a reactive datastore. The only thing that bothers me a bit about it is the dependency on CouchDB (at least in case you want to have online sync). Not that I have anything against CouchDB (it's a great piece of technology IMO), but it's definitely not suited for all use cases and is in general a lot more restrictive/less powerful than a more general-purpose database like PostgreSQL.

Well, RxJS helps with pushing data around in general. It doesn't care much if it's from a local state store, a backend api or something else. So in a way it makes a lot of sense to use it for state management as well. The way we do it is by having a single global state store (like redux) with one incoming RxJS stream for writing to that store, and one outgoing stream that emits the latest snapshot of the store whenever a change is made to it. A component can then subscribe to that stream and filter it so it only gets an emitted value when the data it cares about changes. And because there's only one incoming and one outgoing stream it's very easy to debug and see what's going on in the app, making it very predictable and transparent. Also, like I said before: almost no boilerplate code at all!

We use RxJS for data loading and global state management. Started with redux first, but really disliked all the boilerplate code. RxJS enabled us to have a really smart data loading and caching mechanisme that automatically pushes changes to all streams that rely on a particular piece of data whenever that data changes. No need for reducers, selectors, actions, constants or sagas. Just components with one or many RxJS subscriptions, and services to alter that data. It's been working really well for us so far.

I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that caused a lot of scalability and maintainability problems in production. Its "make reactive all the things" model also gave (less experienced) developers a huge gun to shoot themselves in the foot with, causing a lot of performance issues.

If you want to keep all the reactivity goodness from Meteor I'd suggest taking a look at Firebase. Their new Cloud Firestore is very impressive and basically gives you all the features Meteor offers when you combined with a front-end framework like react or angular. Or you could take a more low-level approach and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create your own reactive push streams, and subscribe to them in the front-end using a reactive library like RxJS.

I have (some) experience with both React and Vue 2 and definitely prefer the later. Vue is very minimalistic but unlike React provides a lot of functionality out of the box. Stuff like the router, the computed properties, automatic change detection, HTML templates, scoped css, animations, ... . But what's more important is the fact it does all these things in an extremely elegant and unobtrusive way. The computed properties are an often overlooked but good example of this. You simply declare an object property that is dependent upon other properties and voila, that's it. It's there in your component together with the rest of your data for you to use in your template. It gets memoized, it gets change detection, it just works (TM). No need for Redux, Reselect, selector functions or any of those things. I love the simplicity of this approach. And this is just an example, but this very minimalistic approach applies to everything that Vue offers.