Meteor vs. the MEAN stack


Meteor is great, we all know it. But before committing to Meteor, many developers will ask “Why Meteor” in the first place, and also “How is Meteor better than the MEAN stack?”.

Can you help with the second article? I’ve only used components of the MEAN stack individually, but not or MEAN.JS themselves, and feedback from folks who have used them would be very welcome. postQuora answerHackerNews ⇐ spread the word!

Thank you!


My experience has been that it really boils down to division of labour, and whether team members want silos of responsibilities (ie. little fiefdoms) or if they want interdisciplinary cross-functional responsibilities.

MEAN promotes silos of responsibilities, server specific APIs, client specific APIs, etc. It’s can also be more comfortable for junior level programmers who maybe only know client-side programming; or only server side programming. Meteor’s isomorphic API, of course, promotes common language across all team members, and more cohesive teams. But only if everybody is onboard with isomorphic full-stack development.


Meteor is the MEAN stack. After you have made a lot of great choices, some workable ones for efficiency (temporarily more or less locked yourself to mongo), and built a lot of infrastructure for automating builds.