As @thea closed the previous post, I wanted to follow up on my conversation with the author on Medium of the post of workpop leaving Meteor. People jumped on it as a sign of things to come without properly investigating the issue.
I asked about the underlying reason, he initially resisted:
I don’t see the need to explain every bit of our “ambitions” but I will say we have the dev team to support this “risk”
When I insisted saying the article is weak without the starting premise, he answered:
I think it comes down to several points
- Controlling how the app is built and bundled
- Controlling how reactive/real time features are built
- Controlling deployments
- Controlling how traffic is load balanced…
Thank you for your response. So we have been using Meteor for a year now, and had in in production in no time
- Controlling building and bundling: agreed, it’s part of Meteor’s ‘magic’, although webpack is slowly becoming standard.
- Reactive, this new package should provide exponential improvements: Meteor Scaling - Redis Oplog [Status: Prod ready] — in line with chattr’s redsubpub
- Deployment and load balancing: we developed production-grade deployment scripts (https://github.com/ramezrafla/meteor-deployment) which are super easy to ease, use nginx load balancing and provide a visual interface to see status. And Btw, these two issues have nothing to do with Meteor, you would have the same challenges with any app
So unless there are other real reasons, you guys moved away from Meteor, as it seems for emotional reasons, or maybe because you hired a new technology team / CTO
So back to work for me! Nothing there to worry about …