So it sounds like you and @sashko agree that productivity (time saved) over Blaze might not be a thing after all?
I've heard this before, but it's foggy to me what this means. To put more meat behind this, are you saying if you change something like a Global Session, in one place, it's hard to reason about what the affects to the system are because one might not be able to reason about where this particular Global Session is used throughout the system?
Why isn't a simple find command enough for me to find all the spots a global session occurs, review the code, and reason about what making a change in one spot will do to the rest of the code? Isn't this how coding works throughout all the languages and from the very beginning? There has to be side affects in React -- make a change in one place and affect another. Don't you do a find string to find all the affected places and reason about outcomes in React too? Where's the disconnect?
Also, is there no such concept as Globals in React? How are the majority of bugs caused in React, by not reasoning about where data comes from and where it's going?
By the way, I very rarely use Globals in Blaze. For the things I do, and there's only a handful, they have distinct responsibilities and naming conventions and are used in very few places in the code.
No tweaking and no code rot occurs with React?
I missed where @sashko said writing code is easy, but I think we can all get behind the sentiment that maintaining code is hard. I'm happy to report so far, maintainability has not been an issue here in Blaze land.
This is encouraging. Is React much easier to change because of being componentized or another reason?
For example, I have a template that's just a form input field, with styling and logic within. I use this on every form, multiple times per form. When I first built the template (aka component), I found I needed to make changes more often to it. When I made a small change, instead of changing every input field of that type in all my forms in all my templates, I made a change to one spot and it propagated everywhere. That to me is an example of productivity and maintainability. Is it any different with React?
So it is possible to write React code too. I worry about not following the right path if I transition to React. I read about containers of components, and where data should be feed into. It's taken me a while to get my good patterns and practices down that promote code maintainability in Blaze.
Just as you had initially found out what makes for a maintainable React app, so too can one find their way to a maintainable Blaze app. I don't know, but it sounds like all things being equal React might be more maintainable, but what I'd love to see is a side by side comparison of good code written in both, rendering the same thing to the screen and talk/write through the pros and cons.
Also, for the most part I don't use hidden context, global state, and I'm organized where I put async things -- so just because something can be done, doesn't mean it will. I'm sure there are gotchas and edge-cases in React too that make it a pain to maintain.
Glad to hear there are strong conventions and a "React way" of doing things. This is reassuring that if I decide to make the migration, there will be guidelines.
To be fair, there are ways to write Blaze that make it easy to work on as well. You have experience with both Blaze and React, me only Blaze, so I cannot make a real comparison for myself. You seem to have honorable motives, are good intentioned and competent, so I do assign your opinion some weight.
Having said this, I too have recently looked into making the switch to React, but not for any of the virtues you sited. Not because of productivity or maintainability or how easy or not it is to reason about. Having a large application, I have no real issues with any of the above and my clients are very happy with my turn around speed.
I've looked at making the switch to React only due to MDG dropping official support and the unknowns around community involvement. I think the premise of this thread is really, if the community steps up and maintains and improves Blaze, would you return or stay with Blaze. I think for me it's too early to tell because it's not only how fast things "improve" but what the improvements are, what gets prioritized.
Does the community put time into making Blaze easier to reason about and maintain? Does it address performance by adding virtual or incremental DOM? Server side rendering? Will Blaze build-in a more modular, explicit approach out of the box? These are all questions yet to be answered. Until we get a clearer picture here, I can't say for sure if I'll stay or if I'll go.