[nathanhammond]

In general:

    how much code the browser needs to parse and execute on every page load

The caveat being that that code only needs to be parsed and executed once in a single page application.

    weight of execution payloads across operations in your app

Presumably this cost is providing value to the developer in terms of reduced development time, reduced complexity, or improved correctness. You shouldn't typically incur significant wasted cost in execution, just a selection of tradeoff. Besides, rendering to DOM is still the longest tentpole by far compared to microseconds for JS execution.

EDIT: With regards to the "independent test," that is in no way a realistic use case. You would never add items to the DOM individually when you're in that tight of a loop. You would instead build up a cache and write once. The only thing of consequence that is being measured in that benchmark is each framework's DOM insertion speed.

[lhorie]

>> The caveat being that that code only needs to be parsed and executed once in a single page application.

Sure, if you don't consider users that open lots of tabs, or users that close their browsers periodically (e.g. mobile).

>> Presumably this cost is providing value to the developer in terms of reduced development time, reduced complexity, or improved correctness. You shouldn't typically incur significant wasted cost in execution

Ideally that would be the case, but from my Angular experience, it's unfortunately not always so clear cut (e.g. filter caching is a good example of time wasted in refactoring for performance reasons)

>> You would never add items to the DOM individually

I was under the impression that this is more or less what everyone was criticizing about Backbone rendering a few months ago when that Om article came out.