It's actually a bit weird how your name gets auto-tagged (even without your consent!) on Amazon. First noticed this when my name showed up[1] (not fraudulently, in this case); but very strange for an author link/page (especially a living one) to be unilaterally created.

Sadly, Amazon probably doesn't care and actual working authors will have to deal with this constantly.

[1] https://www.amazon.com/Introducing-Meteor-Josh-Robinson/dp/1...

So, full disclosure: I recently co-authored a book on Meteor which comes out in a few months[1]. I don't think Meteor is a cure-all panacea or that it's the Best Framework Ever®. I've come to Meteor with a fair bit of experience (Play 1.0/2.0, Sails.js, Flask, etc.) and a fair bit of skepticism. However, I really don't think much went wrong with Meteor. In fact, it treads some of the same ground as its predecessors. As far as OP's article is concerned, I have some very specific squabbles with it:

> This creates a bigger barrier to entry compared to front-end frameworks like React and Angular, or server languages like Go or Elixir.

Okay, Meteor has an arguably bigger barrier to entry than React or Angular (maybe), but definitely 100% not Go or Elixir. I think this is just disingenuous.

> I believe some of Meteor’s early choices may have ended up handicapping it. For example, Meteor’s focus on real-time applications makes them a lot easier to build compared to any other platform out there. But it does also come at the cost of hidden complexity, and potential performance problems down the road.

This is the #1 problem of every framework, ever. Mr. Greif is not saying much, if anything at all.

> Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.

Here, he's conflating things that are easy (routing and pagination) with things that are hard (subscription caching), so it's hard to see exactly what the criticism is here. Not to mention that Iron Router are pretty mature. I haven't run into a routing issue yet that it couldn't solve. As far as joins and caching, etc., these are definitely difficult things. I don't think any framework out there completely (and in the general case) solves these out-of-the-box. Maybe someone could introduce me to one.

> The result of all this is that Meteor has ended up in an awkward place.

I think it just ended up where almost all other frameworks end up: useful, but not completely generalized. In fact, I think striving for a very high degree generality might be a mistake, lest we want to end up with something like Hibernate.

[1] http://www.amazon.com/Introducing-Meteor-Josh-Robinson/dp/14...