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...

100% agree with this post. I also co-authored a book about Meteor[1] and, to me, it's really the "framework that got away." Modern React/Redux/JSX/Next/etc. completely sucks compared to how awesome and seamless Meteor felt when it first came out. Surprised you didn't mention anything about RPCs. Having methods that can run on either the front end or the back end with basically zero boilerplate was an incredible idea which unfortunately never really got traction. A few comments:

I think that HTML over the wire is still pretty context-specific. There's even modern cases where I think it makes sense to just render whatever blob you get over the wire.

I don't think that "Database Everywhere" deserves a thumbs down. It's an insanely useful prototyping tool, genuinely useful when trying to replicate reactivity, not to mention extremely performant for all that work it actually did (it sort of "hacked" this by hooking into Mongo's oplog). Meteor's mistake was, imo, mainly deciding to do this with MongoDB instead of a SQL variant.

I think I'd probably give "Embrace the Ecosystem" a shrug. The modern-day "Ecosystem" is a mess. To start a project, you need tsc, but wait not that version of tsc, and you also need React, but now you need Webpack. And also a CSS plugin, but also a SASS plugin. Oh, an SVG plugin too. But now you have a conflict. Have fun. I actually prefered using Meteor's more limited ecosystem where everything just worked out of the box.

Also no mention of CoffeeScript (which was heavily pushed); that deserves at least two thumbs down.

Anyway, I miss Meteor :)

[1] https://www.oreilly.com/library/view/introducing-meteor/9781...

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...