WebComponent libraries lit-HTML and litElement released | Hacker News Reader

WebComponent libraries lit-HTML and litElement released

polymer-project.org

29 pointsvelmu18 comments

At Home Assistant we have used Lit Element to power our new user interface and it has been great. Small and fast components, easy to learn for new developers, intuitive API.

One of the coolest thing is directives, https://lit-html.polymer-project.org/guide/template-referenc... (you can also write your own). Directives are attached to a DOM element and can interact with the DOM as they see fit. Examples are awaiting an async iterator and writing results to the DOM as they come in, or have a directive that attaches an animation or ripple effect to an element on click.

For people interested in a UI built with it, the Home Assistant demo is at https://demo.home-assistant.io and source is at https://github.com/home-assistant/home-assistant-polymer/tre...

Maintainer of lit-html here. AMA, especially if you're interested in how lit-html works, or where we're going next :)

Congratulations on releasing! I think it’s the right approach to use the platform rather than extending it a la JSX. I have a few questions:

1) What is the situation with the patent grant? I know React had something similar at an earlier point, which was heavily criticized and eventually removed.

2) Is there a way to precompile templates, sort of like what a lot of CSS-in-JS libraries do?

3) I was browsing through the source a couple of weeks ago, and it came across as a rather convoluted everything-must-be-a-class design, which I found surprising considering the simple functional style the library encourages externally. Do you think this is motivated over a more straightforward, procedural design?

Thanks!

1) I know basically nothing about patents, grants and licenses, so I can't comment there.

2) There are transforms to help minify lit-html templates, like https://github.com/asyncLiz/rollup-plugin-minify-html-litera... . See https://github.com/web-padawan/awesome-lit-html for more

3) lit-html requires objects with state and behaviors. Seems a perfect fit for classes. We usually get feedback that the source is very readable. I don't think there's any tension between the implementation using classes and the API surface being functional.

If people are interested in getting started with web components, lit-html and LitElement, we have a bunch of scaffolding and tooling ready to go at: https://open-wc.org/

open-wc.org is a really great project. Thanks for your work there!

We have used Polymer (1, 2 & 3), lit-html and LitElement on large production websites for some time now.

Following the progression was a rocky road at times but it really does now provide a very lean base to build from. I rarely find the need to use a framework or some such library anymore unless for consistency within existing projects.

Reuseable components really are easy now and really are reuseable. It'll be very interesting to see where this project goes...

Build GraphQL apps using lit-element for rendering with lit-apollo:

https://npm.im/@apollo-elements/lit-apollo

I built a demo chat app that got a 98 lighthouse performance score

https://lit-apollo-subscriptions.herokuapp.com

Awesome!

The project is still in beta, but Freestyle Stats website is built with LitElement & Redux! It has a nice +95 Lighthouse score!

https://freestylestats.com

Been using Polymer for the last year and loving it. Happy to do very little to get my element portfolio progressively over to litElement. Congrats to the polymer project team on getting this out there!

Love lit-html/lit-element! Personal project: https://my-project-75792.firebaseapp.com/

Both these look great, But I dont understand Googles stand on Polymer now. Does Polymer use this or Polymer and lit-* are going different direction

https://www.polymer-project.org/blog/2019-02-05-lit-element-... is probably a better link for context. These two lightweight libraries are building on top of browser advances.

And now I’ll start speculating, I’ve no inside baseball — but the way I see it, Polymer is having a bit of a re-think (3 times in a row now, if I recall correctly) because some early ideas on HTML includes and zip packaging are taking longer to become web standards. And having little market traction, with official Material components published for multiple JS frameworks, Polymer has to evolve and simplify to gain traction. These projects appear to be part of that evolution.

I suspect the next thing that might encourage more use of these sort of components and modularization would be the “never-slow” modes recently debated on HN, but there’s a push and pull. Sometimes browser-makers get web devs to adopt their new APIs or heed their warnings, other times it’s the browser-makers wondering if they can make virtual dom diffing more efficient, or effectively embed the core of React or Vue frameworks into first-class browser APIs. If so, these might be considered a first step towards newer API iterations. I’d really like the inside scoop on how web components are working out for Google/YouTube in practice, but for now these frameworks are just “yet another way of doing web components”, but with potential if Vue or other front-end JS frameworks adopt them down the road now that the API for these have hit a stable 1.0.

lit-html and LitElement are products of the Polymer project. They're different enough from the classic Polymer library, yet can be used interoperably with Polymer because it's all just web components, that they deserved new names.

The classic Polymer library is in maintenance mode now. It's getting critical bug, security, and performance fixes only. We're moving customers from Polymer 1 & 2 to Polymer 3, then from there we're encouraging them to incrementally adopt LitElement, which again, they can do because they work together.

Our situation is quite different from frameworks because of web components. First, we care more about web components adoption than any specific library. Then, because apps can mix web components made with different libraries, we don't have to bank everything on one flavor or specific set of ideas. That said, we think lit-html is an even better solution than what we've had before, and we're focusing on that.

How does LitElement compare with something like hyperapp[1] or meiosis[2]? The issue I have with $new_tool is trying to figure out what it offers vs the competing tools and it's a non-trivial time sink.

[1] https://github.com/jorgebucaran/hyperapp

[2] https://meiosis.js.org/

Hyperapp isn't Web Components. We're able to freely mix Polymer and LitElement components because the browser does it for us.

LitElement really is just Web Components with reactive properties and lit-html rendering. Everything else is plain HTMLElement. Hopefully there's very little to learn that's not standard and transferrable to any other web-based code.

I'm not exactly sure what Meiosis is, to be honest.

Are there any ready made components available yet? Something similar to PrimeNG or Vuetify?

Do the material web components count? They are being rewritten using lit-(HTML|Element)

Reply on news.ycombinator.com