BlazeLayout's sole purpose is to support rendering for routers like
FlowRouter. It’s not really a framework that makes componentization easier in Blaze.
Regarding the other packages,
BlazeComponents: I read lots of good comments about them, so they seem to be very good, and I also know that Manuel and Mitar are known for supporting things well.
However, I decided for myself to stop using any community packages that would cause a major refactoring if I had to remove them, which is quite obviously the case if they are defining the way you set-up your UI.
I’ve seen too many community packages all of the sudden causing problems in my app, because they had been abandoned by their original maintainers and were not compatible any more with more recent Meteor versions. This is not to blame the package authors, they sometimes had to find “creative” ways to workaround Meteor limitations when they built them in the first place. But as a package user, you never know if one of these creative workarounds would cause app breaks in the future. And they are very hard to track down sometimes.
When I first read in a
skinnygeek comment that he followed this best practice, I thought it might be too harsh. But I learned over time that he was absolutely right.