... it's working great. But now I miss the benefits of utilities in Lit's ecosystem, and in some cases would benefit batching when some logic can get run multiple times when many properties update.

I made the element have an near identical API to Lit though, so it's not impossible to switch back

I keep going back and forth on this at work. We started with ReactiveElement since we don't use JS templating. But then sometimes the async reactive lifecycle feels heavy-handed when all of the DOM updates are imperative.

I recreated a similar base el with preact signals and... (tbc)

Ok

We’re using BEM and host selectors like :host(component-name) to prevent collisions. I guess you could include something like tailwind if you want the utility class approach. But you’d probably need :host() and ::slotted() at some point

To avoid FOUC, we have all of the elements set to visibility: hidden in the global document, then the shadow DOM stylesheet will override that and make them visible.

For any elements CSR'd after page load, we use that same stylesheet as a CSSStylesheet (or <style> if browser doesn't support)

As mentioned in another thread, we're using a link tag pointing to an external stylesheet. For build simplicity and caching, we have one stylesheet for the entire component library. So browsers should only fetch the stylesheet for the first component.

Making a custom element submit forms like <button> elements, without JS. I've encountered this issue a bunch working in e-commerce.

Oh I didn’t realize that. When you say checking whether the 2 are the same, is it comparing strings of HTML? I’ve been a little paranoid about perf ramifications of morphdom, but haven’t found a better solution. (Other than managing shadow DOM with imperative JS)

I’m not super familiar with lit-html source code, but doesn’t it have its own diffing logic?

I just worked on a mustache + morphdom combo integration with ReactiveElement at work. Seems to be working well, but not battle-tested yet

Not 100% what you're looking for, but there's some interesting nuggets here github.com/ChrisShank/p.... My favorite takeaway here is annotating the markup with "event intentions", and then orchestrating the events in single place via event bubbling.

Would a combo of morphdom/idiomorph and an HTML templating lib (mustache, handelbars, pug, etc) work? Not quite clear on what the workflow would be for integrating a reactive library with markup it didn't make 🤔

Now importNode and cloneNode have the same performance in Chrome: issues.chromium.org/issues/37124...

I'm happy frameworks can get simpler, but also because Lit, which always uses importNode, probably just got faster too.

Filing issues for browser implementation bugs is a good thing for everyone!

We’re currently using Mustache, and we have a PHP compiler for it on the server and a JS compiler on the client. You only really need a string of HTML, and you can configure your JS bundler to create a loader for your template files.

Is the public api React/Svelte components, each which render a web component with declarative shadow DOM?