There’s a right tool for every job, and right now Blaze seems like a pretty good tool for some jobs. Maybe the time will come when it becomes obsolete but until then the fact remains: it’s a great tool!
If one day my hard work churning out apps in Meteor+Blaze, or whatever stack seem fit, would turn into gold, then that work will probably be modified, refactored, analysed, torn apart, rewritten and retested many, many times, eventually turning it into a completely new beast, using whatever tools best fit for the job and the requirements.
At this point, rushing to decision on whether this or that framework, stack or technology will provide the best toolset or the least amount of sweat in the future sounds an awful lot like premature optimisation to me.
And we all know how premature optimisation turns out
@hamatek +1 ad infinitum for @arunoda and everything he has accomplished within the Meteor.js community per my post and many more I have made thanking him for his many contributions over these last few years.
There are plenty of options if you want to tinker on the weekend, and expecting MDG to support your hobby for free is an absurd notion. That’s why hobbies are called hobbies and not businesses.
Plus, we’re not talking large multi-national conglomerates… we’re talking small dev shops who need meteor to be dependable.
I would say that its not wise never to give up Blaze because:
I think Blaze is one of key things that have hooked people in Meteor, because it gives you a fast start when you have first spotted Meteor in GitHub. I dare to say that if people would of started with React tutorial many of them gave up first ten times. However I have not had time to learn React yet, so I cannot say this 100% sure.
MDG people in this post said that money and the audience is the reason why they are going after React and Angular, however Enterprise is always looking for LTS and many companies have gave up Angular because what happened between Angular and Angular2. Enterprise people have always talked that will the Meteor apps work for the next ten years. On the flip side React can be expected to be a long-term technology as Facebook is built with it. I think you are doing it right as you are adopting the technology that is used by facebook, but I would say that combo should be Blaze and React. Some people just has to hear Angular these days and they are gone.
Blaze is just fucking awesome. It works for the most of the apps and its fast. I love the way that I can fast layer multiple helpers inside each other {{#each}} in tempalates and use events+this functions to update small piece of data. I love the way of using {{> }} to embed template for example replacing the username with picture. Just think of it.
When you get Apollo, GraphQL and stuff working in reactivity mode for all data sources, many persons in field are going to test it with their database, what would be the better and easier way to get people in the scene than providing them reactivity to their database and Blaze that can push the data to HTML elements and D3 charts.
MDG is working towards opening it up. With 1.5 everything is to be split up into npm packages and communities like Blaze will be able to build and push changes independently.
As @energistic mentioned, Blaze development is more or less stalled until the push to npm happens (there are a lot of comments in the Blaze repo about holding off on further development until the cutover to npm happens).
With regards to the npm cutover, MDG has a few hurdles to address. @zoltan summed these issues up nicely here:
There are big questions around how exactly dependency resolution might work within an app that mixes both npm and Atmosphere packages. Consider if we ‘move’ Tracker into npm (however that may be). What happens to the many (including blaze) Atmosphere packages that depend on tracker. Maybe we create an Atmosphere shim package that uses the npm package behind the scenes. But then what happens with packages on the npm side that depend on a different version of Tracker? It’s impractical to build a constraint solver that operates over both package systems.
We’ve been thinking about these questions in detail and no great solution has thus far emerged. We’re currently focused on releasing Meteor 1.4 as soon as possible at which point we’ll pick this problem up again.
So far, MDG has been reluctant to point the community in a particular direction lest it be the wrong one and folks end up doing a bunch of redundant work. I’m sorry if this has come across as a frustrating void in communications.
Regarding community contributions - we’re still really excited and are 100% behind the community taking the lead on Blaze from a feature development point of view. In fact, one of the key things we’re shipping in 1.4 is the unpinning of core package versions which will enable the community to release new versions of blaze without any involvement from MDG.
I am having really hard to time figuring out how Angular or React can ever be easier and faster than Blaze for basic app development. I say one of these two should go along with Blaze, but I am not convinced that choosing them both over the Blaze is a right solution.
I just hope MDG solution is the right one…Because it is the first principle that never change something that works, because why to change something that is already good? It’s like having a good pair of shoes for maraton, but you still buy new ones before the race and they break your feet.
. React also has me like 
It’s like having a good pair of shoes for maraton, but you still buy new ones before the race and they break your feet.