Indeed MDG is shying away from tackling the hard innovation its been know for. MDG could do a Manhattan Project style Blaze reboot, taking lessons learned from React and the other great UI packages out there – and surpassing them all.
Building on that momentum, they could then focus on a Tracker reboot/update and add code splitting for Blaze+Meteor.
Why is this logic not applied to the situation of Blaze over React? By building a BlazeNext you would never be constrained by what others cannot do. Blaze done right, and under MDG direct control could be something more than React.
I’ll re-read your post again, thanks.
MDG is or will be depreciating the following due to the decision to use React and GraphQL: Blaze, Tracker, Publications, Atmosphere and on and on it goes.
Gawd I love these quotes, again why doesn’t MDG apply this same logic to Blaze over React? Is React the “right” tool? This seem subjective. And ripping out a lot of tech and replacing it with React supported tech seems drastic to me.
It’s clear that Webpack is what the community has voted “yes” to by using it in greater and greater numbers.
We’ve been listening to what MDG has been saying about the reasons for replacing Blaze with React. One point that’s been hammered home by MDG is that React is the “chosen” tech because it’s being embraced by the community. It seem self serving to apply this logic only where it’s convenient.
Many want code-splitting in Meteor. If MDG has said Webpack doesn’t fit the bill due to technical issues, that’s a fine decision. But pull something else from the community instead of building in-house I say, because at this point it’s hard to trust in house solutions.
Also, to be clear, there’s been speculation by myself and others as to the motivations behind some of MDG’s recent technical decisions.
The reasons for this speculation in my opinion is two fold:
-
On the surface the recent decisions by MDG seem to not hold water and,
-
There has been a lack of communication from MDG proper on the rational behind the recent decisions.
Questions I have are as follows:
-
Why doesn’t MDG proper state plainly why they’re making the technical decisions they’ve made as of late to the Meteor developer community?
-
Why is MDG choosing React over Blaze and thereby gutting a large portion of existing Meteor tech?
-
Is MDG adopting FB tech a strategy to position Meteor for Enterprise adoption, and thereby promoting Galaxy and MDG Support Services?
Many of us have made huge (relative) investments in Meteor tech. I for one have built a company on Meteor tech. I’m very likely a future Galaxy customer too.
The decisions made by the small group at MDG directly affect the Meteor development community and small business people.
Cheers