politics

In terms of low decoupling:

It sometimes makes working with _slotted_ children in a non-lock-in way difficult in terms of state synchronization as opposed to props.children in React. The solution here in an app would be to use a state manager, but it's much more difficult for components that do not want to require the user to use a state manager e.g. design systems.

Additionally, hydration and customElements.define() upgrade order is a different consideration compared to other mono-state frameworks when it comes to SSR.

In terms of state management:

There are plenty of tools out there like lit-mobx shopped by Adobe. The team has also made some examples that show how easy it is to integrate your own state manager into Lit using ReactiveController such as Redux. There is also work being done such as example implementations of Preact Signals integration:

https://github.com/lit/rfcs/blob/preact-signals/rfcs/NNNN-pr...

I worked on adding some of these. We pull them from each of the company's respective brand identity page + some manual SVG cruft elimination to decrease code size.

Yeah, this is not an issue for very well-designed WCs like https://shoelace.style or in cases where it's not necessary like https://modelviewer.dev/

unstyled web components: look into ING Lion Web Components (Lit-based) or @generic-components/components (vanilla)

In that case why not just SSR lit on the backend and send that? It sounds like an unfair criticism otherwise

I have the full React framework and ecosystem if I so choose to use it. For example, I could use something like react-three-fiber to add 3D or Framer Motion to add animations yet fall back to not having those when JS is disabled. Sure you could do the same in Lit but those libraries aren't present or as robust as in React.

It's easy to add interactivity to a NextJS site when you need it.

Likewise with Lit, but that is besides the criticism that he was making earlier

When one writes `import 'lit'` the browser doesn't know where Lit is. This is called a bare module specifier vs an absolute import specifier:

  import '/home/user/project/node_modules/lit/index.js'

A relative specifier:

  import '../node_modules/lit/index.js'

Or a URL Specifier:

  import 'https://unpkg.com/lit?module'

So you have four-ish options to tell the browser where to look for 'lit':

1. Use a server that will use the node module resolution algorithm and transforms it to a relative specifier as it encounters the import (transform/build-ish?)

2. Use experimental "import maps" to go fully buildless to tell the browser where to point that bare module to (buildless)

3. Bundle all your code (build step)

4. Use a bundle from a CDN

Here are some examples of each:

Server that transforms import specifiers (lit.dev does this by default):

https://lit.dev/playground/#gist=9092862a77acf73dd1e6faa73a3... (build-ish)

Import Maps (2):

https://lit.dev/playground/#gist=0c4f66396b333c82cb27e7dd3b2... (buildless)

https://lit.dev/playground/#gist=91c0b286698612b013eb81881ff... (build-ish)

Url Specifiers (2):

https://lit.dev/playground/#gist=05655736300f0425644e61a6264... (buildless)

https://lit.dev/playground/#gist=6d23e8e8dadacd7488bdec81d0f... (build-ish)

hope this helps with some of your questions

Cool, appreciate the thorough answer! I'll give Lit another look now that I understand how to run it buildless + static.

Web Components are Custom Elements + Shadow DOM, and this makes half of that equation server-side. The other half works as a client-side hydration strategy until they churn out whatever Declarative Custom Elements would look like.

let's be real. nobody is crushing anybody in development speed with webpack. Use rollup esbuild or vite

FWIW preact is 4kb minzipped (+ 700 bytes for htm package templating) while lit-html is 3.3kb minzipped.

Author also talks a lot about the issues with losing control of the component model when using preact