Yes, I have read this, but why you want to push me think in React?
For me Meteor is great because I can use it for different kind of apps (from small to big, from simple to very rich interface). I use and like React when it’s best match but sometimes it just doesn’t’.
I am not pushing you to think in React. If you like Blaze templating, great! Stick with Blaze 1 for now, and Blaze 2 whenever it’s out.
That link was for guidance on how one could collaborate with designers if the UI is directly written in ReactJs (JSX), for those who think it’s impossible.
Are you trying to compare Meteor with React here? Or if you mean you’ll be forced to use React because of Blaze2, I think your opposition to React is the syntax right? MDG says that with Blaze 2 you’ll continue to use a templating like interface which will likely be very similar to Blaze 1. Wouldn’t that suffice? If your designers can work well with Blaze1, I think that should be the case with Blaze2.
If you have any technical reasons against choice of React as the underlying engine of Blaze2, then please articulate them too to the community and MDG; would help us all.
@gaurav7 It was not exactly opposition of React syntax, it was more feature request of what I want to see and don’t want to seen in Blaze2.
I just commented what I don’t like and what I like in React and Blaze as @evanyou asked. Somewhere in this thread is my longer answer (or even a few) of what I would like to see in “Blaze2”.
Cool, and my original point was only to address concerns raised in this thread that JSX is particularly “designer unfriendly”. Shared the link in case anybody with those concerns hasn’t seen it.
For some reason all the feedback you guys are giving about this “Blaze x React x Angular” storm, is technical. While the major concerns have nothing to do with technology or even Facebook’s size. The concerns are related to trust & keeping the eco-system together. Words like “we did not take it lightly” make it worse, as they clearly did not take the community with in this “not-lightly”. Basically you are saying “when we take things seriously, then community is not part of the discussion” . Ahhh.
If you really must split from Blaze and announce defeat there, ok, fair enough. But then MDG please at least show courage and try and win your followers back (yes, wake up, you lost them, I pity the guys writing books for you).
You can do so by making an effort to stop all the other core doubts. Make the important stuff 1st recommended citizens and demote the rest to community. I think of things like:
Just look at the number of outstanding issues with Blaze and how they are (not) fixed… If that is not killing enough, what is?
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.
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?
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.
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?
That’s like being tortured continuously with small needles instead of one time with a big stick? Tempting… tempting 
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 !
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.