A missing core principle of Meteor

Meteor is an ultra-simple environment for building modern websites.

http://docs.meteor.com/

What is the beauty of Node? Node brought order to the world of Javascript. All current JS libraries are deeply consistent with Node interfaces and limitations. Meteor is probably the only modern framework breaking this rule. And that’s why, in my opinion, the community is still, after almost 3 years of Meteor’s existence and active development, suspicious about it. As a member of that community, let me explain why.

Nobody promotes Meteor solutions in the Node world. When Google and Facebook introduced Angular and React respectively, Meteor’s native rendering engine — Blaze — couldn’t compete with them despite being awesome in its own way. This happened because outside of the Meteor community hardly anyone has heard about it, or can make a pull request with a new feature or an optimization. This happens to nearly all parts of the Meteor ecosystem. Have you ever heard of Spacebars, DDP, Livequery, Tracker, Accounts? These are pearls of Meteor, great concepts and implementations. But they are not accessible to the wider Node community because they are not Node packages. Eventually, all of the ideas will get their plain-Node analogs and no one will care that Meteor was the first to implement them (this already happened with to DDP, EJSON).

We can’t use Meteor packages anywhere Node can run. When Facebook introduced React Native, everyone was really excited about it. Bringing the full power of Node in the mobile world (and doing it the right way) is what all JS devs were really waiting for. Finally, we can use everything we’re accustomed to in mobile. Except for the native Meteor goodness allowing client apps to work well with the the server-side part of Meteor. Accounts, Collections, reactivity? Forget about them, despite the fact that they are written in Javascript and React Native apps are written in Javascript too. Too bad.

Of course Meteor shouldn’t throw all their efforts to support every other shiny new technology appearing in the Node world. Instead, Meteor should just be interoperable with Node, in full duplex mode, both ways. Then things will happen automatically, like they do with every other piece of software packaged in Node modules.

Another thing of concern in the light of the natural Meteor lock-in is a Meteor monetization model. Don’t get me wrong; a paid Meteor-specific hosting with built-in effortless autoscaling and failover is a really cool thing. But what if not enough people will buy it? This is not that impossible considering that Galaxy only focuses on the Meteor world whereas it could focus on the Node world too, which is a thousand times larger. What will happen to Meteor then? Meteor is an open-source project but its community isn’t large enough to support a half-proprietary, applicable in a limited number of cases, though good, piece of software.

I believe those concerns would vanish if Meteor logic was packed in plain Node modules with clear interfaces. In other words if Meteor explicitly declared and conformed to the principle of full interoperability with Node.

I hope this will eventually happen — Meteor will really embrace the ecosystem integrating with existing open source tools and frameworks. And the community will answer with warmth and love.

P.S. I’m sure I’m not the first one to raise this question, but it’s getting more and more apparent that the elegance of Meteor build system is not as important as the ability to re-use Meteor core logic in plain Node applications.