Introduction, and favour to ask the community!

Thank you! Agree with you here on the learning tools and accessibility.

Appreciate you sharing your thoughts here!

Let me preface this by saying I love Meteor, just like you. Been using it since 2014, and still do. While I fully agree with all of the great points listed above, I think from a marketing point of view it is also important to acknowledge the ways in which Meteor has gotten a bad rep over the years. As these are the things that are keeping people away, not the lack of shiny features in my opinion.

In my experience trying to convince agencies or other devs on using Meteor, these are the pushbacks I often get (directly or between the lines):

  • Meteor is just a toy framework, nice for prototypes but not a solid base to build on
  • Meteor is for people that are not really skilled programmers (this will only be amplified if we keep focusing on how “easy” everything is)
  • Meteor doesn’t follow best practices (like not using NPM for installation, it just looks weird compared to other tools/frameworks)
  • Meteor does not scale (I know we’ve beaten this to death, but it’s still a perception — and also a reason why focusing on the real time live data without acknowledging this concern I think will only backfire)
  • It’s better to build it yourself (while I, as I think everyone on this forum, love the zero config and the fact that I don’t have to spend any time on bundling, deploying, devops, etc, I also think we are a rare breed among developers. A lot of devs like tweaking with this stuff, and feel that it’s the only way to get the best setup. So you will not convince those by focusing on the ‘magic’ of the zero-config setup. Maybe the solution here is to instead have detailed explanations of what the setup actually is, what choices were made and why. Like the specs section of a MacBook page; you can expand it or skip it, so people who want to can get into the nitty gritty, but they don’t have to.)
  • Meteor is not secure (also a very old story, we all know the insecure and autopublish packages were there purposefully for ease of use and speed to get started, this decision has damaged Meteor’s image badly (comes back to the “toy framework, not for serious apps” perception). This is also why I insist we should not again focus on how “easy” and “fast” everything is, at least not without giving a lot more technical insights because it will only reinforce this existing perception).
  • Meteor ties you to Mongo which I’m not sure is a good database (often I have to work to sell Mongo as well, especially if other devs are more familiar with relational DBs).
  • Meteor is hard to customize; it’s great as long as you’re using it as intended, but if you want to do something differently it gets really difficult
  • You cannot/It’s difficult to host Meteor where you want (like in your own Docker container)
  • Meteor requires you to buy in to their whole stack (this could be fixed by a “Make it your own” section on the website: choose your fav front end framework, Postgres instead of Mongo, connect a custom backend to DDP, … — by the way, there are a lot of the people doing very cool stuff like this here on the forums :wink: . A cool way to reinforce this could be with cases; “Read why Company swapped X for Y to support use case Z”)

Also, I think it’s good to realize that the speed and ease of use apply to us in part, because we are used and familiar with the framework and its ins and outs. For newcomers, there will be a learning curve, likely making it less fast and easy to get started than what they’d normally use. Most devs probably also already have a set of tools they take from project to project (components, packages, Webpack configs, …), which already gives them a similar dev experience.

Please don’t hate me :), I am genuinely writing this to help, not to attack Meteor. It is also just based on my experiences, so it might not be representative. But do keep in mind, and I’ve said this elsewhere, that here in the forums is quite a bit of Survivorship Bias. Of course we are all convinced by Meteor’s features and benefits, but this is about convincing people who are not on the train yet, and everyone that left to come back.


Certainly don’t hate you! Quite the opposite in fact – this is very valuable. Really appreciate this. Lots of food for thought about ways we can improve and bring more people to Meteor!

Thank you again!


I started with Meteor shortly after the 1.0 release. I came from the LAMP stack world so it was quiet new to me, but compare to every other solution I was trying at that time Meteor just worked with just one command install, this was super awesome especially compare to the other solutions which were more difficult to setup and even if I followed their guides it often did not work. The next thing that attracted me was the account system and data on the wire. Account system remains for me the most powerful feature of Meteor to this day (would be nice to see it updated and possibly extended).
I then grew together with Meteor. When the time came I switched to React, when I needed hosting Galaxy was there and as with Meteor it was super easy to use. Same with other improvements. I occasionally try other technologies, but compare to the ease of Meteor I find them cumbersome at best.
The pricing on Galaxy (especially once I combine it with MongoDB Atlas) is more than I would like to, but I see it as a donation to the whole ecosystem and is manageable at my size (we’ll see in the future). Currently I’m missing 2-factor authentication from Galaxy and more down the road a setup for any AWS regions (something akin to what Atlas has), ie. one deploy that then gets implemented in all regions.


Perhaps not quite the format requested, but I do have some comments on how Meteor might progress. So hopefully it’s ok to post this here in free form. In no particular order.

  1. Communicate Meteor as a set of tools that can be mixed and matched, not as a “take it or leave it” monolith. Don’t want to use DDP? Sure, you don’t have to. Use Meteor as a build tool and get data via REST or Apollo. Don’t want to use Mongo? Add a package from npm and use PostgreSQL. Want to use Meteor on the server but have React Native on the client side? Sure, connect your mobile device to the server with SimpleDDP. The possibilites are there, especially once Meteor became compatible with npm, but are not very well communicated. This would go a long way to alleviate fears of vendor lock-in, or in this case, framework lock in. Maybe Meteor’s guide might have a section dedicated to examples on different ways to use Meteor.

  2. Don’t over-emphasize simplicity. Like @rijk said, this implies that Meteor is not for skilled programmers. Rather communicate that Meteor provides you with sane defaults, but in most cases does not limit your options to configure things yourself if needed.

  3. Don’t get too caught up in view libraries. Let React/Vue/Svelte/… duke it out by themselves and just keep Meteor open to any view library out there. I’ve said it a number of times before, but it’s worth repeating - the semi-official Vue integration for Meteor is only about 2.5k lines of code (going by memory here, I might be off by about 500 LOC). And at least for me, it gets the job done very well, though I don’t use SSR. Given this, Meteor should be open to any view library that gets enough traction to warrant some skilled dev to write those 2.5k lines. This should alleviate worries that a view library gets left behind.

  4. I think an interesting possibility for Meteor to generate interest is the current rise of PWAs. PWAs might finally deliver what nothing else has before - single codebase, installable on all devices, completely circumvents all App/Play store masochism and enables true continuous delivery. But the somewhat difficult part of it is the offline capability. It would be interesting to see if somebody could come up with robust offline capability for the default Meteor setup with DDP. Caching assets and handling method calls while offline. I have not thought about it too much, and there might be technical issues stopping this. But an out of the box setup for PWAs with offline capability would be very nice.


I agree, specailly with point 4, PWA are picking up and Meteor is very well positioned to take advantage of this trend, I think it’s natural evolution of the Meteor ecosystem to embrace PWA given that Meteor premise was single code base for multiple platforms.

All that is needed to have a PWA scaffolding that brings the tech together.

P.S we are using Meteor to power a PWA app connected to Meteor server using SimpleDDP (which is really nice to work with, perhaps it an be extended to have offline support) and it’s working very well, I believe it’s the fastest way to get an app to the market, our next step is to explore the offline support.


I am still a Big fan of Meteor. I think that what there was Two major things that made Meteor gain so much adoption at the beginning:

  1. It was VERY simple to become a Full Stack developer. That simpler path is somewhat lost now in the documentation in favor of the most advanced developers path… It should be emphasized back! Although noting, however, that Meteor developer today CAN evolve with the platform to become more advanced, and develop more production efficient apps as they go along, using the latest and greatest in javascript technology.
  2. The FREE publishing servers for testing and small projects (including mongoDB). THIS WAS REALLY GREAT!!! That was a great complement to the easy-of-use of the platform AND a great advertisement for its success. We could see literally thousands of working open-source meteor project running beautifully around. That could be brought back WITH some conditions like: being advertisible by the Meteor team, being open-source, limited-time, etc…

Meteor SHOULD be the platform of choice for the beginner ! But not only that… It does have ALL the technology and efficiency to hold the beginner into the platform . There is simply NO NEED TO LEAVE as it is possible to develop the most complex app with it and get not performance penalties anymore.



1 Like

Thank you! We’ll be in touch :slightly_smiling_face:

I have been working with Meteor for 4 years and build and entire companies echo system around it, its a home automation product made for builders not consumers Home Otto were based in Alberta, Canada. All our own hardware fully integrated under one home account, lights locks, thermostat and camera is in development. All run with real-time meteor, adjust a light slider and it updates with sub-second changes.

Our Android/IOS app is a meteor app hosted thru galaxy, our builder tools for reading blueprints and quoting a home automation system is meteor, our internal monitoring and administration tools are meteor as well. We have tied in Alexa, slack, firebase, stripe and other 3rd party integrations.

For Zeotec I creates a lab test management app for maintaining ice rink chillers with field service tech’s, to keep them running efficiently and the hockey games going.

We build IOT systems for monitoring environments and have them report back to a dash board and reporting system all running in real-time, which is what meteor is great for.

Meteor has had its challenges some are harder to work thru than others but I think the long term gains are worth any issues the environment provides.

The good:

  • Everything you need under one roof, or one command away from adding it.
  • Quick to get any project up and running
  • I love 1 command deploy to add new features all my users without having to do a new build to the app stores
  • I have worked with relation databases for 15 years, I like the freedom NoSql and Mongo brings

Needs Work:

  • I would love to see Cordova plugins for essential services get more 1st party integration (big ask)
  • Storage, mongo, static hosting
  • the ability to bash script update container packages, wkhtmltopdf is nearly 5 years old

For smaller projects I have started to use NodeChef which is lower cost with a database, I can host static landing pages, use s3 storage, update and add to the container. its a different beast with a more shared environment but for lesser needs works great.

right now I am working to stream a video camera to a meteor site to drive a remote drive a robot to deliver groceries, streaming is good now I just need to learn to drive :slightly_smiling_face:


Thank you! This is interesting. Appreciate the thoughtful response here.

Hi everyone, it was a pleasure to read all those memories and experiences with Meteor, so I want to share mine as well :slight_smile:

I’ve started playing with Meteor around version 0.4. People at my software house (cheers to @cristo @michalwanat @radekmie) loved it as well, and it gained such internal popularity and acceptance that we released our first Meteor production app soon after, using version 0.6. Back then, lots of things were rough. Still, the framework already gives us advantages over alternatives we were using back then.

For what we love Meteor then and over the years?

  • Just Works™. Easy to install, runs everywhere, and for everyone without significant issues. The same was true for apps built on top of it, and it was a big deal (Docker was not a thing back then).
  • Single codebase, allowing us to reuse code and business logic between frontend and backend.
  • Want something? There was probably a solution for that. If not, you or someone else in the company can write it and reuse it across many apps.
  • It was absurdly easy to use realtime data and updates. Even up to this day, Meteor is unmatched in this area - if you don’t believe me compare to what you have to do to set up and use GraphQL/Apollo subscriptions.
  • Accounts system that it’s there and it’s great. Again, Just Works™.
  • Easy to learn and to introduce new devs to it. At the same time, quite hard to master, so even more experienced devs have fun optimizing and tweaking it.
  • A safe place in the JavaScript Fatigue. Remember all the fuss a few years ago? We as a company were attached so much to Meteor that all those problems were unaffecting us at all.
  • A friendly and open community - lots of meetups and content.
  • Galaxy - again, you can see the Just Works™ philosophy in action.
  • SimpleSchema and AutoForms - we loved to build forms in declarative fashion so much, that when we dropped Blaze for React, we created uniforms.

Currently, at, we have several apps running in production using Meteor. Most of them are walled-garden internal apps, but we have products like, which is happily running on Galaxy. This is why we are glad that there is now a Galaxy roadmap and some attention. We can’t wait for the autoscaling feature :slight_smile:

And while we didn’t start a greenfield project in Meteor for a while now, seeing the direction Meteor is heading after Tiny’s acquisition, this may change soon.


Hi @matthollingsworth! I’m late to noticing this forum post, but I’d like to invite you over to the Meteor Community Slack if you are interested to talk more about some ways we could all work together to revitalize Meteor’s reputation on the web and among various developer communities.

Before I knew this post was up, I made a pretty authentic case for what I love about Meteor, and specifically what I love about Meteor + Vue over here.

One tip I would offer is for the Meteor team / devs to reach out to leaders of other open-source communities that directly impact developers awareness and knowledge of Meteor. Front-end frameworks are where new developers learn to build things these days, and Vue stole the show for the new easiest place to START building a web app. To the millions of Vue developers, Meteor is mostly an unknown choice for a backend (this is from their perspective). I’m hoping to change this perception by helping Vue developers learn & get started with Meteor.

We’re glad to have you as support to get devs excited about Meteor again!

1 Like

Thank you so much! Looking forward to working together :slightly_smiling_face:

1 Like

Hi Matt @matthollingsworth
I am 67yo and a non-coder. Classic Meteor has made complex apps accessible to an Average Joe, just like me. Hey, when Biden tells a steel worker he needs to learn to code, he is clearly referring to Meteor :slight_smile:

Here’s my little offering…
I pipe EEGs around the planet using Arunoda’s Streams. No more Classic Meteor than that.

Happily hosted on Galaxy.


I use meteor on google servers with haproxy and hosted mongo for iot platform. Meteor is simple thats it. Though our platform has other components - mqtt, redis queues, node based event handlers, seperate analytice platfotm etc… from a mere dashboard that offers a view into operational data and interact with field devices . This JuST works!!! At the end iy ie all about decoupled architcture

I used to build with Meteor (wrote a long advocacy post in 2015), and ~5 years later, I’m semi-regretting not sticking with it. The main reasons that drove me away were: sense of abandonment, lack of support for PWAs and GraphQL, and team/community split (Apollo? Blaze vs. React?).

As others have said, it may be worth de-emphasizing “easy”, and emphasizing the serious time savings that Meteor offers. I estimate that at the start of a project, Meteor easily saves a man-month worth of coding time not spent reinventing the wheel (accounts, data sync, bundling etc.) with the “build your own car” approach.

What do others think? As long as it’s also emphasized how you can “graduate” from the initial setup (e.g. opting out of realtime data when and where it no longer make sense), I think Meteor has a winning story.

As for,

That’s true, for myself included. But I recognize there my OCD tendencies, However, when you step back and honestly ask yourself what benefits you’ve got after spending hours or days tweaking and testing and debugging your tweak, over the tried & true approach that a framework offers, the answer is often, “not much”. And it tends to be “not worth the time you’ve spent, which you could’ve spent building an actual feature”, when you ask your customers and business stakeholders, rather than your inner developer geek.


I’m totally new to Meteor and this community. I have a background in Drupal, PHP, MySQL, JS, TypeScript, Vue etc but I’m a generalist, dabbling in a lot of design/creative stuff as well. I’d honestly never heard of Meteor, or if I had I’d forgotten or written it off due to my own ignorance or just “framework overload”.

I have a largish, non-trivial app in mind and had started building a Nest backend and Nuxt TS Vue composition API frontend with MongoDB and GraphQL, I suppose because I was caught up in bleeding edge “best practice” (or my misconception of it). Then I stumbled across Svelte, saw how much faster, smaller, simpler and more rational it was than React/Vue/Angular and fell in love with it almost instantly. Then I found Meteor, I think through the new Level Up Tutorials Svelte + Meteor series, read up the docs and philosophy and I’m hooked. This Svelte + Meteor combo seems to be exactly what I’ve been looking for to achieve my goals as painlessly as possible, and Galaxy looks like a great solution for me as I don’t want to be messing about with server provisioning, config, maintenance and complex deployment. I wish Galaxy also provided MongoDB hosting as an option (even if just a convenient UI to a specialised third-party MongoDB cloud host) but it’s not a deal-breaker.


Thanks for this! I agree, we shouldn’t pushing the “easiness” of building with Meteor. What’s more important, I think, is emphasizing flexibility and efficiency.

What it’s about for me, when working for a startup, is getting to market faster. When building an MVP for a startup, there is always a limited amount of time and budget, meaning you have a limited amount of work you can put in. So, the less work you have to spend wiring up Webpack, rolling Authentication, setting up APIs, managing data, etc, the more time you have to spend on your actual product. Thus significantly improving your chances of it finding product market fit. For a business owner, this is a no-brainer, really. Even if there are concerns about ‘scaling’, it is really irrelevant if you consider that you won’t even get to that point if you spent 4 out of 8 weeks toying around with flashy tech and then come out with a crappy product. Another way to put it: when you do run into scale issues, it really is a good problem to have and you should thank Meteor for helping you get to that point.