Don't know the current state, but for a while it was a lot faster to just replace the HTML source (innerHTML I think?) than to manipulate the DOM. Just the way the browsers were implemented. No idea if the situation has improved by now.
Either way, it looks to me like this approach has to manipulate HTML strings to find a {{tag}} like that. Which seems like it's a lot more work than this:
<div id='thingToReplaceWithData1234"></div>
and then adding a child text node or such to that element. Whether you do that via InnerHTML or CreateTextNode doesn't matter, either seems faster and easier to me than doing a string substitution.
But I don't know, I never really got the appeal of the framework of the week. If it helps write decent web sites, then I guess that's good, but I've noticed that simple sites now are ridiculously slow and I'm guessing this is the reason.
It seems faster, but unfortunately it isn't (or wasn't). That's just the thing. When I started, I also thought using DOM was a no-brainer, but there are all those tiny speed optimizations people make...
Do you build websites using echo, Response.Write or whatever your language of choice is?
The reason people use templating languages client-side are exactly the same as they use them server-side, it's much easier to maintain a larger app.
Most template languages are extremely lightweight and blazingly fast, slow websites are 99% of the time due to sending too much content or slow server-side processing.
My team uses Handlebars templates with Ember.js. We build templates with placeholders for bound values or other view templates. When rendered on the client side, a change to a data model causes an automatic change in any templates that are bound to that data. In jQuery there's a potential for forgetting to write code to update a value or part of the page. With this templating system, it's all bound and auto-updated.
Another reason that we use templates is that we put all the template files up on a CDN. The only thing our server serves up is an empty DOM (just a body and a div), and the templates are all built into the DOM on the client side.
Lastly, managing a bunch of small tmpl files with the HTML we want is a lot easier than trying to embed HTML into JavaScript strings to use with jQuery. We just write up some HTML and an Ember view that renders that template in the right place on the page. Organizationally it's very simple and easy to maintain.
Direct DOM manipulation does not mean that you render things server side and then manipulate them. It also does not mean that you embed HTML in JavaScript strings. The difference is whether you use the DOM APIs (with or without jQuery) to create and update elements, or template libraries and innerHTML.
You could also ask the same question about server-side templating: Why do we string-interpolate rather than manipulate the DOM? DOM manipulation is more robust and far, far more secure (you can auto-escape variables as you know their actual context).
I can think of a couple of ways to do that but it hasn't taken off largely yet:
This is impractical with any JS-heavy application; where you are working primarily with javascript data structures and not the DOM.
It also leads to jQuery spaghetti code. So many people use jquery like a shotgun, to solve every JS problem, when better - and more targeted - solutions can be tailored out of small modular libraries.
You only get jQuery spaghetti if jQuery is your method of choice for manipulating the DOM. Most of my work is extremely JS-heavy applications, and I've never found it necessary to use string-interpolating templates. I have found it very useful to use a hand-rolled "template" system based on DOM structures, with data-attributes indicating where the templating engine should insert stuff. Might turn it into a real library someday, but it's really simple, so I don't see a whole lot of point to doing so yet.
It's true that manipulating the DOM is easy. The template thing makes more sense and becomes somewhat of a necessity when you write apps with data binding. As with about any framework, you can definitely do the same thing by just hand-rolling everything. But you wind up writing a pretty significant amount of custom code for every page. Using a framework you trade off highly efficient (but one-off) code for something that is more re-usable.
Can you explain how templates make data binding easier? Working with the DOM means that you immediately can save a reference to an element, rather than generating the HTML and then traversing that HTML to get the element you want to change.
It's kinda a different technique altogether. Instead of writing code to respond to changes and then update specific DOM elements, you just create a template that has usually some kind of template variables/placeholders that the template engine will populate with data.
Then you "bind" that to some kind of object. Whenever the object changes, the framework then re-renders the template. So the effect is that when your model changes all of your UI components on the page just magically refreshes themselves.
Probably not the best explanation, but hopefully makes sense!
There exist purely DOM-based template engines, such as Batman's one: http://batmanjs.com (The approach has its advantages but unfortunately speed is not one of them.)