Note: Manual caching of (v)dom nodes

[krausest]

This implementation contains client side code to achieve better performance by using manual caching of (virtual) dom nodes.

[krausest]

@ged-odoo I'm considering applying that note to blockdom. We got into that discussion in #1247 (https://github.com/krausest/js-framework-benchmark/pull/1247/files). Would you agree regarding this flag and blockdom?

[ged-odoo]

Yes, it makes sense.

Blockdom is meant to be a low level layer anyway (and a proof of concept). Noone will probably use it directly. We built the Owl framework on top of it, and I think that the vdom node caching has to be done at the framework layer. It was done this way in the blockdom to showcase that it is supported. Maybe there should be a separate project to benchmark vdoms :)

[ged-odoo]

I however want to add that I still think that it is ethically acceptable that my blockdom implementation is done the way it is, because blockdom is not really a framework, just a rendering engine.

[fabiospampinato]

Would this, the template call, count as manual? Personally I kinda see 3 tiers here:

1. Solid-like, it just works, that's the best.
2. Voby-like, you need to do something special, but just a little potentially.
3. You need to do a lot special.

It probably makes the most sense to count 2. and 3. as manual for the purposes of this flag, imo 🤔

[krausest]

@ged-odoo Absolutely. Those notes often lead to heated discussions and not all frameworks are equal (which is a good thing). Still the low level frameworks create some pressure for higher level frameworks to add optimizations that enable the same kind of performance but lead to uglier code and this is where those notes indeed help keeping implementations idiomatic. So it can be that such a note denotes a code smell for some and a design principle for some other implementation.

[krausest]

@fabiospampinato IMO https://github.com/krausest/js-framework-benchmark/pull/1247/files introduces a significant code smell for little return. This was the primary reason for creating this note. The template method looks pretty innocent to me but maybe I just don't get the full picture.

[fabiospampinato]

@krausest the template function is relatively innocent, but I think Solid's approach is still way nicer, because it's applied automatically and it doesn't require refactoring your code in any way (unless you want to squeeze more performance out of the optimization), the template function can be used trivially only in trivial scenarios, in other scenarios, like when the component doesn't just return some markup but also contains state, the component needs to be refactored for it to work, so it's not nearly as nice as Solid's approach IMO.