
Why I’m not staking my future on MeteorJS - jessewmc
https://medium.com/@calvinfroedge/why-i-m-not-staking-my-future-on-meteorjs-52e55fbf5332
======
btown
I agree with many of the author's points. But the primary criticism boils down
to lock-in. Without lock-in, no matter how many rough edges Meteor has, if it
can be swapped out in the future while keeping 95+% of the business logic and
rendering code intact, AND if you require real-time sync between users and
backend jobs, then it's a no-brainer. Because you can get your MVP up with
Meteor, then if you find you need things like account merging, you can make
the business decision to rewrite your backend and sync code from scratch
without any sunk cost. And modern Meteor (i.e. since this summer) supports
this brilliantly.

The reason is that Meteor now has a set of best practices and supported
libraries for working with React and NPM. So you can build completely Meteor-
agnostic React components (which can access the entire React NPM ecosystem),
then have small wrappers that declaratively specify the data subscriptions you
need for each view. If you ever want to swap out your backend, you just need
to switch how you're feeding props to your component hierarchy, i.e. with a
Backbone mixin, Flux, or Relay. (In fact, the subscription code in React-
Meteor is very conceptually similar to how Relay's GraphQL declarations work,
but it has the benefit of giving you a working backend about 5 minutes after
changing client code, rather than waiting 5 months for people to dig into the
GraphQL reference implementation.)

For references, see: [https://react-in-
meteor.readthedocs.org/en/latest/](https://react-in-
meteor.readthedocs.org/en/latest/) and [https://github.com/elidoran/cosmos-
browserify/](https://github.com/elidoran/cosmos-browserify/)

It's also very much worth mentioning that with Meteor's first-class support
for oplog tailing, you can always just write external microservices (in any
language you want) that are kicked off by Meteor and asynchronously make
changes to the database. Then all clients will pick up those changes as
quickly as their network connections allow. We use this heavily in production
with a Kappa Architecture (see: [http://radar.oreilly.com/2014/07/questioning-
the-lambda-arch...](http://radar.oreilly.com/2014/07/questioning-the-lambda-
architecture.html) ) feeding a Mongo database that is itself a [read-only]
Meteor Collection, giving our users real-time visibility into, well, just
about everything. The details merit a separate post, but it's a complete joy
to write code for.

Cordova is clunky. But there's nothing stopping your React Native app from
loading your full client Meteor code into the JavaScriptCore background view,
now that React Native polyfills WebSockets (
[https://github.com/facebook/react-
native/pull/890](https://github.com/facebook/react-native/pull/890) )... then
you'd just need to test for whether your app is being loaded into React
Native. And there you have the best of both worlds: React Native for your
view, Meteor for your models and controllers.

Oh, and to address the point of "staking the future of your company on a
persistent web socket connection between clients and servers scaling in
production" \- a very valid criticism of Meteor. But how else were you
planning on making all your data real-time in the first place?

Meteor is invaluable for getting real-time apps to market, and if you use
React, it's flexible enough if you ever outgrow Meteor's assumptions. And
that's a good problem to have.

