Similar thoughts here.
However until the data flow and patterns with react are properly tested and easy to follow, then react in meteor is not yet a better solution than blaze for the beginner, nor for prototype/minimal viable product projects, as it will just create other problems and possess too much uncertainty and lack of reliability and predictability. Some key elements of the meteor react stack and patterns are still to be vetted out. But eventually it can be, given sufficient work.
In either case, it is not something that can be flipped right now or over night.
maintaining blaze for now, I imagine, is not much different from maintaining react and angular 1 and 2, but maybe urigo and dgreensp? can tell more about that.
as long as maintaining support for blaze, does not limit innovation and possibilities with babel, npm, es2015+, react, redux, webpack, hmr, code splitting, loaders, routing, etc, and anything else we need and want, then by all means.
Eventually when the documentation, patterns, guides, etc is up to par and things have been refined, then react can be just as good for prototyping and MVPs if not better, and with blaze compatibility as a layer on top, mdg need not maintain multiple tracks, it all comes down to add-ons.
But until then, and the tracks can merge or one becomes obsolete it does look like it is necessary to cater to each independently, in one way or another, and using packages for customising flavours should be sufficient, for clinical meteor and other vertical solutions as well, assuming the underlying core is flexible enough.
Ps.
I’m already on the webpack+react+redux etc innovation track, so the blaze support concerns is just to show respect to others, and lets be fair, onboarding new people may as well be via react soon when ready for that, so that’s not really an issue, the real concern should be for those with existing investments in blaze developments and deployments that need some return on their investment, and a little tlc and lts.
