RIP Blaze 2. We’ll miss you! 
But does it mean Blaze 1 will still be developed?
7 Likes
So MDG switched from Blaze, to React, to recommending Blaze again. Newbies don’t have a chance do they lol. Like trying to shoot a squirrel while on a boat deck over choppy waters. A pretty fast moving target.
#Meteor: Hard Target
I just hope you guys pick something and stick with it. Blaze is fantastic and more than good enough for the vast majority of projects, no?
15 Likes
Awesome post.
Looking at the Guide, I can see it’s separating reusable components (stateless) from smart components (stateful), something we learned from React community. Things like this make me expect a great sinergy for this three view layers being supported by MDG and community, “paving the cow path” for next features and development patterns.
This is great news.
MDG will still support Blaze, (and for that I am grateful) but will also provide Guides for React and Angular.
My emphasis above - see: http://guide.meteor.com/blaze.html
For me, and the company I work for, and the app we’ve created with Blaze, it means we can continue updating our app with Blaze.
“Eventually…” we may need to switch to React or Angular, but… for now, Geoff seems to be saying that Blaze is here to stay.
That’s a good thing - and straight from the horses mouth, if you will.
6 Likes
@gschmidt, Thank you for sharing MDG’s strategy for the View Layer with the community.
@gschmidt this seems like great news.
@gschmidt, React and Angular are being developed and maintained outside of MDG, yet in this regard there is no parity for Blaze.
Will MDG allocate resources to Blaze and Tracker in areas outside the Meteor Guide? For example, will Blaze PRs be accepted from the community? Will MDG allocate resources towards Blaze enhancements or bug fixes? Will MDG allocate resources towards moving Blaze and/or Tracker to a more NPM modular-model? Will MDG move to truly open Blaze and Tracker into community driven projects?
8 Likes
Good point. What I read is that Blaze is still not developed further and that the pickup of React and Angular so far isn’t good enough and MDG asks to get both of them to the same level (to finally kill Blaze once the disadvantages that Geoff highlighted vs Blaze are eliminated?)
Said it before and will repeat it. Meteor forgets what made them big. Those ten (or even hundred) thousand developers that use Meteor for fun or in small projects.
MDG wants big companies to switch to Meteor as it needs to pay back the VC’s that huge money they invested. Us small chicken won’t help pay the debts back as all we use up is free hosting on Meteor.com instead of paying for Galaxy.
Like it was written on Kadira Voice, soon Meteor will be just another packaging solution and the masses will have moved on to the next free, open-source solution where stuff is built for them, not for big companies!
R.I.P. Blaze and maybe Meteor as well in 1-2 years
1 Like
@gschmidt when are you letting us know your plans to replace Meteor’s LiveQuery and pubSub system with a GraphQL and Relay (powered) system?
It would be nice to know what direction you guys plan for all this so package developers don’t waste time doing what you are doing already.
My recommendation is you use GraphQL and Relay but build a simple API on top that be used within your react components (or even other view libs). The idea would be that you get to take advantage of the emerging GraphQL and relay ecosystem (eg mongoose and graffiti etc) even though you abstract its complexity away from application developers (on both the client and server). Om next has a great model for this that’s a lot simpler than Relay and it supports subscriptions out the box via Datomic. On a side note, ClojureScript and Om Next overnight have become a full stack framework on the level of Meteor, but functional, which is all the craze. I’d watch out for cljs defectors, especially if you don’t nail the Relay implementation ASAP.
Ps. MDG mainly needs the following UI and client side features addressed for the aforementioned view frameworks:
- datatables!
- modals and flash messages
- forms
- routing in core (with built-in coupled code splitting)
- accounts stuff
Not much more. …so is ur plan for MDG to build all this stuff which used to be built by community developers like @aldeed but now for both Angular and React?? Is that the idea? Or just keep focusing on Galaxy while hopefully we do it. I’m not saying that with any sort of tone–my main gripe is I have no idea what MDG is planning to build still, which means if I pick the wrong packages to work on I could end up doing what u guys will do anyway. So that’s why we need to know your roadmap. It feels like we are being put at bay via these conversational announcements because you still don’t have the bandwidth to address it. That’s ok too. I just wanna know what the deal is instead of being treated like a child, Geoff.
I’ve been exclusively using your framework for 3.5 years, and am in the midst of “leveling up”, if you will, to Clojurescript. Give me a reason to stay! Again I’m not saying that with any sort of tone–I’m just trying to paint a picture of where I and many meteor developers are coming from. It feels in a way that we are being toyed with.
My guess is the message you aren’t telling us is simply that you have zero bandwidth for new APIs and therefore nothing is actually getting built; ur entire staff is focused on Galaxy and bugs. Just tell us that instead of leading us to think ur building some stuff behind the scenes, which if u r, it would really be nice to know what it is.
This latest post of yours has shed a small amount of light, but overall we are still in the dark. I think too much so and too much time has gone by at this point that many of us are considering defecting if they haven’t already. The pace at which the greater js/NPM community is moving has necessitated this. You have a major problem on your hands and I don’t think you see how big it is–because the defectors one day silently bow out, and they are no longer part of any vocal minority complaining anymore. So what that means is its hard to really tell whether ur losing users or not. I can tell you without a doubt that you are. Likely your best developers too–the same ones that in yesteryear would build these packages so you don’t have to. I know it’s scary; I guess keep going down this path, but this winter is the time to really give us some insight as to what’s going on in MDG and what your whole team is working on.
All that needs to happen is we need to know what MDG plans to build between now and summer time.
8 Likes
All that needs to happen is we need to know what MDG plans to build between now and summer time.
Well, I guess this has always been the greater problem with the relationship between MDG and the community.
But I’d say we should cut MDG some slack. If anything, this last post is a sign that MDG is listening, although not visibly participating, but perhaps actually is. I choose to give them the benefit of the doubt and bet that I won’t be let down.
The guide for React should appear soon, though because apart from the blaze vs react split, (meteor) react development itself offers way too many options. I just don’t want to be constantly second guessing my choices and looking over my shoulder for better ones.
6 Likes
I’ve read this post a few times but I’m finding it hard to understand what geoff is saying.
You should or you are? Sounds like you’re asking us…
Does that mean those of us whom you recommended to start new apps with React and find it to be working without a guide should continue with React?
And is this eventuality measured in weeks? months? years? And will Blaze be phased out when the recommendation switches? Either way, I’d not recommend my company to be adopting blaze with this sort of assurance.
These are both correct observations that point out completely different sentiments. It almost sounds as if you’re still trying to sell react.
Well, I really didn’t mind Blaze, but as it was dying, I jumped onto the React bandwagon, now I’m getting signals that Blaze isn’t really dying… maybe… because there’s a better guide to building an app with it?! Doesn’t make any sense.
The problem when I moved away from Blaze is that I also moved away from atmosphere. When coding in React, you just work with React’s ecosystem, so much easier to be in one ecosystem.
Atmosphere was what made building apps easy. It made Meteor great! Without atmosphere, Meteor was just node+express+websockets.
I’m still really confused about the message being given by Geoff. Initially I thought it was a full 180, but the wording is too unsure. It sounds like he’s saying we’re recommending Blaze until we can write a better guide with React and/or Angular2. It says nothing about what they’re going to be working on. Only that they’re dropping the Blaze-React project (thank god for that at least).
13 Likes
I’m glad Blaze will continue to support this, but after all the drama, it’s weird to come back to square one. Will there be any improvements to Blaze? I think it desperately needs code splitting, but the rest of it is good.
I also wrote a Medium post on the subject:
8 Likes
I like how you think man. What do you do when you’re not on the forums?
4 Likes
Am happy to know Blaze will stay onboard, but hope you will elaborate on whether it will be developed further.
I, for one, am very happy you’re not just making a decision and sticking to it.
I think the right decision is worth the turbulance that comes with it 
after all, it’s a lot easier to just ignore change and not admit to making mistakes…
1 Like
This is why new comers, like me, are struggling to get a MVP demoed. You start to learn this but only to find out that in few months it won’t be supported. I like React, used Blaze once and will never use it again.
3 Likes
A very good decision. There’s nothing wrong with Blaze, too much attention is going to React, but Blaze is just easy and works like a charm for most apps. With a bit of work / thinking you can even make your Blaze app have a structure like React, including reusable components. And every view layer has it’s cons, but those can / should be improved.
For example, Blaze + Viewmodel is superior stuff. It makes code much more readable and shorter, even compared to React (see the comparison on the site). IMO, MDG should have a better look at Viewmodel and make the Blaze API more like it.
12 Likes
Exactly what I concluded after reading Schmidt’s post
1 Like
That’s cool. Now people can stop complaining. From the point of view of an enterprise…we’re still going to move to React. We can recruit better, onboard faster. And we don’t look for “meteor” developers, just good JavaScript developers. You’ll find more often than not someone who knows blaze only knows meteor and not a broad understanding of the js ecosystem. So that’s what I caution people using blaze still…be cognizant of the greater js community.
8 Likes
thats why you should just do you and not listen to all this NOISE in the forums. get your mvp done.
9 Likes
I didn’t get the memo. I thought MDG was abandoning Blaze in favour of React and Blaze 2 (a Blaze-like syntax built on top of React).
I agree that there’s a lot that can be done RIGHT AWAY with Blaze that still cannot be done with React just yet. God, can we have a solid decision either way?
This is a terrible time to be starting new projects 
3 Likes
I appreciate the post, but all of this is still a blow in the wind without any insight into the roadmap, topic headcounts and ETAs. The exact reason why our tech advisory is not embracing meteor as a full stack => minimizing dependence on meteors unknown timeline.
Odd, but after this post, we are still sticking with NPM and do not recommend to depend on meteor packages. And as Abhi put it:
PS:
@gschmidt finally pull your community tech intelligence, such as @faceyspacey, into private conversations about easy wins for meteor
2 Likes