I would not switch to Meteor if it was introduced to me today

Meteor started out as great solution for the masses. When I was introduced to Meteor, I switched my 1.5 million-monthly-pageview PHP project to Meteor immediately. Meteor was great for small developer teams with simple projects they could develop over-night. Even some skilled managers or business owners could make their own apps easily. It worked like charm. I remember having goose bumps while developing my first app in Meteor.

Meteor became very popular for what they have done - a complete solution build “from scratch” with an awesome developer experience!

A lot of great hard-core developers (Arunoda, just to mention one) started contributing. Great. However, the help they provided also pulled the Meteor project in the wrong direction. These people needed an advanced solution for collaborating, testing, npm package support, new stuff such as React, Apollo, ES6 support, etc. These people had huge impact on MDG, posting issues, contributing. No wonder MDG listened…

However, the masses using Meteor were different. They were fine and HAPPY with the simple stuff that worked. Session support, Tracker, Collections, Atmosphere, global variables, Blaze, etc… React is great, but it is an overkill for most of the apps Meteor helped build.

Ok, MDG listened and went in a different direction. It pleased the handfull of hard-core developers (majority of those reading this) but it confused the masses (who seldom read these forums). Now, however, the hard-core developers realized they don’t even need Meteor any more. They have React, Apollo and all the NPM packages, webpack and they can “pack” their own apps. Meteor went from being the core to being a part.

So Meteor left the masses that loved it and the hard-core developers left Meteor because they could do without it.

Now, Meteor is for neither of the two groups.

Here’s what Meteor should have done: Keep what they had at version 1.0 and improve some minor stuff: Blaze SSR support, faster compiling, out-of-the-box mobile app support and others.

I would not switch to Meteor if it was introduced to me today. Meteor became popular for what they have done a few years ago and I don’t think it would be near as popular if it rolled out today with what it offers now. They stopped developing what they became loved for.

Sorry, these are my thoughts. I still love Meteor, but my love is fading…

1 Like

Oh how original, another “Meteor is dying” thread. I think we’ve had enough of these around here.

These people had huge impact on MDG, posting issues, contributing. No wonder MDG listened…

MDG has said time and time again that the most important data they use is by surveying and working with real world Galaxy customers. They’re building the features that their source of income is asking for.

They have React, Apollo and all the NPM packages, webpack and they can “pack” their own apps. Meteor went from being the core to being a part.

Meteor removes the need for Webpack, if you’ve used Babel+Webpack you know how annoying it is with constantly changing and breaking dependencies and difficult configuration files. Meteor has an amazing and secure user accounts system out of the box as well, you can’t get that as easily from an npm package. Nobody’s making you use React, Blaze still works. Nobody’s making you use Apollo, but it’s allowing you to use any database other than Mongo and connect multiple data sources in a great way if you want to, with solid tooling behind it like Optics. You’re making issues out of non-issues, since everything you’re complaining about being gone is still right there in front of you, just with more options if you want them.

I would not switch to Meteor if it was introduced to me today.
Here’s what Meteor should have done: Keep what they had at version 1.0 and improve some minor stuff:

That’s exactly what Meteor has done… all of the old code with globals and Blaze and Tracker and Session still works just as it used to, they’ve done amazing work with backwards compatibility. That’s why we’re still on Metoer 1.4 and not 2.x, because backwards compatibility has been upheld the whole time. New (and definitively better) options have been added, but that same framework you liked before is still there. If you liked the old Meteor before, it hasn’t been removed so you should still like it.


So how did your 1.5 million-monthly-pageview project do on Meteor?

What technical issues did you run into that you would not switch to Meteor again because PHP would solves it better?

And is that actually Meteor’s fault?

I got mixed feelings about Meteor.

On one hand, there’s nearly no day where I don’t find YAAMP (yet another abandoned Meteor package). The high level of fragmentation of the community caused by React, plus many good devs leaving Meteor have contributed to that. From this perspective, I fear that I might be the “last man standing” at some point of time, trying to sort out the MEAN-like puzzle Meteor turned into.

On the other hand: I built a React-Redux-Webpack-only frontend for a REST backend service recently. Though it was (and still is) a cool experience, I quickly realized all the good stuff I was missing from Meteor. I was even searching for a Minimongo alternative on npm, since I got heavily used to its convenience. Same goes for routing (React router is way more complex than FlowRouter IMHO) and other parts of the app. And, most importantly, the React world is also very fragmented.

So overall, “the other side of the fence” did not offer a better developer experience. The things I love most about React and Webpack is the modular approach (which is contradicted by some concepts like contexts, though) and the super-fast building times.

If Meteor returned to a more “opinionated” and “developer-experience first” approach, maybe based on React (or even Vue) now that Blaze has been dropped by MDG, this would be awesome. Still, MDG would also have to make this into a sustainable business model, and it seems as if all those part-time and hackathon devs weren’t making enough money.


I’m trying to put it some way that it won’t take a huge text plain but won’t be hursh either…

The thing is. Yes. There was a timestamp when Meteor was behind “SOSIMPLEWOW” vibe.
But that time have past with reactive frameworks popping everywhere, like Pheonix built with Elixir, they provided a robust alternative for Meteor, just about some time around ~1.1-1.2(3) versions, alternative “Meatier”(if you mind) versions of meteor popped and some devs. including myself were not satisfied with the basic one, in case we always had problem of “Atmosphere packages that are 100% npm packages but not up to date”, that was quite troublesome time for entire Meteor and JS(fatigue) communities. I had to use webpack in order to feel more “npm’ful” and stay with meteor, some had to try finding new solutions. But this is it.

Once 1.3 came out, we could breathe out need of atmosphere packages and it was good… But rebuild times…
Once 1.4 came out, we could finally forget about webpack and get performant rebuilds on instant.

And then our garden turned green again, innovations scent all around:
Now we are able to use Vue, Blaze, React, ViewModel - any view we want with no problem.
Validated methods make our life easier than before, and we forgot about client inserts at all.
Grapher, Apollo, Redis-oplog, new SSR solution, super-cool codespliting to come in 1.5

Those who left Meteor, left different Meteor. Try finding alternative now. You may get desperate…
I wouldn’t pick Meteor a year ago. But now, i’ve changed my mind.

I find it weird when you state both, that u’d want even better mobile integration… and php-style simplicity…


I would say that now Meteor could be used by beginners and also (with Apollo and all new stuff) as a complete platform for enterprise. But there is nothing which could block you from using Meteor ‘the old way’ for small apps, MVP projects etc. So, in my opinion it’s better :wink:

Here are my thoughts about the topic:


So I have this Blaze app that I began writing at V0.9 or so… now I’m integrating React on the front end where it makes, doing TDD with the Mocha/Enzyme/Chai/Sinon stack for both Blaze Templates and especially React Components, am looking at both Apollo and Redis Oplog to think about where I might make performance tweaks when and if I need them… it’s like as my app evolves the Meteor ecosystem evolves right a long side it offering me the tools I need as my app needs them. I feel like from 0.9 to 1.4x the developer experience has just gotten better.


These threads are getting really tiring and they all revolve around the same points (Meteor used to be easier, I don’t like change, speculation over MDG direction, super star developer left etc…) and these points has been debated until exhaustion.

And as usual the author is negatively biased, because using the same technology undergoing the same changes, other people were able to launch products with little or even no programming experience using Meteor, and you can see their announcement in this form.

NodeJS ecosystem and JS are one of the fastest evolving platforms, just take a look at the ES2015 features list and try to name another language that changed so much so fast. And if NPM is gaining ground, why competing against it using Atmosphere? MDG made a tough and brave decisions to help Meteor stay relevant today while maintaining backward compatibility. So please take look at the positive side, we’ve access to all NPM packages, ES2015, faster build time, ability to use React, Angular, Blaze and Vue, code splitting and Meteor Guide, and many other new features, these are not solutions for the “hard-core developers” as you stated but the best of what web development offers today. We also have new superstar developers who brought us Redis Oplog, Grapher, Vue integration among many other things. It’s hard to please everybody, you can please some of the people some of the time, but Meteor is still relatively easy to start with and has matured to support larger apps as well, it’s not enough to start easy just to find yourself stuck few months down the road.

I’ve no interest in defending particular technology or personal attachment to Meteor. But I don’t like repeated negative and counter productive comments, especially when I think they’re not fair.


I’m just thankful Meteor is still alive :smiley: I would not want to switch to these other make-your-own-framework kits even if they offer some incremental improvements


For the past two years, I have taught Meteor every semester to 60 computer science students as part of a software engineering course. The technology stack includes: IntelliJ IDEA, Git/GitHub, Meteor, Mongo, Blaze, and Semantic UI.

If Meteor had not evolved to support ES6, I probably would have abandoned it by now. ES6 classes and imports are fundamental constructs for building modular systems, and similar capabilities are present in all other modern languages. I say good riddance to the old Meteor with a global namespace and implicit load order based on file name.

Here’s an example system I provide to my students to illustrate various Meteor design patterns I teach in my class:


From my perspective, today’s Meteor is much, much better for beginners.


Please focus threads on specific and actionable feedback about how Meteor could be improved.