[diveanon]

Please don't take this as a personal attack, but I was severely dissapointed with Meteor after being a strong proponent for it for several years.

I advocated for its use on several projects and was bitten by major performance bottlenecks and its over reliance on MongoDB. GraphQL implementation is great, but does it support relational dB's yet?

I am happy to hear that it is still doing well, and I may end up using it for some personal projects.

I believe that the problem it is trying to solve is worthwhile. However I became very frustrated when the push for monetization started while the framework itself still seemed like it was in the prototype phase.

Please correct me if I am wrong, but Meteor has a place in my memory similar to an ex that I really cared about but hurt me once more than I could stomach.

[NickBusey]

As someone who also jumped on the Meteor bandwagon, and is now stuck maintaining a project created with it, run away and do not look back.

It is not being maintained by anyone as far as I can tell, more and more packages are breaking by the week it seems like, and the basic 'features' listed 'on the box' of Meteor have never worked.

Save yourself some headache and pick a stack with an active community.

[kabes]

1. It is being maintained (albeit less active), version 1.9 is in the works. Communication could improve a lot though.

2. What's so hard about maintaining the Meteor project? It's been mostly backwards compatible since versions before 1.0 (released over 5 years ago, when the JS ecosystem was a very different universe). What other JS framework has a comparible track record towards backwards compatability?

3. Third party packages may break and become unmaintained, but this is just as much true on NPM. In the end Meteor is mostly a build-tool (and a pretty good one, with zero-configuration, code splitting, ...) creating a Node application with full NPM compatability.

[diveanon]

I was afraid I would hear that. Best of luck, don't forget to use all your vacation time.

[cultofmetatron]

I'm currently using absinthe which enables a graphql backend on the elixir stack with apollo on the frontend. its been working fantasticly well for me so far. Its backed by postgresql and the hardest part so far has been making sure to batch sql queries for complicated graphql queries.

I haven't used apollo-server but I wrote nodejs code for 8 years and I wouldn't trust it to scale without a lot of effort being put into your DevOps story.

[JMTQp8lwXL]

Externally, my observation was the monetization of the platform was competing with development. When Galaxy came out, feature work on Meteor slowed down. Hungry VCs wanting their return and rapid growth, I suppose. It would've benefitted more from growing organically longer, before going for monetization.

[flippyhead]

We love Meteor too, but have been very disappointed by how MDG has seemingly abandoned it. We had so many expectations for things it would be doing by now that never materialized because MDG moved onto other shinier things.

[proyb2]

I have experiment Meteor for a while in it early stage, I felt Meteor became complex to manage and didn’t like to stuck in a high technical debts.

Now I would rather wait for V language which seem to solve many limitations found in other languages.

[kabes]

If you don't needed the reactivity, I can see how you could solve your performance problems easier without Meteor. However, if you actually need the reactivity, what other tools/frameworks give you a similar convenient reactivity system with better performance? And there are some solutions within the Meteor community: https://github.com/cult-of-coders/redis-oplog (with some trade-offs)