Just look at the number of outstanding issues with Blaze and how they are (not) fixed… If that is not killing enough, what is?
10 Likes
That’s a pretty good one.
Just to be clear, my stance isn’t that we should all convert existing apps to a new view framework, just that moving forward for new projects, certain frameworks offer benefits over others (Vue, Angular, React, etc…)
I still have a Blaze app and it’s not really worth the time it would take to convert it over. It’s making money, and Blaze is performing well. Packages still work.
However, for me new apps will not be using Blaze.
6 Likes
I’ve been lurking in the Meteor community only for the last few months, so may have missed key historical events. But apparently “Blaze 2” has been pending for long, and this announcement sounds like MDG finally wants to do something about it…
I guess I’d ask the same question as: Which of the outstanding Blaze issues in Github would be taken care of by Blaze 2? If not in the first release of Blaze 2, then maybe in a future roadmap?
4 Likes
Good point. I suddenly realized that no one (me included 
) actually asked that question in this topic before.
So, which Blaze 1 issues (GitHub or not) will be directly addressed by Blaze 2 and what is the priority list?
I’ve built a small startup using Meteor and Blaze over the last year. The B2B application is what I would consider large in size and is used by many clients. My software runs on AWS and I’m a potential Galaxy customer.
In a way I’m one of the lucky ones. I started off when there was only Blaze and Iron Router. When looking for Meteor packages to leverage, such as aleed@autoform, where was no question as to what technologies it used. When looking for answers on Stack Overflow et. al., everyone was on the same ‘technical’ page. The book Discover Meteor along with other beginner to intermediate resources helped a lot; again we were all speaking the same technical language.
So far, I’ve been able to focus on business value more and technical details less (this seems about to change). Although, over this last year I have become what I would consider a intermediate-to-advanced Meteor + Blaze developer.
Having said this, in another way, me and the business I’ve build with Meteor and Blaze are now in a precarious situation.
With MDG’s recent pronouncement regarding the depreciation of Blaze, as a small business owner with paying, long term customers, I’m now faced with several dilemmas, all of which will have a impact on my bottom line.
Doing a full rewrite in React could cost me months of costly rework with little to no benefit to my bottom line. This rework will take me away from feature requests and bug fixes that will delight my clients and in some cases enhance my bottom line.
If I choose not to do a full rewrite, Blaze and all the bugs and performance issues it has (and now will always have), will start to cause a drag on my bottom line. As packages migrate away from Blaze or become abandon-ware, I’ll be unable to provide meaningful enhancements and bug fixes to my application.
If I choose to do a full rewrite in Blaze 2/Inferno I’ll be in the same situation as the full rewrite in React.
I’ve been disappointed in the way MDG has handled this situation. MDG has seemly sacrificed its developer base to protect/enhance its own bottom line in this case.
Why drop Blaze support entirely to the detriment of your exiting developer community and their bottom line?
Why can’t Blaze and React live side-by-side in future versions of Meteor without breaking my existing Blaze 1 code base?
Why not have one MDG developer on Blaze fixing bugs and stabilizing while we ever so slowly migrate to React? Heck, I’d be willing to pay a monthly fee to see Blaze 1 bug free and alive over the long term, just as I would be willing to pay for Galaxy.
The decision to drop Blaze will have a meaningful impact on my business, my customers, and my bottom line; I’m sure many others are in the same boat.
To: @gschmidt at MDG, please consider your existing Meteor developer base and their bottom line too when deciding on the future of Blaze – the ones that took a chance on your tech, the ones that evangelized, your potential future playing customers.
23 Likes
Is there an option for you to start writing your new components in React, and then migrate some of your old UI as needed? As you said, all of your code still works, barring some performance improvements, etc. so I don’t think you need to do a big project to rewrite it all at once?
2 Likes
That’s like being tortured continuously with small needles instead of one time with a big stick? Tempting… tempting 
3 Likes
I mean, it’s going to be less work overall than rewriting all of your business logic in Rails + Ember, as far as I can tell.
Great ! The rewrite will be less painful than migrating to another framerwork ! Problem solved !
5 Likes
I’d like to add Cordova / Mobile to this list.
You made my day 
You can have all of the vision in the world, but if your customers are telling you they don’t like your vision, then plain and simple: they don’t like it.
Did you re-read this before you posted it? On the one hand you’re saying that a re-write in React will have no benefit to your customers and that it’ll just be an expensive port, on the other you’re saying you will have to just accept the numerous bugs and performance issues Blaze already has… If fixing bugs and gaining large performance increases (your words not mine) doesn’t enhance your “bottom line” then I don’t think there’s much hope for your customers.
This is exactly what I am in the process of doing right now. It works, it’s easy, it’s pain-free.
3 Likes
You might re-read his @aadams post, as it is very well-thought I think. You are missing the time-factor I think, writing around bugs today is something different as being confronted with it tomorrow, when packages update or expose, and so on.
1 Like
I’m just simply pointing out the fact that he is complaining about being forced to change his code to get performance improvements and bug fixes… Which implies he has performance issues and bugs now. If he doesn’t, this argument becomes a moot-point, he can continue running the code he has now, as-is, with no issues.
The change to “Blaze 2” or whatever they call it I’m sure will be the most minimal change that MDG can make it, whilst still retaining all of the benefits of utilizing React as the underlying view-model.
I just see this argument as making a mountain out of a molehill, and I say that as someone who has invested a massive amount of time in creating a Meteor application that is currently released, being used by customers and was (until v. recently) entirely written in Blaze.
4 Likes
I’m in the exact same situation, and I think many are. However I do trust MDG to make the transition as smooth as possible.
1 Like
How about a tutorial on mixing Blaze & React? (And best practices around it?) Is there something like this out there?
My Blaze UI could use some performance improvements for a certain (sub) template, what would be the best approach to rewrite that?
1 Like
In my opinion, this is a straw-man argument:
Lets just say I have no issues with Blaze 1 right now, as is (to wipe away the point you made based on assumption).
The second sentence in my original post alone is enough to cause what I believe is a serious encumbrance on my bottom line:
The following is what I would consider ad hominem comments:
I’d like to keep the discussion civil.
It is intellectually dishonest to brush off an individual’s reaction to a situation as unacceptable because it is not the same reaction that you would have:
I’d say this is an appeal to questionable authority:
Further, as to your statement about the migration from Blaze 1 to React:
I’d just like to point you back to my original post:
In sum, my conclusion:
I believe we, the Meteor developer community, has been given False Alternatives, either stay with Blaze 1 or Migrate to React (or Blaze 2). There exists an alternative that seems unconsidered by MDG, I believe to the great detriment of the existing Meteor developer community:
Namely keeping Blaze 1 around for the long term in support of their existing Meteor developer based. And in so doing maintaining, bug fixing, and possibly ever-so-slightly enhancing Blaze 1.
The result I believe will allow MDG’s Meteor developers time to breathe, adapt, adjust, and migrate to new technologies as MDG too adapts to its changing environment.
4 Likes