The challenges discussed by the OP apply to any large-scale complex project and are not limited to developing in Meteor. True, some are specific to Meteor (besi

The challenges discussed by the OP apply to any large-scale complex project and are not limited to developing in Meteor. True, some are specific to Meteor (besides the challenges that go with all NoSQL architectures), as is the case with any tech stack. IMO it’s quite unfair to obsess about the cons only (especially if they are the kind of “problems” you can’t tackle), and to take the pros for granted. Routing in Meteor, for one, is trivial (esp. with Flow Router). Subscription management and caching are solvable problems too (esp. if you refrain from doing subscriptions during routing, but instead declare your dependencies where you are really are dependent on your data: in the UI components). What’s the problem with using NPM packages inside Meteor, exactly? The fact that you must write a single additional line in a package? Well, if you’re not used to organize your code in re-usable Meteor packages, then, I guess, it’s more your problem, than it is a problem with Meteor. Meteor does not scale well? How is that? Any Meteor app can scale, as can every application that has been set up with a well engineered architecture: implement you logic in micro-services and your Meteor app will scale smoothly, horizontally, until your database (and not your app layer, that is!) becomes the bottleneck. Most of the comments here, seem to emanate from me the degree of freedom that comes with Meteor (platform vs. framework). If you can’t architect, then, obviously, Meteor won’t save your day and do your engineering for you. I put up some slides with Meteor best-practices for building large-scale apps: http://meteor.redandivory.com/ http://meteor.redandivory.com/ The presentation is almost two years old, but most of the guidelines still hold. tl;dr — It’s not the framework’s job to do your architecting. Don’t blame the tool if you don’t read the manual.