Late last year I posted a message about how MDG was thinking about the view layer and where we thought we should go next. Since then, we’ve had many more conversations, both here on the forum, with the Customer Advisory Board we formed last year, and 1:1 with teams ranging from large production users to Meteor non-users, and in environments ranging from small startups to large enterprises.
Against that backdrop, I wanted to share what we’ve learned and talk about where to go next.
The Strength of Blaze
Blaze is a hugely valuable part of the Meteor ecosystem. The main reason for this is easy to miss, yet is obvious when you look at, say, the Meteor Guide.
The biggest strength of Blaze is the ecosystem around it - all of the amazing packages and components that our community members have written and generously shared on Atmosphere.
You might expect that Angular or React would have comparable or superior package support. Sure, those ecosystems have a ton of great view layer components! But today, if you try to duplicate the Meteor Guide in React or Angular, you’ll find that you have to do significantly more work, because those view layers lack the ecosystem of full stack components that exist around Blaze – packages that provide not just the view component, but also a slice of the app functionality that goes behind it. Examples include accounts, and the many packages built on top of autoform.
This ability to create and share “full stack components” is hugely valuable, and is the fruit of building an integrated JavaScript platform. It’s not a property of Blaze, it’s a property of Meteor. The reason that Angular and React don’t have as much here is because you can only write these packages in the context of a complete platform, like Meteor, and Angular and React don’t have as long of a history with the Meteor community.
View Layer Platform Strategy
If Blaze were the only view layer in the world, this post could end here. However, it’s not, and that’s good news.
Angular and React both are great products with fantastic teams behind them and thriving communities. The competitive dynamic between the two is driving a huge amount of innovation for JavaScript. And, in the long run, it’s better for the JavaScript community to unite between one or two options rather than to split our forces maintaining our own independent, but increasingly convergent, flavors of reactive HTML binding.
Our goal with Meteor should be to build the industry standard JavaScript-based full-stack app platform. So now we have a decision to make, and forces pulling us in several different directions.
-
On one hand, we’d like to be view layer agnostic. No matter what view layer you use, you need what Meteor has to offer. Angular? React? Blaze? Smaller projects? Support them all!
-
On the other hand, choice has a cost. A cost in terms of the burden on developers to research and make the right choice, and a cost in terms of fragmentation (dividing the community’s efforts between several options).
This decision plays out at every level of the stack, from the view layer to testing frameworks to databases. What we want is not every possible choice, and not no choices, but the right choices. The view layer seems like the right place to offer a choice, since without it Meteor cannot become the industry standard.
So, I think we should aim to support React, Angular, and Blaze as equal partners. That means expanding the Meteor Guide to cover all three, not just Blaze. It means bringing the ecosystem of full stack packages around React and Angular up to parity with Blaze. And it means tooling improvements to support Angular and React, for example, bringing the out-of-the-box Meteor React tooling up to the quality of the tooling you can build yourself with Webpack (for example around build times).
For now, between React, Angular, and Blaze, there is no single best choice. All have pros and cons and you can’t yet “have it all”. Speaking as MDG, we are going to continue making Blaze our main recommendation for new apps in Meteor, while also standing behind Angular and React for those that prefer them. The reason for this is that the ecosystem of full-stack packages around Blaze is so powerful – we can write a much better Guide against Blaze. Eventually we may switch that recommendation to React or Angular 2 as they come up to parity with Blaze.
React Templating
Last year, we proposed to build a templating system on top of React, to give a Blaze-like user experience on top of the React engine.
As we went to hammer out the details of the design, what we found was that not many people actually want this. People who want to use React want to use 100% idiomatic React-style React. People who want to use Blaze want to keep using Blaze, and especially want to keep using Blaze full-stack packages. People who have large Blaze codebases, but like React and want to switch, want help structuring their codebase so they can make the transition incrementally, not a different syntax.
We’ve heard you. We’re cutting this project. Instead, we will put those resources toward the strategy described above: helping to build up a great full-stack development experience, complete with Guide, for Angular, React, and Blaze.
Not everyone likes React’s JSX. But JSX is the React way. Teams that don’t want to use JSX have good alternatives in the form of Blaze, Angular, and soon Angular 2. We’ve also noticed that developers of many skill levels – from elite, super experienced developers to new bootcamp graduates – can pick up JSX easily, and once they do they generally like it.
Meteor Pride
Our pride as a community should come from building the best stack that provides the best development experience. As we think about our platform strategy choices, let’s stay focused on that.
Lots of smart, kind, dedicated people around the world are working on JavaScript right now, and that’s a blessing. Meteor should be about pulling together the best ideas into one cohesive whole, wherever we find them.
after all, it’s a lot easier to just ignore change and not admit to making mistakes…