Angular, React, and Blaze

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.

111 Likes

RIP Blaze 2. We’ll miss you! :wink:

But does it mean Blaze 1 will still be developed?

7 Likes

So MDG switched from Blaze, to React, to recommending Blaze again. Newbies don’t have a chance do they lol. Like trying to shoot a squirrel while on a boat deck over choppy waters. A pretty fast moving target.

#Meteor: Hard Target

I just hope you guys pick something and stick with it. Blaze is fantastic and more than good enough for the vast majority of projects, no?

15 Likes

Awesome post.

Looking at the Guide, I can see it’s separating reusable components (stateless) from smart components (stateful), something we learned from React community. Things like this make me expect a great sinergy for this three view layers being supported by MDG and community, “paving the cow path” for next features and development patterns.

This is great news.
MDG will still support Blaze, (and for that I am grateful) but will also provide Guides for React and Angular.

My emphasis above - see: http://guide.meteor.com/blaze.html

For me, and the company I work for, and the app we’ve created with Blaze, it means we can continue updating our app with Blaze.

“Eventually…” we may need to switch to React or Angular, but… for now, Geoff seems to be saying that Blaze is here to stay.

That’s a good thing - and straight from the horses mouth, if you will.

6 Likes

@gschmidt, Thank you for sharing MDG’s strategy for the View Layer with the community.

@gschmidt this seems like great news.

@gschmidt, React and Angular are being developed and maintained outside of MDG, yet in this regard there is no parity for Blaze.

Will MDG allocate resources to Blaze and Tracker in areas outside the Meteor Guide? For example, will Blaze PRs be accepted from the community? Will MDG allocate resources towards Blaze enhancements or bug fixes? Will MDG allocate resources towards moving Blaze and/or Tracker to a more NPM modular-model? Will MDG move to truly open Blaze and Tracker into community driven projects?

8 Likes

Good point. What I read is that Blaze is still not developed further and that the pickup of React and Angular so far isn’t good enough and MDG asks to get both of them to the same level (to finally kill Blaze once the disadvantages that Geoff highlighted vs Blaze are eliminated?)

Said it before and will repeat it. Meteor forgets what made them big. Those ten (or even hundred) thousand developers that use Meteor for fun or in small projects.

MDG wants big companies to switch to Meteor as it needs to pay back the VC’s that huge money they invested. Us small chicken won’t help pay the debts back as all we use up is free hosting on Meteor.com instead of paying for Galaxy.

Like it was written on Kadira Voice, soon Meteor will be just another packaging solution and the masses will have moved on to the next free, open-source solution where stuff is built for them, not for big companies!

R.I.P. Blaze and maybe Meteor as well in 1-2 years

1 Like

@gschmidt when are you letting us know your plans to replace Meteor’s LiveQuery and pubSub system with a GraphQL and Relay (powered) system?

It would be nice to know what direction you guys plan for all this so package developers don’t waste time doing what you are doing already.

My recommendation is you use GraphQL and Relay but build a simple API on top that be used within your react components (or even other view libs). The idea would be that you get to take advantage of the emerging GraphQL and relay ecosystem (eg mongoose and graffiti etc) even though you abstract its complexity away from application developers (on both the client and server). Om next has a great model for this that’s a lot simpler than Relay and it supports subscriptions out the box via Datomic. On a side note, ClojureScript and Om Next overnight have become a full stack framework on the level of Meteor, but functional, which is all the craze. I’d watch out for cljs defectors, especially if you don’t nail the Relay implementation ASAP.


Ps. MDG mainly needs the following UI and client side features addressed for the aforementioned view frameworks:

  • datatables!
  • modals and flash messages
  • forms
  • routing in core (with built-in coupled code splitting)
  • accounts stuff

Not much more. …so is ur plan for MDG to build all this stuff which used to be built by community developers like @aldeed but now for both Angular and React?? Is that the idea? Or just keep focusing on Galaxy while hopefully we do it. I’m not saying that with any sort of tone–my main gripe is I have no idea what MDG is planning to build still, which means if I pick the wrong packages to work on I could end up doing what u guys will do anyway. So that’s why we need to know your roadmap. It feels like we are being put at bay via these conversational announcements because you still don’t have the bandwidth to address it. That’s ok too. I just wanna know what the deal is instead of being treated like a child, Geoff.

I’ve been exclusively using your framework for 3.5 years, and am in the midst of “leveling up”, if you will, to Clojurescript. Give me a reason to stay! Again I’m not saying that with any sort of tone–I’m just trying to paint a picture of where I and many meteor developers are coming from. It feels in a way that we are being toyed with.

My guess is the message you aren’t telling us is simply that you have zero bandwidth for new APIs and therefore nothing is actually getting built; ur entire staff is focused on Galaxy and bugs. Just tell us that instead of leading us to think ur building some stuff behind the scenes, which if u r, it would really be nice to know what it is.

This latest post of yours has shed a small amount of light, but overall we are still in the dark. I think too much so and too much time has gone by at this point that many of us are considering defecting if they haven’t already. The pace at which the greater js/NPM community is moving has necessitated this. You have a major problem on your hands and I don’t think you see how big it is–because the defectors one day silently bow out, and they are no longer part of any vocal minority complaining anymore. So what that means is its hard to really tell whether ur losing users or not. I can tell you without a doubt that you are. Likely your best developers too–the same ones that in yesteryear would build these packages so you don’t have to. I know it’s scary; I guess keep going down this path, but this winter is the time to really give us some insight as to what’s going on in MDG and what your whole team is working on.

All that needs to happen is we need to know what MDG plans to build between now and summer time.

8 Likes

All that needs to happen is we need to know what MDG plans to build between now and summer time.

Well, I guess this has always been the greater problem with the relationship between MDG and the community.

But I’d say we should cut MDG some slack. If anything, this last post is a sign that MDG is listening, although not visibly participating, but perhaps actually is. I choose to give them the benefit of the doubt and bet that I won’t be let down.

The guide for React should appear soon, though because apart from the blaze vs react split, (meteor) react development itself offers way too many options. I just don’t want to be constantly second guessing my choices and looking over my shoulder for better ones.

6 Likes

I’ve read this post a few times but I’m finding it hard to understand what geoff is saying.

You should or you are? Sounds like you’re asking us…

Does that mean those of us whom you recommended to start new apps with React and find it to be working without a guide should continue with React?
And is this eventuality measured in weeks? months? years? And will Blaze be phased out when the recommendation switches? Either way, I’d not recommend my company to be adopting blaze with this sort of assurance.

These are both correct observations that point out completely different sentiments. It almost sounds as if you’re still trying to sell react.

Well, I really didn’t mind Blaze, but as it was dying, I jumped onto the React bandwagon, now I’m getting signals that Blaze isn’t really dying… maybe… because there’s a better guide to building an app with it?! Doesn’t make any sense.

The problem when I moved away from Blaze is that I also moved away from atmosphere. When coding in React, you just work with React’s ecosystem, so much easier to be in one ecosystem.
Atmosphere was what made building apps easy. It made Meteor great! Without atmosphere, Meteor was just node+express+websockets.

I’m still really confused about the message being given by Geoff. Initially I thought it was a full 180, but the wording is too unsure. It sounds like he’s saying we’re recommending Blaze until we can write a better guide with React and/or Angular2. It says nothing about what they’re going to be working on. Only that they’re dropping the Blaze-React project (thank god for that at least).

13 Likes

I’m glad Blaze will continue to support this, but after all the drama, it’s weird to come back to square one. Will there be any improvements to Blaze? I think it desperately needs code splitting, but the rest of it is good.

I also wrote a Medium post on the subject:

8 Likes

I like how you think man. What do you do when you’re not on the forums?

4 Likes

Am happy to know Blaze will stay onboard, but hope you will elaborate on whether it will be developed further.

I, for one, am very happy you’re not just making a decision and sticking to it.

I think the right decision is worth the turbulance that comes with it :smile: after all, it’s a lot easier to just ignore change and not admit to making mistakes…

1 Like

This is why new comers, like me, are struggling to get a MVP demoed. You start to learn this but only to find out that in few months it won’t be supported. I like React, used Blaze once and will never use it again.

3 Likes

A very good decision. There’s nothing wrong with Blaze, too much attention is going to React, but Blaze is just easy and works like a charm for most apps. With a bit of work / thinking you can even make your Blaze app have a structure like React, including reusable components. And every view layer has it’s cons, but those can / should be improved.

For example, Blaze + Viewmodel is superior stuff. It makes code much more readable and shorter, even compared to React (see the comparison on the site). IMO, MDG should have a better look at Viewmodel and make the Blaze API more like it.

12 Likes

Exactly what I concluded after reading Schmidt’s post

1 Like

That’s cool. Now people can stop complaining. From the point of view of an enterprise…we’re still going to move to React. We can recruit better, onboard faster. And we don’t look for “meteor” developers, just good JavaScript developers. You’ll find more often than not someone who knows blaze only knows meteor and not a broad understanding of the js ecosystem. So that’s what I caution people using blaze still…be cognizant of the greater js community.

8 Likes

thats why you should just do you and not listen to all this NOISE in the forums. get your mvp done.

9 Likes

I didn’t get the memo. I thought MDG was abandoning Blaze in favour of React and Blaze 2 (a Blaze-like syntax built on top of React).

I agree that there’s a lot that can be done RIGHT AWAY with Blaze that still cannot be done with React just yet. God, can we have a solid decision either way?

This is a terrible time to be starting new projects :frowning:

3 Likes