[spankalee]

I work on Lit, which I would hesitate to call a framework, but gives a framework-like DX for building web components, while trying to keep opinions to a minimum and lock-in as low as possible.

It's got reactivity, declarative templates, great performance, SSR, TypeScript support, native CSS encapsulation, context, tasks, and more.

It's used to build Material Design, settings and devtools UIs for Chrome, some UI for Firefox, Reddit, Photoshop Web...

https://lit.dev if you're interested.

[troupo]

> lock-in as low as possible.

As in:

- reactivity. Specific to lit

- declarative templates. Specific to lit

- SSR. Specific to lit.

- context. Specific to lit.

- tasks. Specific to lit

"minimal" and "low lock-in".

Please do not hesitate to call it a framework. If you call React a framework, then lit is definitely a framework.

[spankalee]

Lit's features are internal to each component (except context which is being developed as an open community protocol with the Web Components Community Group) and there is no coupling between components written in Lit. So you can port from Lit to something else component-by-component.

Lit is also modular. The template library, lit-html, is usable independently and used by other web component and non-web component libraries. The reactive custom element base class ReactiveElement can be used to build web components with a different template system like Preact.

So yes, "lock-in as low as possible".

[troupo]

This is just splitting hairs in an attempt to pretend that lit isn't a framework (or framework-like lib), or that it's somehow unopinionated, or that it somehow prevents you from lock-in.

Almost all of the things you listed are specific to lit, and lit only. So, people who will develop with lit will be locked in to lit. Because it's not like you can just pop the code you wrote with lit into stencil or ionic, and will just work.

> So you can port from Lit to something else component-by-component.

I personally saw a huge project ported from Angular to React basically doing the same. It's not a testament to lit. It's what people have been doing since time immemorial.

[meiraleal]

> 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.

[troupo]

> 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?

[meiraleal]

> 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.

[gitaarik]

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.

[troupo]

> 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.

[gitaarik]

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

[hmcdona1]

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.

[troupo]

> 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

[veeti]

How do we know this won't be killed off by Google in six months?

[spankalee]

Honestly, you don't. It's used for many Google projects like Chrome, parts of YouTube, Maps APIs, Collab, the Google Store, and a ton of internal things, so I think it's unlikely, but I understand Google's reputation.

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.

[troupo]

> It's used for many Google projects like Chrome, parts of YouTube... so I think it's unlikely,

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?

[gitaarik]

I never used Polymer but as far as I understand it was always an experimental project for the then very young technology of Web Components. And it was a rather opinionated framework also. Lit is just a very lightweight layer on top of the now matured Web Component API. And you are not really dependend on a strong community releasing occational security updates and new features and bugfixes, because it's very small and simple, and it won't really need much new features, because Lit doesn't want to be a opinionated framework, but a simple tool for a single job: rendering a web component.

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.

[troupo]

> as far as I understand it was always an experimental project for the then very young technology of Web Components

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...

[gitaarik]

Well, any popular framework has all these things, and most frameworks have a lot more. Lit is really the littlest amount of tools you would want. With less than that, you can just as well directly use the web component APIs, and not use a framework / library at all. I don't know what you imagine would be a less opinionated way without having to chip in on usability.

[matt7340]

I've read that Angular is also extensively used for Google internal projects. How do the teams choose between Angular and Lit?