While latest API and logic is mature and battle-tested enough, there are few things that worked well but others that didn't shine in V1.

Following a list of things I'd like to improve for the next release:

• ES2015+ code. I'm happy about current hyperHTML compatibility and features detection capabilities, but the code is a little monolith written in old ES5, hence not too welcoming for contributors
• ES2015 modules. I'd like to split all internals in modules and utilities. This should give me the ability to produce a light version of hyperHTML that doesn't include method and wire adopt-ability
• there is already a 100% code covered viperHTML branch that produces layouts with hyper friendly comments in the right place. This would make hyperHTML adopt capability way easier, reaching attributes with ease but also making multiple placeholders discovery a no-brainer. Factoring out from main package adopt-ability would make hyperHTML lighter and hyperHTML.adopt accurate. Moreover, the current adopt logic is partially broken in core due unability to discover templates previously used.

This will be a big effort in terms of code refactoring, it will partially change/break current adoptability (an experimental feature not many are using so far anyway), but it will not change the API as we know it.

However, adopt will be not available by default (breaking change) and because of that I think V2 makes sense (as also previously suggested).

If you have anything in particular you'd like to see in a V2 please add a comment to this future-plan issue, thank you.

While at this stage it's definitively inferior in terms of features, there are few ideas in lit-html that could be borrowed by hyperHTML keeping viperHTML counterpart compatibility a must-have.

Everything discussed in here will result into a major update due inevitable incompatibility with the current implementation but before going that far, I'd like to investigate few things.

~~Drop Comments~~ ?

Solution: NO. Comments were not just improving performance splitting automatically the layout in chunks, comments were mandatory to solve partial tables layouts. There's no way without comments you can obtain the same. Also, dropping was a way to have attributes without quotes but current V1 candidate already support that.

lit-html is using {{}} as placeholder while hyperHTML is using <!--hyper-->. The reason for hyperHTML to chose comments is to have best performance on template creation too, not only on successive updates.

To be checked:

• [ ] how badly performance would be affected walking nodes and, per each node, their text content (splitting it in chunks to create new nodes)
• [x] is {{}} supported without quotes (attributes) on every browser?
• [x] is {{}} supported with or without quotes (attributes) on svg elements?

~~Partial Attributes~~ ?

Solution: NO. Partial attributes are YAGNI. You can already have template literals within interpolations so that either through arrays or string concatenation or even functions you can address attributes.

html`<div class=${`foo ${maybeBar ? 'bar' : ''}`}>Foo bar?</div>`;
html`<div class=${'foo' + (maybeBar ? ' bar' : '')}>Foo bar?</div>`;
html`<div class=${['foo', maybeBar ? 'bar' : ''].join(' ')}>Foo bar?</div>`;

html`<div style=${`top:${top}; left:${left};`}>x</div>`;

This has been asked more than once and I still believe it's not needed at all and it makes templates more messy instead of cleaner. However, lit-html supports partial attributes.

To be checked:

• [ ] how badly performance would be affected walking attributes and, per each node, their text content
• [ ] how costly is each new attribute composed update
• [ ] what are the use cases - are use cases so common ?

HTML opt in ? see comment

lit-html is an "always textContent" template thing. It understands it's not text only if the interpolation is a rendered lit thing, hence at distance, post parsing or after the first pass.

hyperHTML has semantics to understand the intent upfront but there are cases where it needs to have an explicit opt-in or opt-out from text.

The recently introduced hyperHTML.escape(text) covers the opt-out from html but there's no official opt in.

hyperHTML.wire could be a good candidate for that, but I'm keen to hear other ideas too.

Is there a way to apply attributes to an element based on a condition? The following does not work:

const maxlength = state.maxlength ? `maxlength="${state.maxlength}"` : '';
const fileElement = hyperHTML.wire(state)`<input type="file" ${maxlength}`>;

I prefer not to apply maxlength property if state.maxlenght is falsy. Thanks!

Hi there, I'm excited to get going with hyperHTML. I think it would be nice for the readme to show exactly how to install and import hyperHTML, I'm not seeing that anywhere and I'm having to figure it out on my own. Thanks!

If I'm understanding correctly (from the forms example), the eventing depends on stringification ... that means that it's super fragile and things like closures are, obviously, forgotten. It seems like the only way to slightly hack around this is to put functions on the Window object so:

const foo = 123;
const evt = {
  onchange(ev) {
    const onNo = "" + foo; // Aside: double quotes breaks everything
}}

Doesn't really work, because it gets transpiled to:

function onchange(ev){
  const onNo = "" + foo; // double quotes break everything
}

Because it's now just declaring a function, and not calling it.

      <select onchange="${evt.onchange}">
        ${makeOptions(someData)}
      </select>

Would become:

      <select onchange="
function onchange(ev){
    const onNo = "" + foo; // double quotes break everything, foo reference error!
}">
         <option>
      </select>

Maybe there is no way around this?

I think I have a fundamental misunderstanding of how the library actually works so I don't think this is an issue with the library however below is my code and the error I get, I am not sure why this happens.

import { wire, bind } from "hyperhtml/esm";

window.wire = wire;
window.bind = bind;


var appRoot = document.getElementById("root");
var appRenderer = bind(appRoot);
// appRenderer is a function which takes 1 parameter: template
// I should call appRenderer with a template (``) everytime I want to update the UI.


function UI() {

    var timerInstance = timer(0, notify);
    var timerInstance2 = timer(0, notify);


    function render(){
        return  wire()`${timerInstance.render()}, ${timerInstance2.render()}`;
    };

    function notify(){
        console.log("I am notified!")
        subscriber(render());
    }

    var subscriber;

    return {
        subscribe: function (f) {
            subscriber = f;
        }
        , notify: function(){
            notify();
        }
    }
}

function timer(start, notify){
    var counter = start;
    var template = wire()`hi ${counter}`;

    setInterval(function(){
        counter++;
        template = wire()`hi ${counter}`
        notify();
    }, 2000)   
    
    return {
        render: function(){
            return template;
        }
    };
}

var ui = UI();
ui.subscribe(function (template) {
    appRenderer`${template};`
})
ui.notify();

I am notified!
bundle.js:956 Uncaught DOMException: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.
    at domdiff (http://localhost:9000/dist/bundle.js:956:20)
    at Array.anyContent (http://localhost:9000/dist/bundle.js:10491:99)
    at Array.update (http://localhost:9000/dist/bundle.js:855:16)
    at HTMLDivElement.render (http://localhost:9000/dist/bundle.js:828:12)
    at http://localhost:9000/dist/bundle.js:9968:16
    at notify (http://localhost:9000/dist/bundle.js:9934:9)
    at http://localhost:9000/dist/bundle.js:9956:9

First of all I would like to thank you for your awesome work. This micro-framework/library looks really interesting and very promising indeed.

I was playing with the example provided here and stumbled upon a couple of issues.

The first one is that sometimes, when re-rendering a re-ordered array, the first item is not displayed. I've tried both with data-id attribute in the template and without it, it doesn't help much. What am I doing wrong here?

The second one is just a DOMException being thrown when trying to render the reordered array.

Both issues are illustrated by this fiddle

Hi,

We faced an issue when upgrading to 2.34 version of hyperhtml. The new behaviour with the ?disabled=${value} option causes breaking changes when using the null value.

Previous behaviour: disabled=${null} sets the disabled property on the DOM element to false Current behaviour: disabled=${null} sets the disabled property on the DOM element to true

Because of this breaking change in behaviour the major version should be bumped to 3.x.x to indicate the breaking change.

I'm writing down as raw HTML (static content only, sorry) some documentation: https://github.com/viperHTML/viperhtml.github.io/blob/master/hyperhtml/documentation/index.html

You can read it online directly via this page: https://viperhtml.js.org/hyperhtml/documentation/

I'll try to write down the API too but there are already various examples and explanations of all the things you can do via hyperHTML.

There are also 52 examples: https://viperhtml.js.org/hyperhtml/examples/

Most of them updated to use V1. There are various Code Pen too.

The reason I'm opening this issue is to review, ask more, file bugs or PRs against what will be the official documentation page for this project.

Thanks in advance to anyone willing to help.

New version 1.12.2 broken for Custom Elements. Same CodePen I used for #129 but with updated hyperHTML package.

https://codepen.io/anon/pen/vWBwOx?editors=1010

(Sorry, no time for details. You probably know your way around anyway.)

Question on the dbmonster example https://webreflection.github.io/hyperHTML/test/dbmonster.html

Is this the latest example? I'm only getting 30fps roughly? Shouldn't we aim for 60fps at least?

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency @ungap/is-array was updated from 0.1.1 to 0.2.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Publisher: webreflection License: ISC

Find out more about this release.

Your Greenkeeper bot :palm_tree:

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency @ungap/create-content was updated from 0.1.4 to 0.2.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Publisher: webreflection License: ISC

Find out more about this release.

Your Greenkeeper bot :palm_tree:

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency @ungap/weakmap was updated from 0.1.4 to 0.2.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Publisher: webreflection License: ISC

Find out more about this release.

Your Greenkeeper bot :palm_tree:

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency @ungap/template-tag-arguments was updated from 0.3.1 to 0.4.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Publisher: webreflection License: ISC

Find out more about this release.

Your Greenkeeper bot :palm_tree:

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency @ungap/custom-event was updated from 0.2.0 to 0.3.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Publisher: webreflection License: ISC

Find out more about this release.

Your Greenkeeper bot :palm_tree:

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The dependency @ungap/essential-weakset was updated from 0.1.2 to 0.2.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Publisher: webreflection License: ISC

Find out more about this release.

Your Greenkeeper bot :palm_tree: