I'm not sure. But FWIW I don't think more complex nesting would change anything in this regard. Those transforms essentially just avoid you having to wrap some

I'm not sure. But FWIW I don't think more complex nesting would change anything in this regard. Those transforms essentially just avoid you having to wrap some things in functions manually, and avoid some extra function calls. Avoiding manual wrapping is a convenience feature and those extra function calls are not really that expensive (or it wouldn't be possible for Voby to be faster than something optimized like Solid in the benchmark). If you'd like to come up with a different sort of benchmark where you think Solid would shine I'd be happy to write an implementation of it with Voby and see what happens. Or you can just try that yourself, the API is fairly similar. --- I should probably add that js-framework-benchmark is heavily biased toward measuring creation time actually, which is something where compile-time optimizations should shine. If you are more interested in updating things, like you would be in a rich application, Voby is actually some 20% faster than Solid at replacing rows with other rows, because it support reusing of older nodes (opt-in) (this also lowers memory pressure in some cases by the way, no need to make and gc lots of stuff in some cases). This optimization is not supported in Solid nor Svelte, and interestingly it's not a safe optimization that can be applied all the time, so it must be opt-in, but how are you supposed to tell to Solid or Svelte when it's safe to apply it if something like Voby's "template" function, which is also used for this, is abstracted away entirely from you? In some sense the transform actively goes against performance here.