I like that Meteor is official supporting Angular and React. I think it’s good the dev have to option to decide which front-end framework they are most comfortable with. Right now, I’m more comfortable building app using Meteor + Meteor-Flux + React.
1 Like
Well, to be clear, and the reason I keep saying things like “Relay(-inspired)” is because it’s about what Relay accomplishes, not the brand of any specific product. And without an exciting new tier on top to create using GraphQL (like Relay), GraphQL would be worthless, or at least less of a big deal.
If we can do Relay better than Facebook, we should. If we can use Relay under the hood to our benefit we should. It comes down to specifics that developers can agree on and discover after the overall goal is pinpointed. But my perspective doesn’t change: it’s the interface into the view layer (what Relay has pioneered) that makes all the difference to application developers. Even if GraphQL is the most important tool used by “library/framework developers.” I mean that would only make sense if framework developers use GraphQL to create a bunch of competing Relays.
Either way, it’s all following the river to the ocean, and the ocean is the view layer. GraphQL is the river. So sure, from the “framework developer” standpoint it’s all about GraphQL, then why aren’t we using it to build a competing Relay already (like Om Next has) instead of basically recommending people use Redux?? It’s obvious all “single source of truth” features should live under one roof with a consistent succinct API. Domain State + UI State + Time Traveling + Meteor’s special sauce: subscriptions. And it’s not obvious whether Relay should be out of the picture as something we use yet ;). My perspective is not until React Conf at least.
1 Like
Hi @arunoda, I’m following Mantra. Regarding State Management, I’m a bit confused. The use of “State” seems too ambiguous to me. Router states seems to be Application State, and then we have Data states, UI states etc… I’m not too sure the correct terms here… but should they be conceptually separated ?
e.g. an App with options/branching/user decisions, for simple use case, router and url may be sufficient for flow control, but for App with more complex states, I’d rather use FSM to manage the flow control/switching. Does that count as “State” management in your scope?
Exactly.
In Mantra, Application State(by router) and UI state is normally consider as** Local State.**
We do this because, some apps does not need a router and simply need to put a component to the UI.
We call Remote state for Data State.
3 Likes
I’m a bit confused, so is Blaze going to be actively maintained and improved upon, or just left around and used for guides?
1 Like
[quote=“dfischer, post:132, topic:16100, full:true”]
I’m a bit confused, so is Blaze going to be actively maintained and improved upon, or just left around and used for guides?
[/quote]Hi @dfischer, you might get a MDG response, but incase not, this comment just yesterdays seems to suggest the latter:
We can only guess what MDG means by “maintains” above.
My guess is “maintains” to MDG right now and in the context of Blaze means they’ll keep Blaze under their control and nothing else. Not fully open source it. Not allow the community to drive the direction of change or fix bugs. Hopefully this is a temporary state, but it could very well be permanent.
An adjacent guess is Blaze will be frozen as it is today and depreciated slowly, not dropped outright, only due to the: lack of proper Meteor React/Angular integration generally, lack of proper Meteor-integrated package coverage even at the basic level in some cases, lack of written guidance for Meteor React/Angular, and finally legacy Blaze customers and developers.
This comment seems to suggest Tracker and Blaze as stand alone, open sourced, community driven projects are a possibility (fingers crossed):
I think Tracker and Blaze would be a great contribution to open source by MDG.
Hope this helps. 
3 Likes
If I may ask a stupid question, and coming late to the party it might be.
What is the reason to drop Blaze for Angular/React? Why cant Blaze be the React/Angular replacement? From my 2 weeks of tinkering and evaluating Meteor i find it totally awesome! What are the pressures causing Blaze to be made to seem “sub-par”, is it due to the backers of each of the tech? Can it not be monetized? Being green behind the ears with it, it seems to me it would be the selling point for Enterprise Meteor.
1 Like
I didn’t get any level of certainty from this message. Is MDG still working to improve Blaze or not? Are you simply maintaining its current state while working to improve Angular/React-Meteor until they are up to par with Blaze, then focusing exclusively on Angular/React once that happens?
3 Likes
I think the recent turmoil in this community comes from people not wanting to have their time wasted. I, for one, don’t want to invest enormous amounts of time in a serious project that is built off deprecated things, since it likely means those things will no longer be maintained. It’s a form of waste and I don’t have unlimited resources or bandwidth to spend flip flopping my projects around different technologies and playing with code that really has nothing to do with providing users with real world value so please just give a definite answer. As one member of the community has mentioned, it would be extremely helpful if MDG gave a list of intended or proposed developments for Meteor this year or for the next several months.
5 Likes
- Blaze 2 looked like React (don’t re-invent the wheel)
- MDG doesn’t have the resources
- Lack of SSR, no default component model, no adoption outside of Meteor, less maintainable for teams, lower re-render performance
- Unlikely to be worth the effort
Shame there’s still so much uncertainty on development of Blaze etc. Should really have been cleared up by now…
Thank you for continuing to treat Blaze as a first-class citizen in the Meteor framework.
@gschmidt I’m actually happy to hear this news. Thanks MDG for keeping Blaze.
But please can you clarify this statement?
We’re going to continue improving support for other view layers (Angular and React) until they’re at parity with Blaze, including the Guide. In the longer term, we expect that most of the usage will gradually shift from Blaze to Angular and React. How long MDG maintains Blaze will depend on how much usage Blaze continues to get in the community, especially among our business customers.
Because this sounds for me like the exact opposite of this statement from you:
Speaking as MDG, we are going to continue making Blaze our main recommendation for new apps in Meteor, while also standing behind Angular and React for those that prefer them.
Thank you
1 Like
Where did you get this idea? 
It’s simple actually:
After calls from the Meteor Development Community for Tracker and Blaze to be treated as a first class citizens (meaning, for bugs to be fixed, enhancements to be made, and for both packages to be broken out into NPM), @gschmidt answered by twisting this on its head: He called for MDG to continue working to make React and Angular first class citizens (instead of Blaze) on par with Blaze, and when MDG thinks sufficient parity has been achieved they’re going to drop Tracker and Blaze from first class citizen status. See what he did there? 
Listen, MDG has already made up their mind – they’re all in on React. That’s fine and it’s their call to make since, with the relatively limited number of Meteor users, and even fewer Meteor users that actually care about Blaze, no one in that pool has the inclination or bandwidth and know-how to make much fuss over it.
Anyone that has an issue with MDG’s choice has a decision to make, suck it up and make the switch to React or go to the few if any alternatives. MDG understand this, which one reason why they feel comfortable making drastic changes (such as this, but it won’t be limited to this I can assure you) at this point in time.
1 Like
When is MDG going to stop flip flopping and stick to a specific path? This is what the Rails community keeps warning newbies about when venturing into Meteor. At least with Rails you know where you stand and have an idea of what is coming down the pipe.
Most applications don’t need React in the first place. Unless you’re building amazingly complex UI’s, on the scale of Facebook, you generally can ignore React. Seeing React popping up all over the place where it isn’t needed is just overkill. So many static sites are using React, just to say they are using React. Why? Epeen.
Stick to Blaze. It’s what helped sell your platform in the first place. Don’t let investors influence your decisions. Let the feedback of your users help forge your path. Focus MDG, focus.
5 Likes
imho
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 
5 Likes
@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.
1 Like
-1 likes
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.
2 Likes
- Yes
- Of course
We shoudl continue this way
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.
Indeed - Blaze was the first thing I saw when I started Meteor and I was like 
. React also has me like but in a different way.
1 Like