I really like Meteor as a meta platform/framework where it embraces third party frameworks through atmosphere. Blaze seemed to be an appropriate basic templating framework, while still embracing other more strongly opinionated frameworks via atmosphere. I wonder if it is possible to generate an optimized porting api without overly committing to a particular third party framework like React.
Foolproof? Pretty much, yes.
The data layer stuff is likely to come in a long while from now, will be better than we have now, and will be optional when it comes.
Iâm using React (and JSX!) quite happily now. Most looking forward to hot-refresh, module support (mostly for the ease of testing), and a low-cost Galaxy tier.
Since there is a discussion about the Data Layer and I thought itâs time to document what I have in the mind.
Here it it: Why Meteor needs a Data Layer ?
And this is a comment from @joshowens
You have me intrigued and from what I hear from behind the scenes at MDG, they are thinking about this very thing. I would love a much more public discuss on it.
behind the scenes at MDG, they are thinking about this very thing. I would love a much more public discuss on it.
I fear that public discussion would be something like a post saying that âminimongo will no longer be maintained but a thin wrapper around graphql would be there for a transitionâ followed by 400 replies without further comment from the OP.</sarcasm>
hilarious. the future is looking awesome or bleak, depending on how you look at it, and ultimately depending on the migration strategy. I think the absolute key thing here is: that the migration strategy forward is akin to the metaphor of monkeyâs swinging from vine to vine. We still must be able to hold on to the previous vine, and simultaneously while holding on to the new vine. Anything less would be like what appears to be happening in the Angular world, and itâs not looking too good for them. It appears that their decision there (and the time itâs been taking to implement) is what has led to React blowing them away. Being that Meteor is a âfull stackâ system itâs both an even more challenging situation and imperative we get right.
The 3rd piece is the upcoming new module system. These 3 things (view layer, data/subscription layer, and modules) could in fact be the deciding factor whether Meteor goes on to become the king of the âisomorphic webâ or a siloed platform that is slowly eroded by the greater NPM community. Thatâs why we must demand the absolute best in migration strategy, not just access to the new tools.
Ha ha. I hope MDG should have learned some lessons