Thank you MDG for developing Meteor and Blaze!

It was almost ten years ago I made my last coding activity. I was a Sw. Developer and I was coding in Java. Since then, I took several other roles including Product Management, Presales Engineer and Solution Architect. I met with Meteor last year. After spending a couple of weeks by discovering and learning its basic, now, I’m in love with Meteor! Meteor provides more with less. Aside from some other great features like being a full-stack framework, reactive, etc. I like its front-end fwk Blaze a lot, too. It is so intuitive, very easy to learn and makes front-end work a real fun!
I have seen discussions about replacing Blaze with React or Angular. I hope MDG will not deviate from their current direction and goals just because an expectation from the larger communities of Angular or React. They might be superior than Blaze in some ways. but definitely, Blaze is much better in grasping attention of people who haven’t coded in front-end and in delivering much more with less coding. Blaze is simple and intuitive. (I coded in Java for many years, but I am not experienced with JavaScript.) Look at the way they are coding in React and Angular at I am sorry but I have to say, especially, React code seems ugly.
Of course, there are many other factors to be considered while evaluating a software technology (like performance, scalability, reliability, community support, etc.) but nobody should dismiss the value of simplistic solutions, either. As my Ukrainian Professor of my Ph.D study says, “God likes simplicity!”


It’s a bit unfair to use such an old article.
Pure functions, createContainer and a clever use of ES6 syntax would make the React snippets much easier to read.

Moreover Blaze is really simple if you’re building barebone SPAs, start adding things and you will probably start fighting against the limits of the technology (maybe it’s better now that development has resumed, I’ve never went back to it).
You shouldn’t care about a couple of minutes gained in implementing a couple of pages/components, what you should care is that 2 months from now you can add new features (possibly complex) with ease.
I found that for me a good structured React project help to be productive in the long term (coming from ASP.NET I also found its lifecycle very intuitive and well implemented), which is what I really care about.

Moreover it’s not like Blaze can’t get ugly (and I mean really ugly), for example I always found the account-ui templates to be incredible ugly to work with.


Hi Matteo,
Thank you very much for your comment.
Blaze is a nice component aligned with Meteor’s vision of reduced TTM. And, I’ll spend a couple of days exploring both Angular and React, too.

1 Like

Don’t even remind me. I tried to rewrite this library 1:1 to Vue and that was a nightmare to even tell what’s going on in which template.

@gkaradag Hi Gokhan

You’ve probably not heard of the “Mantra” initiative.

React permits a wide range of different ways of working, and can quickly lose a naive developer in a hazardous jungle. The Mantra Specification for Meteor apps, lays out a framework for combining a number of widely recognized best-practice techniques into a coherent methodology. In particular, “Higher Order Components” (HoC), “Separation of Concerns” (SoC) and something a bit like the Java pattern “Injection of Dependencies” or perhaps more commonly “Inversion of Control” (IoC).

Basically, it splits React code into three separate parts: your basic dumb “Components” and “Composers” that emit “Containers” by injecting smarts into Components. It also separates out actions into their own group of concerns. You’ll find a very, very good introductory article about Mantra from The Meteor Chef: “Working With the Mantra Architecture”.

I’ve been maintaining my own fork of the Meteor Mantra Kickstarter, and added onto it a whole bunch additional capabilities that I describe in the README.

I agree with others here, that it would be a shame for you to write off React on the basis of an old, and rather biased article.

That’s a good attitude. I myself started with Blaze and I enjoyed it very much however I started learning react and I found that thinking in components is a lot easier as the code grow in complexity. With that said, the beautiful thing about Meteor is that you can pick and choose the view layer best suited for your needs.

1 Like

Also, React makes file management easier. Instead of needing two separate files for everything, React puts the view and logic into one. That was, by far, my biggest gain with React. There are plenty of technical improvements and efficiencies that React has, and I love them, and still my favorite thing is just that I can focus on one file at a time. No more separated views and logic.

From (and elsewhere no doubt): “Meteor Blaze is a powerful library for creating live-updating user interfaces. Blaze fulfills the same purpose as Angular, Backbone, Ember, React, Polymer, or Knockout, but is much easier to use. We built it because we thought that other libraries made user interface programming unnecessarily difficult and confusing.”

To my knowledge at least, MDG has not backed away from that stance entirely but rather made it easier to use the larger ecosystem. Instead of asking “which technology is better?”, we should be asking “which technology is better suited to a particular problem space?”. One-size-fits-all solutions do not exist.

For Meteor+DDP+Blaze, it is difficult to imagine an easier, better way when:

  • The primary data source is local to the app (not an external service/s)
  • MongoDB is sufficient
  • Eventual consistency is good enough

Granted, that is a very narrow scope, which is a problem and the impetus for GraphQL/Apollo, but under those conditions Meteor+DDP+Blaze offers a near-perfect solution.

Nevertheless, for many reasons, its’ potential can be difficult to realize. To those ends, in case it is of any use to anyone, I’ve developed a reference architecture ( which demonstrates some ways of getting around the roadblocks.

1 Like