This is one reason why we care so much about low coupling and lock-in, and a small, easy-to-understand codebase. You should be able to migrate away from Lit very easily, and fork or maintain it if necessary. We're also trying to build up our non-Google contributors.
When Custom Components v0 was barely released Google re-wrote Youtube with Polymer. Where's Polymer now?
> You should be able to migrate away from Lit very easily
And that should comes from which part of lit? Custom DSL? Custom decorators? Custom data bindings? Custom tasks?
As I wrote elsewhere, Preact, Svelte, Vue, and Angular can all be compiled to web components. How easy do you think it would be to convert app code between each of these frameworks? Convert that code to and from lit?
So because it's small and doesn't need much new features, it's also easy for the community to maintain it. I think not much has changed in the Lit library over the last few years. So it's also easy with upgrading.
So experimental that Google even had a Polymer Conference and was promoting it heavily, like it promotes lit now.
> because Lit doesn't want to be a opinionated framework
For a "non-opinionated" framework it sure does have a lot of opinions: custom DSL, custom directives, custom decorators, custom way of building elements...
- reactivity. Specific to lit
- declarative templates. Specific to lit
- SSR. Specific to lit.
- context. Specific to lit.
- tasks. Specific to lit
- directives. Specific to lit
"littlest amount of tools"
Splitting hairs
> The others are very basic functionalily for what you expect from a framework like Lit.
Indeed. Framework like Lit. These mental hoops and shenaningans lit defenders have to jump and go through to pretend lit is somehow not a framework and somehow different.
Literally the very first example you get on lit's own page show how invalid all those claims are: https://lit.dev/docs/components/overview/