The idea is to illustrate the power of iterative typesetting in combination with Printing on Demand. I can understand you don't like the idea of seeing yourself show up in every story, but you must like the idea that any manuscript out there, can be automatically designed and typeset and even iteratively be redacted or translated and forked into new editions...
I ordered my copy. This is typographical craftsmanship of the highest level. Thanks for this marvel reflecting a huge amount of dedicated labour and what must have been months of research.
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/ 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.
Meteor is not yet another nodeJS web-framework or client side JS framework. It also doesn't stop at combining the both (with a beautiful DDP to share data between C/S). Meteor' s architecture will make it possible to use it's components for all sorts of applications (other then the obvious web-apps).
2. It's as easy or as complex as you want it to be.
You can write a meteor app in 4 files or in a complex packaged structure. No need to overcomplexify, if you dont't want to. But you cán write large, complex, stable and maintainable code.
3. It embraces the eco-system.
You can rely on all of the NPM packages out there for your serverside logic and use all of the available frontend UI libraries and scripts. It will also enable writing complete reusable components in 1 package: servers-side logic, data-model, client-side logic, UI, ... all in one.
Biggest upcoming updates:
* Meteor UI.
Better approach then any other UI framework out there (including Facebook's react or FTLab's fruitmachine)
* Galaxy.
Deploy and scale your app on your own infrastructure or in the cloud by pressing a few buttons.
To counter a few of the cons in this thread:
* It's not reached 1.0 and it is therefor not production ready. I'd suggest writing your new applications in meteor anyway. Meteor matures quicker then any other framework out there. Is is well funded and here to stay.
* It is not scalable. Maybe not easy right now to make it scalable. But it certainly will be soon, when using mongodb oplog and galaxy will make it really easy to scale your service.
I run an agency in Belgium (redandivory.com) and we switched completely to meteor for all of our new projects. I think it's the framework of the near future.
