[mrcwinn]

I would just say that the "X versus Y" approach to frameworks (as opposed to tools) is not very productive in a lot of cases. The best way to approach it is to define and understand the needs of your project, research, and choose.

For example, it might be the case that simple, real-time-ish data is very important. Meteor might be an excellent choice.

It could instead be the case that lock-in (and Meteor is definitely encouraging lock-in on both sides of the http request) is a concern for your team, and you feel it important to have flexibility or maturity on the server-side. Meteor might be a terrible choice.

X can be better than Y in one circumstance, and must worse in another. Define, research, pick.

[jasode]

>The best way to approach it is to define and understand the needs of your project, research, and choose.

But reading someone's "X vs Y" is one way to "research" and reading the factors that the author compares can also feed back into the reader's "define and understand the needs of your project". When there are new technology options, novices often don't have the background to know "what or how" to compare them. Reading some "x vs y" opinions is part of filling in that background.

[faceyspacey]

I would master your tools and somehow afford yourself the luxury to build things just for those tools. Fortunately meteor is opening up possibilities for a whole new world of realtime apps. Forget angular if u can start from scratch and build new realtime stuff. The closest option is React combined with maybe firebase or something. But even then reacts way of defining HTML inline (compiled with jsx or standard) doesn't compare to how meteor uses HTML templates which a designer can easily edit like usual. As great as react is, nobody wants to code inline HTML. And you don't have to in order to get the same effect.