Dojo’s create() method doesn’t support the full stan-like syntax for nested creation. It’s (currently) more suitable for creating individual nodes. I had argued for a hierarchical version, but it was deemed to big (and potentially too slow) for Dojo Core. We may add something like that back if we can come to a resolution on that.

Regards

The Sly chart is junk because it uses “stacked bars”. Stacking values without, at a minimum, providing a table to explain the values does more to obscure the data than to present it evenly. Also, having re-run Sly through a better set of benchmarks, I’ve found that their “additive error values without variance” chart wildly mis-represents the actual performance impact of their engine. It’s not faster, it just looks that way because they used a bad benchmark and type of chart that works to obfuscate, not clarify, data.

FWIW, I don’t hold it against the Sly folks…benchmarking is hard. It requires experience and some background in interpreting numbers. Many engineers don’t have that background.

Also, FWIW, I argued against the “Libraries” section at the bottom, but it’s not a huge loss to have them. They simply add detail about relative browser performance at the toolkit level. The more important thing about the TaskSpeed charts is that they show by-toolkit numbers on a normalized scale, grouped by browser. Without that view (which Sly didn’t provide), the numbers are more-or-less noise.

Regards

It seems like from a high level perspective, the Sly chart gave a good approximation of the summation across all browsers, it wasn’t intended as a chart to describe the relative performance difference between specific browsers. Seems like if you want to show one chart only, that one isn’t too bad.

I would argue that some of the charts shown in the TaskSpeed reports aren’t very useful, for instance the entire “Libraries” section at the bottom.

That being said, this is great stuff! I definitely agree that more benchmarking needs to be done, not just the CSS selectors.

Nice work!