It sounds like you were in an organization where there was some fundamental disagreement that caused the contention.
I don't have any skin in the game, but I find this account to be an unfair characterization of Meteor, so I'd like to refute some of your claims.
First, I really don't know where you got the idea that Meteor is an all-or-nothing stack. Sure, it provides everything you need, but you're not compelled to use what it provides. Meteor works very well with all sorts tech.
Basically, if there is javascript support for it, you can use it with Meteor.
Secondly, it's disingenuous to say that Isomorphic Javascript is just bad tight coupling by invoking "universally accepted anti-pattern" because someone can come along and spout equally broad and obnoxious engineering-speak, calling it DRY and touting its core principle of code reuse as best practice.
Now, I am genuinely interested in specific shortcomings and outright failures of the technology. If you had a bad experience with DDP, I'd like to hear about it so I don't make the same mistake.
If I want to use Angular, I can include a single javascript file and then bootstrap my entire page, or a portion of the page with an application module.
If I want to make an application where one page is an Angular client app and the other is an Ember app, but they're both served by the same server and communicate to the same API you can do that with number of server-side frameworks and architectures... not Meteor though.
Meteor is an all-encompassing server+client package. You'd need to include all your angular application code along with all your ember application code because they share the same meteor server application and meteor is not built to separate clients from servers.
My bad experience and much of my frustration comes from Meteor's hype machine. This person was hyping Meteor as a production ready framework to a startup when it was not... hell it hadn't even reached the arbitrary 1.0 version number yet.
In fact, when Meteor upgraded to 0.9 it force upgraded everyone... i couldn't run `meteor -v` without Meteor saying "Upgrading to v0.9...", which of course would break all the atmosphere packages we were dependent on to have Meteor connect with all the normal functionality that NPM modules would offer.
Meteor evangelists will say "oh, but it wasn't 1.0 and atmosphere isn't a thing, or whatever", because it's always a deflection when it comes to this conversation. The fact that this is a thing that COULD happen is never addressed, the architecture and patterns that led to something like that happening is just ignored.
It sounds like you were in an organization where there was some fundamental disagreement that caused the contention.
I don't have any skin in the game, but I find this account to be an unfair characterization of Meteor, so I'd like to refute some of your claims.
First, I really don't know where you got the idea that Meteor is an all-or-nothing stack. Sure, it provides everything you need, but you're not compelled to use what it provides. Meteor works very well with all sorts tech.
* The website has a whole subdomain devoted to using it with Angular: http://angular-meteor.com/.
* Here's talk given about using React: https://youtu.be/-QtrkXKvQFc. I'm currently doing this with great results.
* Here's one of a few projects providing support for PostgreSQL: https://github.com/meteor-stream/meteor-postgres/wiki/Gettin...
Basically, if there is javascript support for it, you can use it with Meteor.
Secondly, it's disingenuous to say that Isomorphic Javascript is just bad tight coupling by invoking "universally accepted anti-pattern" because someone can come along and spout equally broad and obnoxious engineering-speak, calling it DRY and touting its core principle of code reuse as best practice.
Now, I am genuinely interested in specific shortcomings and outright failures of the technology. If you had a bad experience with DDP, I'd like to hear about it so I don't make the same mistake.