MeteorJS: Bright Past, Fast-changing Reality and Unpredictable Future

Within past few months Meteor development was a lot like a roller coaster. The excitement after new releases was soon replaced with a need to deal with the issues that they caused. It changed again to the enjoyable path after those problems were resolved. However, the high frequency of new releases has lead to an uncertain situation when you have to question yourself if it is reasonable to follow each of the updates, or it’s better to wait till the situation gets more stable. And in case of planning a new big project - whether it’s reasonable to build it with Meteor now. To make things more clear, we analyzed our experience with Meteor. We also talked to several Meteor experts to find out what they think of the current situation and what the prospects of Meteor development are.

Meteor We Met

A few years ago, when Meteor has just been introduced to the world of programming, it became a one-stop solution for numerous developers. Ease of learning, high speed of app development, use of JavaScript only and reactivity are just a few features that influenced its popularity.

“I was doing an intense search for a framework that would allow me to build mobile and web apps as quick as possible. I tried a lot, including the traditional MEAN stack. When I first saw Meteor, I said to myself: “Wow, that’s simple. And exactly what I need.”

Tom Brückner - founder of

Meteor Nowadays

There are several great projects developed with Meteor including large ones like Telescope and Galaxy, and smaller ones, inspired by personal hobbies and needs.

“I made an app called BBoy Tools for myself as a breakdancer to help myself train and compete better. It has this really neat feature that allows me to enter and categorize dance moves and select when I’ve used one in a competition. That way I can always see what moves I have available to do still without having to use just my memory. I still use it constantly.”

Scott Tolinski - creator of Level Up Tutorials

However, as with any other framework, there are some difficulties in work with Meteor. Real-time applications need way more resources compared to non-reactive ones. So, despite being a good solution for mvp, the scalability issues are quite common when it comes to larger applications. This is the reason why we prefer Node.js for building large projects. Below you can see a couple of possible solutions for scalability issues in Meteor:

“I try to deal with scalability issues through a combination of being frugal with my subscriptions and horizontal scaling across multiple machines. To be honest, I feel like Meteor doesn't really give you the tools to do a good job with scalability, since there's no easy way to disable real-time at a granular level. Another thing MDG will hopefully improve with Apollo!”

Sacha Greif - designer, coder and entrepreneur,

“When you have publications that can be used by a lot of users, Meteor is smart enough to cache a large part of the subscription. In my case with the, most of the feeds were unique to users and couldn’t make use of the oplog, so it was pressuring the db and the app cpu. The issue lied within geoqueries as you can’t use oplog with them. I then decided to change the data model to rely on geohashes delimiting zones and sort the available feeds client side. It’s a bit of overpublication, but it reduced the cpu footprint server side, so it was worth it.

Version 2.0 of situation will be to use a different technology stack, relying more on direct broadcasting than the DB feed.”

Michael Mazurczak - founder of

Meteor Development Group does a good job on refining Meteor’s features. The integration of npm packages and new imports folder in 1.3 release and the support of more recent versions of MongoDB and Node.js in 1.4 version are only few of the introduced long-awaited improvements. However, not all developers rush to update their applications to the latest Meteor versions. Along with some incompatibility issues, one of the biggest concerns is how frequently MDG produces the new releases. Starting from March 2016 there appeared Meteor 1.3, 1.3.1, 1.3.2,,, 1.3.3, 1.3.4, 1.4, 1.4.1 and, maybe, I have missed some here. For those who have their applications functioning in Meteor 1.2 updating to a newer version basically means rewriting the whole app. So it’s no wonder that many developers choose to wait until things with Meteor get more stable.

“I'd planned to stop adding features to my prototype and upgrade to version 1.3 when it came out, but when I realized how quickly the MDG is doing releases, I dropped those plans. I think the smoke needs to clear a bit before I take on a planned rewrite for a commercial release. I want to move from Blaze to React and implement GraphQL using the ApolloStack.”

Dean Witcraft - software developer

An Unpredictable Future

With all said above, it’s quite hard to foresee even the nearest future of Meteor as a JS framework. There are several different opinions on what awaits Meteor. What unites most of them is the uncertainty of Meteor’s position at least before the first Apollo release is launched. Who knows, maybe, Apollo and Meteor integration will become one of the most awesome development stacks. Or, maybe, Apollo will absorb Meteor and it will no longer develop as an independent project. For now, we at Apiko are still using Meteor for mvp applications development. However, we are migrating our large Meteor projects to Node.js, as currently it seems to be a more stable solution. If you also feel like migrating your Meteor app to Node.js, we can help you with that.

Read our recent fresh review of Meteor 1.6: 'Meteor 1.6. Review: Benefits, Issues, and Examples'.

“The ideas behind Meteor will also live on and who knows, maybe a couple years (or months?) from now all the pieces will be there for someone to give Meteor's vision another shot.”

Sacha Greif - designer, coder and entrepreneur,

“I’d love to just see Meteor continue to improve and impress.”

Scott Tolinski - creator of Level Up Tutorials

And so do we :)