When will MDG finally drop Blaze?

For at least 12 months the Meteor community (here and here)  have been abuzz with notion that MDG (the company behind our beloved Meteor platform) are planning to drop Blaze in favour of React (and Angular before that) and you can’t blame the community for being at least a little confused as the message coming out of MDG has been slightly inconsistent (even if that wasn’t the intent) and less transparent than you would expect from an open source project.

The upshot of this is that the Meteor forums are full of contradictory advice and augments for and against Blaze, Angular and React (although the debate seems to be mostly centred around Blaze and React – Sorry Angular) which IMHO is creating a real problem for two types of Meteor developers:

 

  1. Developers who are new to Meteor – If you are a new developer who has been hooked and amazed by the numerous examples of Meteor productivity, reactivity, simplicity (or any other -ity you can think of) just like we all did, you will quickly find yourself lost in the forest of view layer guidance that currently exists and faced with this paradox of choice you will most likely star the git repo (GitHub’s bookmarking system) and run back to the comfort of the more opinionated framework your used too (Rails, ASP.NET MVC, PLAY, DJango, etc…)
  2. Developers who are starting a new project in Meteor – Starting a new project in Meteor right now is a minefield of uncertainty, lets leave aside the impact of Meteor 1.3 es2015 module support for now (that’s another article) as that is still in Beta. Choosing the layout system to use for you new project is hard, you’re going to be tempted to jump on to the React movement but your also going to be tempted be the initial productivity benefits of Blaze (I will talk about this later). Hopefully this uncertainty wont make you use something else entirely? but I have certainly been guilty of using Node/Express/Jade instead of Meteor because i wasn’t quite sure where to place my bet with Meteor rendering technology.

 

The Reality (as I see it)

Having just spend time explaining how too much contradictory guidance exists in this space, I’m about to add my two cents just to make it ever so slightly worse 😉

I have spent a long time thinking about this “problem” and after reading pretty much all the MDG responses and publications over the last year, I have come to a conclusion about the state of Blaze & React in relation to Meteor and now have a framework upon which I can use to decide which view layout technology to use for a particular development.

 

Blaze is here to stay

Given the direction of Meteor (1.3 and beyond) is almost impossible to imagine Blaze not being at least a first class citizen in the view layout space, MDG might make React the technology of choice in the future (I personally think they will) but the drive to a more modular Meteor code base guarantees that Blaze can live on and prosper regardless of the MDG preferred option.

 

Whats so great about Blaze anyway?

Blaze is perfect when your starting out with Meteor because it has almost no learning curve, sure you have to understand how helper methods and events work, you have to grasp the life-cycle but onCreated and onRendered are pretty much what you would imagine they are, right?

When I’m “showing off” Meteor to a client or colleague I always use Blaze, Always! Blaze allows you to build a working prototype or an MVP in record time enabling you to take your product to market faster and reduce the risk of failure (or at least Fail Fast).

You can find a package on Atmosphere that will solve any user experience problem you can imagine, whats more most of the time all you need to do is add the package and your good to go, I have  built some pretty impressive apps in Meteor without really writing much code (this has to be the future!).

Blaze is familiar and comfortable, remember it’s essentially just handlebars which is just html with some special tags {{}}. It looks like HTML (because it is) which means you have access to a world of ready-made examples (the web) illustrating how to solve any kind of UX problem all available to you via the famous “Copy and Paste” method.

 

So Blaze is perfect, end of story!

Well no, and this is where the “problem” (as i described earlier) comes from… Blaze for all its awesomeness does have its faults, anyone who has built a large multi page application in Meteor will tell you, Blaze layouts and their sister JS files get harder and harder to maintain over time, structuring your layouts and components in a way that makes best use of expensive resources like subscriptions (and reactivity) isn’t straightforward.

Blaze is so un opinionated and flexible its almost impossible to spend more than a week with it before you start creating a monster in your code base, now this isn’t a problem when you’re prototyping, but if you have any desire to maintain a production application your going to find yourself endlessly refactoring.

Blaze doesn’t lend itself to SSR (Server Side Rendering) because it needs a browser to render, using a headless browser on the server to render the page is possible but is going to add a pretty huge overhead to your initial requests, throw in a spike in traffic (Yay new customers!) and your going to see CPU loads that will make the most hardened sys admins teach itch not to mention the SEO (Search Engine Optimisation) issues this presents.

 

Stop rambling! Should I use Blaze or not?

Short Answer: Sometimes

Wow, all that for more uncertainty!

The conclusion I have reached is this… Blaze is still the first choice for new applications, especially prototypes and applications that are going to be relatively small (discreet use cases, simple to-do list or chat for example).

If your building an application with lots of pages and components and if your app survives past the initial prototyping phase your going to reach a point where you hit the Blaze issues I descried earlier, this is where I recommend migrating to React (Sasha Greif has a really good series on this over at Discover Meteor).

If your development team is more than two developers, using React is going to make your life easier and you will all get on with each other a lot better, trust me!

 

  • Honestly, I hope they’ll never drop Blaze. I think one of the best features of Meteor is that it offers developers a choice between using Blaze, React, and Angular on the view layer. In fact, it’s even possible to mix Blaze with React (don’t know about Angular, but may be possible as well).
    This puts Meteor in a unique position with regards to developer scalability – you can go from a single person prototype (built with Blaze for faster prototyping) to a full-blown React frontend incrementally, without having to rewrite the entire thing from scratch. And once the entire frontend has been converted to React, you could even replace Meteor itself with a traditional REST API and/or web sockets if it turns out that Meteor doesn’t scale well. And all of this can be done incrementally. Therefore, I see Blaze as a strength, not as a weakness.