Hacker News Reader

Comment by veeti | Hacker News Reader

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

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.

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

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

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.

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

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.

> Lit is really the littlest amount of tools you would want.

- reactivity. Specific to lit

- declarative templates. Specific to lit

- SSR. Specific to lit.

- context. Specific to lit.

- tasks. Specific to lit

- directives. Specific to lit

"littlest amount of tools"

SSR, context and tasks are all separate packages, not in the Lit core package. The others are very basic functionalily for what you expect from a framework like Lit. It has to do something ultimately :D

> SSR, context and tasks are all separate packages, not in the Lit core package.

Splitting hairs

> The others are very basic functionalily for what you expect from a framework like Lit.

Indeed. Framework like Lit. These mental hoops and shenaningans lit defenders have to jump and go through to pretend lit is somehow not a framework and somehow different.

Literally the very first example you get on lit's own page show how invalid all those claims are: https://lit.dev/docs/components/overview/

Reply on news.ycombinator.com