> Broadly correct, yes, but a little clarification - elements don't have to be input elements, then can be any elements. So, for example, if the psjs-bind 'for'

> Broadly correct, yes, but a little clarification - elements don't have to be input elements, then can be any elements. So, for example, if the psjs-bind 'for' target would is a span element, then the innerText content is updated. For input elements, the value is updated, etc. I'm still working out whether this is a good idea or not. Got it. I'm curious how this works out in practice; it feels like this would end up being a bit too unstructured in practice, but that's just a guess, and that might not be an issue when it's used in relatively small amounts. > You're correct; some JS is still needed! Of course I consider that a failure that needs to be rectified - for updating the page based on user actions (or input element changes) I'm considering a custom element that subscribes to a channel and listens for a subject pattern, and then changes its style fields (`display: none` to `display: block` (or vice versa)) based on the payload. I like the idea of being able to write most/all client-side logic with custom elements and/or a server-side rendering library. It can't cover all use cases without being so general that you might as well use JS, but there's probably some 80/20 point that covers most use cases with relatively simple tools.