Why I’m not staking my future on MeteorJS.
Calvin Froedge

I posted this on Hacker News but thought I’d post here too for visibility!


I agree with many of your 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/ and 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-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 )… 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.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.