Roughly: Meteor required too much vertical integration on each part of the stack to survive the strongly changing landscape at the time. On top of that, a lot of the teams focus shifted to Apollo (which at least from a commercial point of view seems to have been a good decision).
Tight coupling to MongoDB, fragmented ecosystem / packages, and react came out soon after and kind of stole its lunch money.
It also had some pretty serious performance bottlenecks, especially when observing large tables for changes that need to be synced to subscribing clients.
I agree though, it was a great framework for its day. Auth bootstrapping in particular was absolutely painless.
non-relational, document oriented pubsub architecture based on MongoDB, good for not much more than chat apps. For toy apps (in 2012-2016) – use firebase (also for chat apps), for crud-spectrum and enterprise apps - use sql. And then React happened and consumed the entire spectrum of frontend architectures, bringing us to GraphQL, which didn't, but the hype wave left little oxygen remaining for anything else. (Even if it had, still Meteor was not better.)
I'm the defacto maintainer of the Meteor MySQL integration. Since 2015, I've been involved in the design and maintenance of six different Meteor webapps for real-time geospatial applications built for B2B and B2C.
Given this, I reject your assertion that Meteor is limited to MongoDB and "toy apps".
I think this blog post may provide some insight: https://medium.com/@sachagreif/an-open-letter-to-the-new-own...
Roughly: Meteor required too much vertical integration on each part of the stack to survive the strongly changing landscape at the time. On top of that, a lot of the teams focus shifted to Apollo (which at least from a commercial point of view seems to have been a good decision).
Seems like meteor is still actively developed and is Framework agnostic! https://github.com/meteor/meteor
Tight coupling to MongoDB, fragmented ecosystem / packages, and react came out soon after and kind of stole its lunch money.
It also had some pretty serious performance bottlenecks, especially when observing large tables for changes that need to be synced to subscribing clients.
I agree though, it was a great framework for its day. Auth bootstrapping in particular was absolutely painless.
non-relational, document oriented pubsub architecture based on MongoDB, good for not much more than chat apps. For toy apps (in 2012-2016) – use firebase (also for chat apps), for crud-spectrum and enterprise apps - use sql. And then React happened and consumed the entire spectrum of frontend architectures, bringing us to GraphQL, which didn't, but the hype wave left little oxygen remaining for anything else. (Even if it had, still Meteor was not better.)
I'm the defacto maintainer of the Meteor MySQL integration. Since 2015, I've been involved in the design and maintenance of six different Meteor webapps for real-time geospatial applications built for B2B and B2C.
Given this, I reject your assertion that Meteor is limited to MongoDB and "toy apps".