3 ms·
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
by Tichy 14y ago
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.
- jacobr 14y agoHere are some benchmarks: http://jsperf.com/dom-vs-innerhtml/18 http://jsperf.com/dom-vs-innerhtml/18 TLDR: It depends, but DOM manipulation tends to be faster in newer browsers.
- drblast 14y agoEither 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 14y agoIt 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 14y agoDo 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.