[Tichy]

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.

[drblast]

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.

[Tichy]

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...

[mattmanser]

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.

[jacobr]

Here are some benchmarks: http://jsperf.com/dom-vs-innerhtml/18

TLDR: It depends, but DOM manipulation tends to be faster in newer browsers.