New uhtml library benchmark

[WebReflection]

µhtml is a simplification of lighterhtml so that it weights ~2.8K instead of ~5.5K.

Current PR adds both keyed and non-keyed results to the mix.

Thank you in advance for considering this new "micro" entry 👋

[WebReflection]

as nothing happened so far, I'd like to put this PR on hold, as I'm bringing keyed results in too, through my latest commit, that needs some refinement, but it's 99% ready to go.

[WebReflection]

@krausest FYI the merge request has been updated with both keyed and non keyed benchmarks, this could now be merged.

[krausest]

Thanks. I‘m on holidays this week so I‘ll merge when I‘m back.

[krausest]

@WebReflection I started merging before your last commit. Results are updated.
I'll merge the last commit the next few days.

[WebReflection]

@krausest my apologies, I should've checked the label before pushing. I don't think there's much difference with latest, I was just updating udomdiff with comments and a tiny fix that was worth pushing an update for.

I'll try to resolve conflicts now, hopefully that helps too.

[WebReflection]

actually the version conflicting was 1.4.4 but the table shows 1.4.6 ... anyway, conflicts gone 👋

[WebReflection]

@krausest I've published again but my latest commits are mostly related to changes in the README, so I don't think you need to re-run anything in there.

However, I've realized why the version is 1.4.6, because I haven't pinned uhtml to the exact version, I have simply used the default npm semver, which allows patches behind the scene.

At this point I have two questions:

• should libraries land only with exact pinned version in the package.json, or it's OK to use the default npm semver rule?
• do you want me to pin to the exact latest version, or it's OK as it is now?

I guess you could also save your time by skipping a re-benchmark, as I know it takes some time 👋

[krausest]

No problem - I pinned the versions and merged the PR (and re-run the benchmark). From my experience anything but fixed versions lead to broken builds (though I wouldn't transfer this advice to real world projects).