> 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.
Get dozens of book recommendations delivered straight to your inbox every Thursday.