Echo JS 0.11.0

Well, in general, for me, they lack somewhat the context for decisions. So, to take for one example, the discussion of partial attributes here: 

https://viperhtml.js.org/hyperhtml/documentation/#essentials-7

I read through this section, and I have the following questions. Please bear in mind that I am not a trained computer scientist, mathematician, or language designer. I'm just an everyday web developer who's been doing this for 20+ years. I'm not trying to pick hairs, but these are genuinely the questions I have on reading this section. 

Questions:

- What is a partial attribute, and why should I care that it is not supported? I presume this is a counter-reaction to something in Angular or React or some online discussion of framework design, but I don't know why it is relevant to know this.

- So, I see the difference between these two lines, but I don't quite get why #2 should be problematic, and the discussion in this section does not really explain it:
1) html`<div style=${`top:${top}; left:${left};`}>x</div>`;
2) html`<div style="top:${top}; left:${left};">x</div>`;
Like, what if I have a set of classNames on an element, but they are toggled from different sources. Doesn't that seem like it would work more like #2? I mean, I do think I get that you're saying that there are performance costs to splitting up an attribute that has multiple values. It's just not clear why this has to be discussed specifically to this length, and what breaks when I try #2.

Not trying to rag on the library at all - and by the way, I feel like these docs are much improved over the earlier versions - just trying to explain my comment above. I will take another crack at it now that the docs are so much more explicit. 

In fact, I'd suggest in order to take off, hyperHTML needs more "soft" content comparing specific features and tradeoffs made vs. the other libs. Articles and tutorials and deep dives and stuff.

Like, I read this under "API": 

"Even though hyperHTML is a function, it should be used as a namespace.
Every method is detached from its context so that you can easily destructure them.

const {bind:hyper, wire} = hyperHTML;
 
hyper(document.body)`
  ${wire()`<h1>Hello Content</h1>`}
`;
"

I can only say, huh? 

It's clear that a lot of thought went into the choices made for this library, but not as clear why those choices matter, and how they inform the decisions I will make as a developer. 

I'd go so far as to say that documentation drives the success of Vue as it did React before that, more so than the technical merits of these libraries. I want to believe that hyperhtml is the superior choice, as it feels "right" to me, but the path from liking it to using it seems daunting.

Anyway, keep it going - I like what I see!