The State Of Meteor Part 1: What Went Wrong

Obviously there are many React haters. Yet, some of the biggest contributors to Meteor have embraced it. I discovered Meteor recently. I read many posts by Sacha and Arunoda. I chose React and flow router because it looked like the winning team. Selling my company on Meteor was not easy. The SQL team put up a hard fight. Ultimately, React made the sale. Management’s eyes lit up when they heard the name Facebook. From a marketing perspective, MDG should leverage how well Meteor and React work together. My biggest hurdle has been a lack of documentation and proper examples. The guide is very helpful, but it is still sorely lacking in terms of React. This has slowed me down and I’m sure I could be doing things better. Personally I have found Meteor/React a pleasure and I look forward to part 2.


From Meteor is “The JavaScript App Platform - Build apps that are a delight to use, faster than you ever thought possible” and you said "The large goal of Meteor is to make javascript development as smooth and easy as possible. "

What is an App Platform? Development utility is only part of platform. A platform includes cores, foundations, components, frameworks, libraries, and toolkits. A platform requires consistence, stable and solid foundation. A platform needs to provide stable APIs and architecture for packages and extension. Before Meteor has been built as an app platform in right direction. But in the future it is a question mark.

How do you distinguish Meteor platform and NPM platform in the future? Any reasons for Meteor exist as a platform in current roadmap?

If Meteor’s goal is to become a productivity tool and environment then there are no arguments.

I would strongly argue that any reasonable JavaScript platform or programming environment today needs to work with NPM seamlessly.


my two cents is that MDG trying to convert meteor from a hacker stack into enterprise first hacker second stack. The whole picture looks more clear after the Meteor 1.3 alpha introduced(e.g: import npm modules). The bad part for this is I think now the duration of the learning curve extend. Good part is it will teach people to write more universal code that can be used by other JS platform as well.


The title of this is uncool @sacha. I enjoy your work and this post has many great points, but that title is going to produce a lot of unwanted FUD; part 2 to refute it or not. This Hacker News thread is a nightmare.


work with NPM does not mean to remove Meteor’s own package system. Instead Meteor needs to pay more attention to enhance its own package system.

1 Like

I agree - I think something like “The State of Meteor Part 1: Growing Pains, Bright Future” would help keep the FUD levels down (while still getting the message across).


You know… my feelings match those of the title of the article posted in OP… but for a different reason.

I wonder to myself “What went wrong?” When I see how the feelings of Meteor changed in the last 6–12 months???

A little over a year ago (probably a year and a half) I was practicing Node.js and first discovered Meteor. I instantly loved it in comparison to the other frameworks I was using.

6 months-1 year ago, all the feedback I seen was very positive. There was an upbeat feeling in the community.

I did not check the community since Summer, and in December decided to check again, and all of a sudden it’s filled with negativity???

I wonder to myself… “What went wrong?”. What happened? What did I miss? How did the general opinion change so fast???

My personal feelings about Meteor have not changed. I fought for the ability to implement Meteor in to my workplace for our software and managed to do so. Both myself and co workers are happy.

Frankly, it is very worrisome to see the community so negative… After fighting to get Meteor in my workplace, and planning a project that is probably going to span entire 2016 in to 2017… I am very worried to see all this negativity. It would be horrible for Meteor to fall apart now… And the community seems to be trying very hard to convince us that it is a real possibility for it to happen…


I wrote a rather lengthy response to this here, before noticing the reply as linked topic feature: State of Meteor: Response & Solution

Honestly, I would not have read the article had it not felt like Sacha was really going to expose some profound thing that I must have missed. As I said, it’s like a combination of 50 recycled robo-articles ripping on Meteor… but I did…and I cannot get those minutes of my life back.

I have not engaged, strike that… perused… the community since last summer as well and it would be a shame if it has changed from the ‘everything is awesome sauce’ feeling that was abound early last year.

Meteor rocks…and it’s v1.2. Write code with mad, superior glee knowing you are using the coolest shit out there and ignore this type of … click bait.


I fully agree with @Spyridon and @iDoMeteor. I’ve been working with Meteor for the past year and as a company we have committed to it for the foreseeable future. Yes, it has some issues but what framework doesn’t? For me, the positives far outweigh the negatives.

It’s gotten to a point where I’m not visiting the forums and news sites as much to avoid the negativity. I will say this feels like it may be that a more vocal minority is causing this perceived negativity, my colleagues and I really enjoy developing with Meteor and will definitely continue to.


You’re right, I apologize for that. My goal with that title was to try and capture the sentiment of part of the community, especially people who tried Meteor once but gave up on it for whatever reason. And it was also a catchy title. But I should’ve given it more thought, taken at face value by people outside the community it implies that something major did go wrong with Meteor, which isn’t really true. “Growing pains” is more accurate.

Hopefully part 2 will be able to make up for it.

P.S. That being said, Hacker News is Hacker News… don’t pay too much attention to it!
P.P.S. Also, MDG (or someone else) can always piggy-back on this to defend Meteor and introduce all the new stuff coming out in 1.3. ; )


yeah this has probably already turned away a handful of new developers (or old too).

There are people who won’t even read the article, they’ll just cache the title and write meteor off next time they are considering a new stack…

It’s posts like this that will have a negative impact over time… I understand sacha was just trying for a click-bait title for the meteor community-- but it may have unintended consequences.


Meteor isn’t going to fall apart, as long as ditches the ‘all or nothing’ approach. You’re either using Meteor or you’re not. It is currently far too highly coupled. It needs to be more modular. And with the developments in 1.2 and 1.3, it’s obvious that MDG is making investments in making Meteor more modular, and these changes will have a solid payoff long term. That’s Part 2.

1 Like

Meteor Rocks!

Blaze or React
Webpacks and other cutting edge stuff!

Just make it awesome and cutting edge!

People fear the change that’s all!

MDG is the most active Team I know and they keep going forward and letting the community choose whatever router, template engine or anything you want.

The only things they had to make from the start is the guide which is the real docs not the which is an API doc.

We need some good/advanced Tutorials from the MDG showing us (as they did with meteor React tutorial I liked it) how to use the best new technologies :smile:

People can keep using blaze and add react in the same time until they fully migrate to react (there should be a guide on this I think)

Just when you want to make a move a BIG one like the blaze to react explain why and give all the info we need to know not just some few words… or stressful things like this will happen within the community) Don’t let the rumors ruin it!

Thanks for you work bros and keep it up


Maybe you can do

The State of Meteor Part 2: What Went Right

1 Like

Just copying my reaction from the blog post, since it’s gotten no likes there, while I think it sounds pretty smart :sunglasses:

Isn’t having a platform in a state of flux better than having a stale platform? Software that doesn’t evolve with its time, that’s something that would really scare me.


Part 2 is out!


Meteor made me move from a Front-End Developer, to actually understanding databases, models, controllers… and even choosing a view layer. No matter what, you can still build a basic Meteor app very rapidly, you don’t have to choose React or Angular as a view… or wait for whatever database, router, etc… I think the fact Meteor is incorporating new tech a huge selling point for them.

I think the main problem is businesses picking up Meteor… and jobs being offered. I’m seeing more React and Angular jobs than any Meteor jobs. And that’s probably because they’re all set in their business stack ways, and just changing out the view layer in their apps. I wish there was more companies switching out their Rails stack to Meteor, or whatever “java” stacks. I would love to just work on Meteor… but unfortunately unless you develop a business from scratch, not many companies outside of California are even aware of it, it seems.

I’m spending most of my time just learning React and build tools, but I wishhhh i could just work in Meteor ugh


I did, thanks for the feedback.

Very well put!

That’s a good way to sum up the situation. I think MDG is smart enough to do that in a way that doesn’t increase Meteor’s difficulty curve too much though. In fact I think this will smooth out the difficulty curve, instead of things being super easy in the beginning, and then hitting that wall.

Meteor’s main problem for me is scalability of queryObserve, especially for poll-only queries like geoqueries.

Real-time is becoming less of a requirement for me. The backend only needs to make things “just work” for my user. Most potential users saw the guts of my app as guts, where I see them as diamonds. I implemented a huge real-time data display for no reason.

“If meteor offers it, I should use it” is a dangerous way to think, and is probably a huge source of negativity for this framework.

So I stopped going all-out on meteor’s wicked awesome features. No matter how cool these hammers are, I only need one hammer for a thousand nails, unless I hire a bunch of people. It’s easy to use too many hammers with Meteor. Not only that, but sometimes a hammer isn’t even the right tool. It’s just that all you hear about is “Meteor has awesome hammers”

  • proceeds to apply the hammer to every nail, screw, and widget *

The most useful thing for me in Meteor is how the UI can simply update itself when the underlying data changes. I’m sure react is king here, but blaze has been good too. I’m happy to build my own data transport, just don’t make me handle the UI.