Why do you like Handlebars (and concerns about live-binding)

handlebars.md

I'm considering adding an alternative to CanJS's EJS live-binding system. I really like EJS, it's extremely powerful, but ugly to look at. So, I'm trying to create a better mouse-trap.

Currently, the most popular mouse-trap seems to be Handlebars. What do you like about it?

• Syntax, or
• Prepared data

Syntax

Handlebars uses {{}} for insertion and {{#}} and {{/}} for widgets and control structures.

Prepared data

All data must be passed to handlebars (except accessed through a helper). You can not seemingly call helper methods that read data like {{person.age()}}. This limits logic that can be performed in the template (although a helper can still do pretty much anything).

Concerns about live-binding and handlebars

I'd like to learn what people like about handlebars and use that in the design of the alternative templating language. But, there's two issues I would have to overcome:

Prepared Data

Prepared data is something that has been strongly promoted on the server and it also is being promoted on the client. I don't consider it as much an imperative on the client. I've never seen anyone fire an ajax call in a template. The data is always prepared, it's just accessed through the model or other helpers.

Needing prepared data makes doing something like http://jsfiddle.net/qYdwR/36/light/ with Handlebars more difficult to write. You'd have to create a computed property that is the date merged with this updating time observable.

With EJS, you can just write a function and anything that uses it becomes live.

Limited "helpers" (this is no longer a concern ... Handlebars must support this)

I don't think it's possible in Handlebars, but EJS supports ERB-style sub template helpers (if you wanted to build them) like:

<%== columns(items, 4, function(item){ %>
  <li><%= item.attr('name') %></li>
<% }) %>

Notice that the function(item){ ... } is actually a template that is called out to by the columns helper implemented like:

columns = function(items, num, template){
    var cols = new Array(num);
    items.forEach(function(item, i){
      if( ! cols[i%num] ) { 
        cols[i%num] = "";
      }
      cols[i%num] += template(item)
    });
    return "<ul>"+cols.join("</ul><ul>")+"</ul>";
}

And this would also instantly become live.

No defaults in Handlebars without a helper AFAIK. Again, we're used to that. We create observables upfront that do what we need.

But isn't this what ember.js is doing? It allows binding without {{#prop }} and it's by Yehuda and I would argue still handlebars ....

Assuming that syntax though, how would you update the dom for a template like this?

In a similar way as it works in EJS, which does not replace the whole element. It sees the new content, parses it and sets or removes the attribute.

My issue with that syntax is that I don't know how you're going to interpret my inline attributes.

The same way EJS does it ...

Here's the code for selected/ checked:

https://github.com/jupiterjs/canjs/blob/master/view/ejs/ejs.js#L377

It gets the new value, splits it by = and remove or sets the attribute name.

Essentially, EJS already has the code that creates observables, and can:

• update an attribute's value - https://github.com/jupiterjs/canjs/blob/master/view/ejs/ejs.js#L399 - even like class="{{foo}} {{bar}}"
• add or remove an entire attribute - https://github.com/jupiterjs/canjs/blob/master/view/ejs/ejs.js#L377
• update text - https://github.com/jupiterjs/canjs/blob/master/view/ejs/ejs.js#L310
• update html - https://github.com/jupiterjs/canjs/blob/master/view/ejs/ejs.js#L329

In a similar way as it works in EJS, which does not replace the whole element. It sees the new content, parses it and sets or removes the attribute.

Awesome. I need to take a closer look at EJS.

But isn't this what ember.js is doing? It allows binding without {{#prop }} and it's by Yehuda and I would argue still handlebars ....

It's antithetical to reasons I use Handlebars I would say then. I don't know exactly how Ember.js does it, but Handlebars is supposed to be simple and explicit. I think changing the syntax to do live binding is more confusing than it is helpful.

On why you should work with us to open source this ....

1. We will make it live-update just the part of the dom that needs changing
2. We will make it work in many more situations
3. We will provide a standard computed layer as part of CanJS
4. We will make it work pretty like Ember (even if you might think this is a negative, I'm sure that it would help make it more popular option which benefits the last point)
5. We'd help harden it. In the 2.5 months CanJS has been out, we've had over 55 reported issues https://github.com/jupiterjs/canjs/issues many of them on live-binding which we've turned around and fixed. You'll basically get bug fixes for free.

As I saw you responded to #4 while I was typing this ....

You're saying changing {{}} to also setup live-binding makes things more complex ...

Ok, so lets make this optional (but I'd say turned on by default to better compete with ember). Something like:

Handlebars.bindByDefault = false

And it doesn't overwrite reading properties to check for observes.

on explicit .... you mentioned it will call a function if it finds it ... I'm not sure how that's explicit. I think this is the same thing. If it finds a function, it calls it. If it finds a property on an observe, it binds to it, if it finds a simple property, it writes it. It's just one more case, similar to when it finds functions.

Parity with Ember is compelling I admit. I dislike changing the default behavior, but if there is a way to turn it off I can't complain.

You don't have to make a case to me for open sourcing code, I just have to run it up the chain. That said, my implementation is basically a $.View.hookup hack (and on 3.1 no less), but I hope we'll open source it and I'd love to help out on getting an implementation leveraging this cool EJS DOM-diff code. What handles list binding?

you mentioned it will call a function if it finds it

The function call behavior is admittedly a little weird (and undocumented AFAIK) but it makes sense. You're not going to want the toString() of a function in your templates.

The function stuff certainly makes sense ... you see a different type and get a value from it slightly differently. I don't think seeing an observe and getting a value differently (and of course hooking up live-binding) violates the ideas behind handlebars (especially as this is almost certainly what Yehuda is doing).

But, if you are ok with functions being treated differently, I've just added a compute method for CanJS:

canjs/canjs@8eb7847

What handles list binding?

I think maybe how EJS does it's magic isn't clear (because it's so powerful it might seem like magic). There's really nothing special that "handles" list binding. It's just the part of code that updates an HTML chunk listed above at: https://github.com/jupiterjs/canjs/blob/master/view/ejs/ejs.js#L329

The secret is that can.Observe.List changes it's length property when items are removed or added and can.Observe.List.prototype.each calls this.attr('length'). So a block like:

<% list.each(function(){ %>
  CONTENT
<% }) %>

is just html getting updated that is live-bound to the list's length.

more about can.compute here:

https://forum.javascriptmvc.com/topic/can-compute-crazies

Right, that makes sense, you would just use a DOM diff for everything. can.compute will be very helpful.

The flag to turn it off though is going to be essential, and those of us who need to upgrade will need it per view() call. Right now we have a lot of manual update code that could interfere with live binding. That's why it would be better for us to have a helper instead.

As promised, here is our plugin: https://github.com/Spredfast/jmvc-bind-handlebars

It's a different approach, but it gets us close without too much code.

Justin and Noah, I am very sorry, but I had to make the repo private until we attach a license to the code. I will try to make sure this happens quickly so I can make it public again.

It's public again. Sorry for the disruption.