Meteor Guide Regarding Blaze

Like Brajt said, it would be optimal to have one, but giving people two options up front is better than leaving them to experience the pain, search for answers, and then have to make a decision later on.

We could enumerate the most common problems areas when using view layers, and then @mitar and I can submit PR’s where we explain how each package deals with each situation.

How about the following to start with:

  • Creating components
  • Reusing components
  • Communication between components
  • Event handling
  • State handling

Again, these could be in a section called “Packages that compliment Blaze” (or something to that tone).


@tmeasday’s out for the weekend, I’d like to get his perspective about this as well.

1 Like

Completely agree, those are some of the things I enjoyed the most when going from Blaze to React.

1 Like

I do think it would be a true disservice, if you don’t tell developers upfront there are simpler alternatives to do more complex stuff with available packages. Actually the guide already recommends packages for other layers like simple-schema for data. Then why not the view layer?

Learning / comparing by example is always the best way to learn. When new developers jump to Meteor by learning the TODO example, they are naturally exposed to those exciting new features (reactivity without effort etc…) that distract them to ignore or assume real world apps will be equally easy, until their app requirement become complex enough to hit walls. That’s exactly the start of my journey reaching VM. We all want to focus on business logic, which is mainly view layer centric, instead of lower level stuff, that’s why Meteor hits, isn’t it? Then why not make new comers’ lives even more easier, without going through all the painful routes? or worst, leaving Blaze or Meteor…

It would be great if the guide could provide sample apps with more real world requirements, in different versions using pure Blaze, VM or others packages. The idea is like: , but in full app. Just let developers decide which approach they prefer. For VM I work most with, @manuel already has great demo apps like the contact management, though I wish the app could make use of other packages like Astronomy for validation and easy-search for search etc…

Personally, I think React is over-rated in Meteor (probably mostly the forum community) because most haven’t really tried or even aware of the existence of VM …


Yeah, when you start to need more Sessions, Reactive-X etc… either you end up in VM or leave Blaze, even Meteor. It’s all for the sake of Meteor developers (thus MDG) if the official guide could eliminate the unnecessary painful journey of solution searching.

I’d be happy to sharing my toy projects, but probably most new developers prefers to see raw JS/HTML other than jade and livescript that I personally prefer. Maybe @sashko could consider inviting and listing different versions of the predefined demo apps alone side the official one. Then I’d be very happy to help make VM version in jade/livescript to show case the simplicity etc…

1 Like

I have some perspective on this as someone who started into Meteor seriously mid-December. The Guide has been completely invaluable, it’s been my bible and it’s especially important at the moment as examples from even a few months ago would now be considered out of date.

For us as experienced developers looking to take on a new platform, a “blessed” approach is really important to us (Microsoft do that really well, it’s usually pretty clear that the recommended starting path is).

The other thing that’s worth a thousand words is a great demo. From a corporate/enterprise of view the Todo app is a great starting point, but a demo with a dashboard and a few dull screens showing how to edit records and do the dull business of parent and child relationships (invoices and invoice lines etc) and lookups would be invaluable. Rather than just bemoan the lack of that though, I’m actually working on writing one in 1.3 React, I’ll send @sashko a link to the repo when it’s working and you can have a look and see if there’s anything worth using.

One other thought (because I know MDG are sitting round twiddling their thumbs for a lack of things to do at the moment); a boilerplate project that includes all of the guide recommended packages would be really good too. It would be great to be able to type meteor create --guide-boilerplate --blaze my-project-name or something like that and be up and running on the happy path.

Yeah, often I feel that people leave to React to get some features at the cost of more code than Blaze while manuel:viewmodel gives them many of the same with less code than pure Blaze.


This would be impossible to maintain for us. We can at most maintain 1 or 2 example apps, unless there is someone literally working full time on example apps (which won’t be the top priority even if we would hire such a person).

This is one place I would really encourage some work from the community - if you make an example app that uses view model but follows all of the recommendations from the guide (not necessarily in code, but at least in spirit) I’d be happy to figure out a way to promote it.

Spot on! This is the reason we haven’t published a forms article in the Guide yet - we don’t have a testing ground for the kind of app that needs really complicated form functionality. It would be great to have a new example app for this.

Yeah this is certainly something we want to do once the guide is more complete for Meteor 1.3, if you want to help with that it would be awesome. First we need to get the testing and app structure/modules articles into the guide for 1.3.

Sure that’s understandable. Recently I did quite some private Meteor mentoring for which I always ask the guys to use VM. Shall let you know when I come up with the VM version of the Todo example. :smile:

Make sure you use the Todos app from the Guide, not the one that comes with the tool right now - we haven’t updated it yet.

1 Like

Would MDG maintain the simple-todos (or a new version at the same scale) in the current tutorial of It is the right bite-size for new comers. The Todos app in the Guide introduces too many concepts, seems not a right app candidate to start with for comparing view layers.

I’d say you can’t really see the full advantage of using Blaze Components or Viewmodel is the tutorial’s Todo app, it’s too small for that.

Yes, I agree. Just thinking to make it a start. The point is to have a reference based on official Blaze implementation.

I appreciate this is a frustrating situation. For context the stated reason we haven’t looked to recommend one or the other is partly due to the lack of clarity around direction with Blaze / React / React in Blaze:

I guess things are becoming clearer in that respect, so perhaps it’s time to revisit this issue; I’ve added it to our agenda this week:

It’s outside of the guide’s goals to provide more than one recommendation; however I think in this case, like the end-to-end testing case, there are a few competing options that have their merits so it could make sense to at least mention them all. But we probably would need to recommend something, unless the whole section is a “other options” section…


Did you guys ever got to this?

Since then things have progressed in other ways a bit so this kind of fell off the radar.

As you probably know we split Blaze off into it’s own repo and we’re hoping it’s development can be more parallel to that of core, and community driven. As such we’ve given @mitar commit rights to that repo and hopefully post 1.3 he and others in the community like yourself can continue Blaze in the sort of direction that you’ve taken it with BC and VM.

We want to focus on getting 1.3 out but I know that @martijnwalraven has been thinking about figuring out how to properly separate the release process of Blaze from that of core and he’ll probably focus on that right after 1.3 is released. Our aim would be that Blaze could be on its own release schedule and not held up by core changes.

Part of that effort will eventually be for the same Blaze maintainers to take over the guide article as well. Again, I’d rather focus on getting 1.3 out the door and then think about this afterwards but that’s the current direction of our thoughts on that subject.


Looks you can’t grow wrong with Blaze Components or ViewModel. The thing you can’t do is continue building an app without one of these opinions. You will spend cycles arguing what’s right rather than conforming to a common understanding. My team did this and we just chose react. So this will happen to everyone else! I like BC vs view model but I still think both APIs are too big! IMHO

1 Like

Wow that’s cool that @mitar is going to help maintain Blaze!


So, @mitar, what’s the status of Blaze?

1 Like

We are stuck on this design decision we cannot decide on: