> I installed lit-html and got to work. “Components” were simply functions that returned lit-html template results. A big singleton at the top of the tree held

> I installed lit-html and got to work. “Components” were simply functions that returned lit-html template results. A big singleton at the top of the tree held onto all the application state, stored as a global variable within that module. > The first hurdle came when a component needed local state. I could have lifted it to the singleton, but that would have broken the component’s encapsulation. I noticed that lit-html directives can keep state, so I decided to use them to build a tiny component library — ignoring a warning from the lit-html developers that this wasn’t a supported use case. > My home-brewed library worked great… until I needed to run some code when a component appeared on the screen. I started digging through lit-html documentation and issues looking for a way to detect a directive’s lifecycle, but it became clear to me that going down that path would be painful. So the author knows about lit-html, good. I guess the obvious question at this point is why didn't he continue down the lit path he was already on, and tried lit-element? Lit-element should have given him observable local state (it's class-based web components), and would have given him lifecycle hooks (e.g. connectedCallback for doing something when a component appears on the screen). Lit-element is from the same ecosystem as lit-html; yet the author doesn't seem to have explored it at all. Why?