Try it, you're refusal to "get past the need to mix markup and code" is restricting you from some pretty helpful functionality if you build JS heavy web apps!

People who write business code and logic often have little to no concern about tables vs divs, CSS quirks, and markup structure in general. Conversely, our UX people have no concerns whether we use MongoDB or SQL Server to serve records. They shouldn't have to. Our concerns are separated by using proper design and architecture, and we can work on things together while focusing on implementing our particular skillsets.

The script/markup mixture of DD and Backbone is not necessary at all, and it's a quirk because these frameworks (and others) make it one!

Probably because of this: http://jsperf.com/string-concatenation-vs-the-dom

Yes, it's faster to create DOM elements in string form rather than one-by-one, attribute-by-attribute.

However, creating DOM structure in code sucks. It's far better (and faster) to create markup and deal with templates by compiling HTML files into strings in JavaScript files and then turn those strings into DOM structure when needed.

Once you create DOM fragments from singular, compiled strings, you can perform data binding.

So, instead of this (from your benchmark):

  var $dropdown = $('<select class="s">');

  $u.find('a').each(function() {
    var $a = $(this);

    $('<option>').html($a.text()).attr('value', $a.attr('href')).appendTo($dropdown);
  });

  <select class="s" data-binding="{@source: aElements}">
    <option data-binding="{@template-for: aElements}{value: href}{@text: aText}">
  </select>

Writing markup to represent the presentation of data, and code to represent the logic of business is far superior to writing code that does both!