Sorry but I think it is quite obvious that a large framework will create much more lock-in and dependency than a tiny library. The more specific stuff you use, the more you are locked in. And yeah Lit still does some things for you so there's always some lock-in, with any library that you use. So it's not about simply whether it is a lock-in or not, but the amount of lock-in.
Lit doesn't need JSX and a virtual DOM, which are React specific technologies. You have to design your React components with these technologies in mind. With Lit there are much less dependencies like that, so your code will be less designed for a specific framework, making it easier to move to another framework that doesn't impose a specific workflow.
So. So, extraordinary claims require extraordinary proofs. I eagerly await a description, with examples, of how much work there is to convert a non-trivial lit component to Stencil.
BTW. Claiming that Virtual DOM is somehow a react-specific technology (and that somehow apparently affects conversion from React to something else) really shows how much you understand about the topic at hand.
I: ask to show me how converting from lit to something else is easier as you claim
You: ignore everything completely and answer a question literally no on asked, and pretend that the only custom thing is the DSL.
Yup. My choice to completely ignore you in a sibling discussion was correct.
On the other hand, after a few years of engaging with web component defenders, propoenents and propagandists I'm not surprised in the least. This behaviour is on par with the rest of them.
From all our arguments I think it's obvious that Lit has less lock-in than any other framework we discussed. If you find it so important to prove your point, why don't you make an exstensive comparison of all the discussed frameworks?
Lit doesn't need JSX and a virtual DOM, which are React specific technologies. You have to design your React components with these technologies in mind. With Lit there are much less dependencies like that, so your code will be less designed for a specific framework, making it easier to move to another framework that doesn't impose a specific workflow.