The State of Meteor Part 1: What Went Wrong

This is exactly the reason I'm not using meteor - and it's not so much wanting the ability to switch backends as knowing in advance I want to use an SQL database like Postgres, and not Mongo. With meteor, it's Mongo or nothing.

I believe SQL integration is on their roadmap, but I think now it's too late.

You can in fact use React as the view layer with meteor, so for an app using React, the remaining killer feature of meteor 6 months ago was optimistic updates, with database sync all handled. But, there was still the hard limitation that you must use it with Mongo, which simply made it a no go. I commented about this here, a couple of times, and others did too. I even asked a few months ago if there was a library that just provided the optimistic updates feature. Well, now there is one that looks promising, though it's still early days and I've not used it yet - Facebook's Relay - with complete React integration, caching, request management and optimisation, and yes, optimistic updates and sync. The difference though, is that it talks to a graphql server, which can be written over any database at all - with Relay the frontend is entirely agnostic about the database used, by design, because it talks to it through a middle tier. There's no reason for me to wait for meteor to implement SQL integration any more, because now another solution has come along.

I still don't understand why meteor made the choice of a hard dependency on Mongo if they ever wanted to become mainstream. Had they not, it's very likely that many developers, myself included, would have picked up meteor over the past year and would be hooked on it. Now though, that train is rapidly leaving the station, at least for devs on the React stack. I think they missed their window.

Also, consistent growth isn't really enough, usually, to capture a market and exponential growth is usually expected from startups.

Instead, I just utilize `Meteor.Methods` for all client/server interaction. I actually think it's pretty nice because you define the method on the client as a "stub" that gets called as it waits on the server response. I think the tutorials and guides focus too heavily on their fancy client/server mongo magic.

Though something that is a bit frustrating reading this is that I left React. I found it overly-complicated for my product and preferred architecting everything in terms of templates. Blaze is threatened by React? How? I like React, but I can't exactly get behind writing HTML components in javascript because whoa man, a diff engine & "look ma! I'm being functional!" I realize the benefits of uni-directional flow, but all it really did was add a lot more conceptual weight to a pretty simple interface.

So I said, this is pointless let's just simplify things with Meteor + Blaze. Now Meteor says, it's "threatened" by React?

This seems to be the same issue with other frameworks when they get to a point where they have enough adaptation and find out they need to change/update parts of their framework to get it to the next level.

Same thing is happening right now with AngularJS. Been around for a while, had massive adaptation, then they realized they needed to make major changes. Enter pivot to 2.0 which pissed a lot of people off, but the heat is dying down now and people are coming to their senses.

I'm pretty sure at some point React and other frameworks will hit their wall too.