Hey, thanks for your interest – and great questions. Keep them coming.
Generally speaking, the reason I like using Blaze instead of jQuery, is that elements (or attributes etc.) are completely ready when they are rendered. They don’t exist before, at all.
Flickering
… so flickering doesn’t become a problem.
Alternative syntax
I agree that using a string with a colon in it looks more artificial than a keyword argument.
Actually, I realize that I’ve been inconsistent in the way that bindings can have a detached option, but you can’t omit the property name from the bind expression without the library failing. I’ve corrected this for the next version.
Here’s the problem with using keyword arguments as bind expressions, though:
Every keyword argument would designate a binding, so we would lose the possibility of passing actual keyword arguments to the bindings.
This is a feature we can’t do without, since it is the only way to pass dynamic data to a binding (not just a string argument inside the bind expression). Which happens to be one of the major advantages of this package 
Classes
I don’t want to parse objects inside bind expression strings. It’s too complex. Here’s my suggestion for having a class binding:
<div {{bind 'class' classes=classes}}></div>
// viewmodel
{
red: true,
classes: function () {
return { red: this.red() };
}
}
I’ll add this binding to the set and push version 0.5.6.
