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.)
mentalgear|6 months ago
hobofan|6 months ago
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).
h4ch1|6 months ago
thrown-0825|6 months ago
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.
dustingetz|6 months ago
vlasky|6 months ago