> I personally saw a huge project ported from Angular to React basically doing the same.

Do Angular and React components talk to each other? Lit and other Web component frameworks can share components. To refactor Lit components into other web component framework or raw web component is orders of magnitude easier than converting Angular <-> React.

> Do Angular and React components talk to each other?

You can make them talk to each other. Depends on what exactly you need, how components and projects are structured etc.

> Lit and other Web component frameworks can share components. To refactor Lit components into other web component framework or raw web component is orders of magnitude easier than converting Angular <-> React.

You're putting a false equivalency between "talking to each other" and "refactoring one code base into another".

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?

> You can make them talk to each other.

you can make almost whatever you want with code but they weren't build for that. Besides that, both angular and react are bloated software, adding another layer to create web components version of their components is just more bloat. It took some time for chariots to be considered a legacy way of transport but you can't fight its obsolescence just by saying that chariots will also carry you from one place to another.

All that is beside the point.

What a vendor lock-in basically means is that your integration with the vendor is so specific, that it's very hard to transfer to another vendor.

Lit is basically a library that makes use of the native Web Components APIs in modern browsers. If someone else would make a similar library, it would most probably have similar functionality.

So I don't really see the issue with vendor lock-in here. Most logic regarding your app is not gonna have anything to do with Lit. Only the way the templates are structured is a bit specific. But it is way less specific than JSX. Because it's just normal HTML with a few specific attributes to easily bind event listeners on HTML elements.

So Lit basically just gives you easy access to powerful browser APIs, making it really easy to build complex webapps without using a big framework.

> your integration with the vendor is so specific, that it's very hard to transfer to another vendor.

Indeed.

> Lit is basically a library that makes use of the native Web Components APIs in modern browsers. If someone else would make a similar library, it would most probably have similar functionality.

Maybe, similar, perhaps.

The meat of the matter is this. There are a lot of things in lit that are specific just to lit. They have nothig to do with web components. Custom DSL. Tasks. Reactivity. etc. etc.

So yes, when you're buying in to lit, you're locking yourself to lit, and the way lit does things.

For example, Stencil, another popular web component library, is completely different from lit: it uses a different templating mechanism, a different data binding mechanism etc. etc.

> So Lit basically just gives you easy access to powerful browser APIs

No, it doesn't give access to those APIs. It goes out of its way to hide those APIs and provide a different, ore ergonomic API on top.

Well, if Stencil is a Web Component framework using native Web Component technologies and strategies, transferring from Lit to Stencil will probably be a lot easier than from React to Angular or something.

And there are actually not that many things specific to Lit, and it's only things that would need to be solved in some kind of (opinionated) way anyway. But I think Lit does it in an elegant, intuitive and flexible way. You might like it or you might not.

I don't know Stencil, but looks nice. But their main npm package [0] is 47.8 MB, whereas Lit [1] is only 105 KB. So I would say that there are a lot more things specific in Stencil then there are in Lit. Which would probably make it harder to move from Stencil to Lit, than it is to move from Lit to Stencil.

[0]: https://www.npmjs.com/package/@stencil/core

[1]: https://www.npmjs.com/package/lit

> Well, if Stencil is a Web Component framework using native Web Component technologies and strategies, transferring from Lit to Stencil will probably be a lot easier than from React to Angular or something.

Literally everything that's on the web is using "native technologies and strategies". Because there's nothing else.

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.

Why non-trivial? Because trivial components are easy to convert from anything to anything. You could convert a trivial React component into knockout.js, then to Angular, and then to Lit, and back, in under half a day even if you've never worked with those technologies before.

> And there are actually not that many things specific to Lit

I've listed a few of them. They are opinionated enough that lit code and stencil code are completely different and incompatible.

Besides, there are a dozen or so libraries and frameworks that can, or do, compile to web components. Their code is also different from lit's.

> But their main npm package [0] is 47.8 MB

This is completely beside the point. We're not discussing Stencil, or the opinions its authors may or may not have taken.

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.

> Lit doesn't need JSX and a virtual DOM, which are React specific technologies.

But lit needs lit's custom DSL, lit's custom reactive components, custom everything.

Even in their most trivial example literally everything is custom, and specific to lit:

    import {LitElement, css, html} from 'lit';
    import {customElement, property} from 'lit/decorators.js';
    
    // custom lit-specific decorator
    @customElement('simple-greeting')
    export class SimpleGreeting extends LitElement {
      // custom lit-specific css function
      static styles = css`
        :host {
          color: blue;
        }
      `;
    
      // Custom, lit-specific reactive properties
      @property()
      name?: string = 'World';
    
      // custom lit-specific render function 
      render() {
        // custom lit-specific DSL
        return html`<p>Hello, ${this.name}!</p>`;
      }
    }

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.

That is a slight layer upon simple JavaScript string templates, nothing compared to JSX I would say

Edit: hint: that is why Lit's library is also much smaller

I: list all the custom things that lit has

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?

I mean they have to be for now - you're just being semantic for the sake of it a bit. I will say as a team that utilizes Lit for our design system web components (which none of our users even need to know or care about no matter their framework btw). The Lit team are huge advocates of aligning with native standards (now or what they might be in the future) and working to establish or push them forward. The goal of the project for a lot of these issues truly seems to be to eventually not need them to be a part of Lit at all.

> you're just being semantic for the sake of it a bit.

No. I'm calling it as it is. I don't pretend that something isn't a framework when it has all the same things that the frameworks they so love to vilify do.

> The Lit team are huge advocates of aligning with native standards

Which of the things that lit provides are native standards current or future? Its template DSL? Its custom decorators? Its data binding system? Tasks? Directives?

Not to mention the usual workarounds like support for SVGs https://lit.dev/docs/api/templates/#svg