5 minute review of Meteor.js

Quick & Dirty

We started working with Meteor when it first launched back in 2011-2012. We built a real-time chat app, and started in on an e-commerce platform. We eventually abandoned using it for client work. The risk was too great that the API would change too dramatically before it matured and the team released v1. But now ...

Why Meteor?

It is lightening fast to work with, even for the most complicated apps. That being said, the right tool for the right job is still critical. For our background processes we still use Redis and Resque, for some parts of our back-end we are using Rails. For everything else Meteor works really well.

We aren't fanboys!

We just really like to see rapid progress when developing greenfield projects. It not only helps our clients, and stakeholders, but it helps us feel validated.

When we started playing around with Meteor, we were really interested in Angular and Ember. Both failed to meet our needs, they weren't isomorphic. We wanted to get away from fragmentation in the stack as much as possible.

Angular felt too thin, and Ember just too damn esoteric. Beyond all that, the documentation for both is so poorly organized it is hard to be productive.


Testing still sucks. I don't care what anyone says, it is still too brittle, but hey, we may not be doing it right.

The only other major issue to contend with is drilling the pub/sub model into your head, and trying to grasp reactivity on a theoretical level.

My Favorite thing about Meteor.js

Meteor allows you to start performance optimization early in your dev cycle, allowing for a cleaner, more performant experience.

A few tuts