6 ms·

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

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 https://lit.dev if you're interested.

troupo 3y ago
> 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 3y ago
  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 3y ago
    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.
    - hmcdona1 3y ago
      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 3y ago
        > 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 https://lit.dev/docs/api/templates/#svg
    - gitaarik 3y ago
      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 3y ago
        > 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.
veeti 3y ago
How do we know this won't be killed off by Google in six months?
- spankalee 3y ago
  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 3y ago
    > 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 3y ago
      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 3y ago

> 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 3y ago
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 3y ago
  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.
  - hmcdona1 3y ago
    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 3y ago
      > 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 https://lit.dev/docs/api/templates/#svg
  - gitaarik 3y ago
    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 3y ago
      > 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.

veeti 3y ago

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

spankalee 3y ago
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 3y ago
  > 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 3y ago
    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.