It’s really hard to address every question in this thread, so I’ll just put down a generic Q&A (opinions are personal, but based on my impression from internal discussions at MDG):
Why are you reinventing the wheel again?
We are not “reinventing” anything. It could be misleading to label this new project as “Blaze 2”, or giving it the name “Inferno” - what we are hoping to build is a thin, optional layer on top of React, with full interoperability with all the components and libraries in the React ecosystem. The primary goal of this project is to lower the barrier of adopting and migrating to React.
Old Blaze code will continue to work, and it should be totally possible for both solutions to co-exist in the same project. My hope is that a user should be able to incrementally migrate an app to the new solution without committing to a complete rewrite.
Why React? Why not something else?
We believe React is currently the strongest view layer solution in the JavaScript ecosystem. The advantages of using React include:
- Robust component model
- Easier to reason about state
- Huge ecosystem of reusable components, libraries, tooling and learning resources.
- Has robust and actively maintained routing solutions, e.g. react-router, flow-router.
- Plays well with modules, Webpack, SSR, incremental loading etc.
- Maintained by dedicated team at Facebook, and used in production by many serious businesses.
- Opens up the possibility of leveraging ReactNative
- React core is focused on the view layer and does not impose too much architectural decisions on the user, therefore making it a better fit for integration than more opinionated frameworks like Angular.
My personal opinion is that focusing on how “fast and easy to get started” is somewhat shortsighted when picking a view layer. Our end goal is to enable Meteor users to build large applications that are scalable and maintainable, and we’ve found that:
- Blaze in its current form doesn’t serve that goal well, and it will not improve if we maintain 100% backwards compatibility.
- React checks a lot of boxes in terms of what we want to see in a “better Blaze”;
- The amount of effort and resources required to maintain a competing solution with feature parity and the same level of mindshare is huge (think ~20 full time engineers) and may not be the best strategy for MDG.
- But there are things we want to keep in Blaze. React can be hard to jump into. Hence this “template for React” project.
Note that it would require non-trivial refactoring effort even if you are migrating to a Blaze-based solution, as long as it demands a different API (e.g. Blaze Components or ViewModel). We think it’s better off in the long run if that effort be spent on migrating to a React-based solution instead.
What we are asking for is the community’s trust that MDG is making this decision by placing the users’ long-term interest first.
But I hate JSX!
The exact purpose of this “template on React” project is so that you will not be forced to use JSX when using React. It also doesn’t prevent you from dropping down to JSX if it ever becomes necessary.
You should leave Blaze alone and solve other problems first.
This is the first step we are taking in terms of re-aligning Meteor with the bigger JavaScript ecosystem. We are well aware of the other possible improvements such as better NPM integration, ES6 modules, easier way to leverage external build tools such as Webpack… etc. @benjamn is already working on that front.
As mentioned above, this view layer project is intentionally limited in scope so that we have bandwidth to tackle other problems at the same time.
I don’t trust Facebook.
The problematic patent clause has been removed, and that, in my opinion, in fact shows that Facebook is well-intentioned and committed to its open source efforts. I also don’t think the impression with developing for its app platform has strong correlation with the quality of its open source projects. It’s more reasonable to judge after you’ve actually tried the technology in question.
This will hurt Meteor’s package ecosystem.
A unified view layer does have its benefits. However, I’d argue that by adopting React you in fact get to leverage a much more active ecosystem in terms of view layer components. Easier NPM integration will also help out in this aspect.
I admit that if you are relying on packages that are tightly-coupled to Blaze, it would indeed be a painful process. That is why I hope we can come up with an incremental migration strategy that doesn’t force you to fix everything at once.