Limitations of Meteor - what can't it do? [closed]

Question

Meteor seems like a great framework for quickly writing dynamic applications, but there has to be a catch.

Presumably there are the limitations I will run into when building an app using Meteor.

I am looking for a way to assess whether or not Meteor is a good choice for a given project.

Can you give any examples of the kind of app that could not be easily written in Meteor, and would be better written using a different, more customizable framework?

Answer 1

I'll attempt to give you the unvarnished truth as someone who has been running meteor in production for a revenue-generating business since 2013. Note this answer is being written for meteor version 1.1. Any limitations given here will undoubtedly be fixed over time.

Limitations

• Meteor only officially supports mongodb.
  1. If you have an existing database that can't be easily ported, you may be out of luck.
  2. Mongo doesn't have triggers. Because of this, meteor jumps through ridiculous hoops in order to observe changes to the database to maintain reactivity. This ends up being a big deal if you manually call observe or observeChanges, or if you need a reactive join. In order to maintain a rational CPU level under even moderate load, you need to use oplog tailing, which will require that you either host your own DB, or use a dedicated instance from your favorite provider (recommended). However, once you do that meteor can indeed scale.
  3. Following from (2), oplog tailing performs poorly under heavy write loads. While this isn't common for most web applications, if your app will exhibit that kind of behavior you may be able to solve this by separating that portion of your app into a microservice.
• Meteor isn't a good choice for static sites because it's dynamically rendered via javascript - i.e. SEO support is limited. Some packages like ssr are designed to help with this. My understanding is that the Google crawler has become significantly more sophisticated in running SPAs, but I wouldn't bet my business on it. Often an easy workaround is to maintain a static site separate from the app.
• There is no built-in component library. If you know what you're doing, you can write reusable templates but it's not really the same thing. Some well-known meteorites have been able to use react and polimer to build their apps, but there's a non-trivial amount of hackery required.
• All of the js and CSS assets for a site are loaded upfront. I.e. there is no notion of incremental loading or feature pruning. The good news is that your content can be easily cached. The bad news is that the initial page load can be painfully slow.

Summary

Overall, meteor has been a fantastic framework to work with. Despite the above limitations, we have been incredibly productive with it. Like any framework, you'd probably need to just do an evaluation project to see if it's a good fit.