htm/mini tradeoff

Maybe I am missing the point of htm/mini, but I can’t justify the tradeoff here. It saves 150 bytes, but adds 10 conditionals, which kind of make the code little more verbose.

Do we have a future plan to expand the main version to consider keeping mini version? I am guessing we might see more adoption of mini version if we add more features to main version.

[heyheyhello]

@Grafikart I’d recommend explicitly cloning the nodes rather than disabling cache:

const btn = html`
  <button class="btn-gradient"><span>Hello</span></button>`

const items = [1, 2, 3]
return html`
  <div>
    ${items.map(b => btn.cloneNode(true))}
  </div>`

While we all appreciate htm as a parser, it’s actually very expensive. The caching step can save lots of work. Try putting yourself in htm’s place and imagine parsing your <button... call through the 292 lines of code (build.mjs) to generate your DOM node, each time. That’s a lot of wasted work, and it would be a lot more efficient to leverage the browser to clone nodes for you - promise it’ll be faster than having htm do all the work again and again.

https://codesandbox.io/s/happy-pare-hgqkc?file=/src/index.js

[Grafikart]

I’m currently using mini cause the “normal” version seems to have a cache that creates problem if your h() function render a DomElement. Indeed htm will reuse the last return and the same dom reference will be used.

const items = [1, 2, 3]
    return html`<div>
    ${items.map(b => html`<button class="btn-gradient"><span>Hello</span></button>`)}
    </div>`

Since nothing change for the button, the method h() would be called once 😦 If mini disappear maybe we should have a way to completely disable cache (maybe in the bind function)