again, you’re not hearing what I’m saying, instead latching on to words like “extreme.” I’d say read between the lines to see what I’m saying, but you don’t even need to do that–I’ve been clearly stating it. But I’ll say it another way: Meteor has been so successful because it was more coupled than what was going on in the greater Node community. In a VERY EXTREME WAY MDG integrated and united the entire stack! It mixed and matched the best stuff, making great decisions regarding tradeoffs along the way. The system wasn’t as flexible as what was going on outside of Meteor, but a lot more powerful and simpler in the coupling and decisions made. So what I’m suggesting is they go that ridiculously extreme at either making blaze awesome, integrating and coupling it with everything it needs to be the best all the way to the “Native level” OR they do the same with GraphQL, Relay and whatever Facebook is sure to churn out down-stack.
That’s what I mean by ***“extreme”***. It’s an extreme amount of work. It requires an extreme amount of foresight. It takes an extreme commitment to a particular decision/path. What I mean is be bold like they have been in the past.
Now we can get caught up in the words, or what I actually mean. And just to redirect this somewhere productive, what do you think about the possibility that MDG builds ***“Blaze Native”***??? Is that even an option, too difficult and time consuming, why? etc. What about GraphQL, could that ever be a path for us, and what would it look like? What would the implications be? What would the true benefits be? The true idea with GraphQL is somehow it would make it easier for other DBs to integrate with Meteor. The initial idea for why Facebook made it was to make it so any backend system can easily integrate with React. But where that’s obviously going is to a place where any DB can not just interface but be made observably reactive. That’s the next step, the next “Standard” Facebook will release. Obviously there are challenges with observing the data like we have done with Mongo and the oplog. But just look at all the DBs start to make themselves more easily work with React/Relay by conforming to the GraphQL spec and building an interconnecting layer/binding. It seems next is “realtimeQL”–so DBs themselves can make themselves realtime (instead of us having to jump through hoops to make them realtime for them, like for example we are doing with MySQL). So just imagine Facebook doing it again–Facebook speccing out, laying the rules and groundwork for how DBs can become realtime, i.e. observable. Perhaps that’s the real problem here, we are constantly rolling our own solutions, but Facebook (powered by its clout) is rolling out standards. I’m just gonna leave it at that, because that’s a whole other pandora’s box. But maybe it isn’t–it actually epitomizes the juncture of the road we’re at, the supposed “false dichotomy”:
A) The more marketable standards-based approach
vs.
B) The quicker coupled walled-garden approach.
Part of this decision needs to include recognizing that we get the benefits of moving faster thanks to coupling. That’s how we can compete with the legions of developers in the React community. This is as opposed to the defeatist attitude we can’t compete because they have so many developers. We can compete–there code is so much more complicated, ours is more focused; that’s what we have on our side.
So that’s why i see the options: doubling down on coupling or joining the movement of standardized ware.
I’m personally am favoring the coupled “Blaze Native” route. I think in our case we could successfully be more like Apple than Android–the platform where it’s generally agreed upon superior apps are made, even if it is more closed off. So @sashko, respectfully, what do you think, can we even do that? Can MDG pursue the Blaze Native route?