feat: Add `html` alias for `hyper`

[brettz9]

IDEs like Atom can syntax highlight html blocks (also semantically clear that may behave similarly to this.html)

[WebReflection]

Changes need to be applied to the esm folder, but I am not sure I understand this MR. You can import and alias everything you want with the name you prefer, while this.html is already set on the class.

[brettz9]

Sure, I didn't take care to do a full PR at this point, as I figured might need further discussion.

In using hyperHTML-Element, the only export is HyperHTMLElement. So, it's not just a matter of:

import {default as HyperHTMLElement, html} from 'hyperhtml-element';

...but requires an additional line like:

const html = HyperHTMLElement.hyper;

...which I think is less than ideal to specify for each component where the common use case of nested wiring is needed.

AFAICT, I can't reuse this.html in both parts here and must use HyperHTMLElement.hyper:

render () {
    return this.html`<fieldset>${
      ['label1', 'label2', 'label3'].map((info) => {
        return HyperHTMLElement.hyper`<label><input value=${info} /></label>`
      })
    }</fieldset>`;
}

Thanks! (And I note even GitHub's highlighter prefers html for coloring. :-) )

[brettz9]

(Incidentally, speaking of questions of convenience, I'd think dispatch would be another nice one to have in hyperHTML-Element.)

[WebReflection]

// this is cool though 😁
const {hyper: html} = HyperHTMLElement;

when in doubt, open an issue, not a PR/MR that makes little sense and is there only to discuss something.

Because this project is used in production, it's a bit late to change the default export into something else, or pollute the ESM module with default + other exports, as that plays badly with CommonJS counter-part and I don't want to disrupt the team that's using this module since 2.5+ years ago, so chances that I'll export anything else here are very low, but I don't think attaching an alias for hyper as html would be a big deal, so I'd be OK in going forward with the idea.

That being said, everything I use/maintain/improve these days is around uhtml and I strongly suggest you to move around that library too as it's more modern, faster, smaller, and so on, while hyperHTML is mostly in maintenance mode only these days, including this helper.