[oblak]

I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution.

On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve a number of problems that are not directly solved by Web Components. State management, rendering, routing - right now, these are, imho, the high level areas that need solid solutions for an UI app to function in any sane way. How much of that is solved by going Web Components?

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

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

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

[matt7340]

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

[earthboundkid]

"Web Components" are the name for a dream, not an actual technology. The actual technologies involved -- customElement and shadow DOM -- are pretty crappy to use directly, and even when hidden behind a framework/library don't buy you that much. But people want it to be true that there is such a thing as a "Web Component" so the dream lives on.

[gitaarik]

Why do you think this? I've been using it for years and it works lovely, no complaints at all.

[o11c]

> I've been fought by people insisting that if we're using a framework, we should be using it for everything,

Remember the definition of a framework: a framework is just a library that does not play well with others.

[jdmg94]

Stencil does it, but the resulting web components are still not great to work with because of shadow dom and the missing standards you can't expect from custom elements. You want inline styles? hope your dev remember to drill those down.

[DarkNova6]

A foolish consistency is the hobgoblin of the little mind

[toasted-subs]

Svelte compiles into WebComponents.

[beebeepka]

That's good to know. I really liked what I saw last time I played with it but it's hard to find many job listings where people are using svelte. Almost everything is react and surprisingly, at from what I can tell, it's getting even bigger share in job postings I used to see. Hooray for uniformity, I guess.

[steve_taylor]

That’s news to me and probably everyone who uses Svelte including its developers.