Lit – Eine schnelle und schlanke Bibliothek zum Erstellen von Web Components

• Fügt auf Basis des Web-Component-Standards nur Reaktivität, deklarative Templates und minimalen Boilerplate-Code hinzu
• Mit einer geringen Größe von etwa 5 KB sowie schnellem Rendering werden Leistung und Ladegeschwindigkeit optimiert, indem nur die geänderten UI-Bereiche aktualisiert werden
• Alle Lit-Komponenten sind native Web Components und können unabhängig vom Framework überall dort wiederverwendet werden, wo HTML eingesetzt werden kann
• Nutzt das Shadow DOM, um den Geltungsbereich von Styles standardmäßig zu begrenzen, CSS-Selektoren zu vereinfachen und Konflikte mit anderen Styles zu vermeiden
• Modelliert mit Reactive Property die Komponenten-API und den internen Zustand und unterstützt effizientes erneutes Rendering bei Änderungen von Eigenschaften
• Schnell und einfach dank Templates auf Basis von Tagged template Literals
• Einsetzbar in verschiedensten Webprojekten – von gemeinsam genutzten Komponenten und Design-Systemen bis hin zum Aufbau kompletter Apps mit weniger Vendor Lock-in und besserer Wartbarkeit
• Tutorial verfügbar
• GitHub

[devstudyman7]

Das empfinde ich seit drei Jahren so: Für den direkten Einsatz von Vanilla Web Components ist es schnell, und es wirkt wie ein Framework für die Übergangsphase, aber langsam..

[cnaa97]

Was soll das heißen?

[bluemir]

Ich entwickle Betriebstools ausschließlich mit Web-Standards-Web-Components und lit-html, und mir gefällt, dass die Menge an Wissen, die man dafür kennen muss, auf ein Minimum reduziert ist. Von den Funktionen in lit-html nutze ich im Grunde nur Event-Handler-Binding und Loop-Templating. (Für den Rest reichen Web-Standards eigentlich aus ...) Es ist zwar etwas umständlich, dass man bei Änderungen render direkt aufrufen muss, aber statt dass Änderungen an Variablen automatisch erkannt werden und dadurch implizites Verhalten entsteht, kann ein expliziter Aufruf in mancher Hinsicht auch hilfreich sein. Da es sich um Betriebstools handelt, hat die Unterstützung für verschiedenste Umgebungen eine niedrigere Priorität, deshalb empfinde ich das vielleicht auch so.

[GN⁺]

Hacker-News-Kommentare

• Wir hatten Lit in einem Firmenprojekt im Einsatz, verwenden es inzwischen aber nicht mehr, und ehrlich gesagt bin ich ziemlich erleichtert darüber.
  Wir nutzten bereits ein schwergewichtiges Framework, und dass jemand Lit hinzugefügt hat, nur um noch eine Zeile mehr im Lebenslauf zu haben, war eine große Belastung.
  Vor allem Shadow DOM hat die **Accessibility-(A11y-)**Probleme noch verschärft. Durch den getrennten id-Scope wurden Verknüpfungen wie label-for und describe-by kaputtgemacht, was uns viel Ärger bereitet hat.
  Natürlich lag ein Teil davon auch an den fehlenden Skills unseres Teams.
  • Die Integration von Web Components in eine React-Codebasis war wirklich hart. Ich denke weniger, dass es an Lit lag, sondern eher an Web Components selbst.
    Styles sind zwar gescoped, aber wichtige Dinge wie Schriftgrößen sind davon ausgenommen, weshalb bei jedem Austausch immer wieder kleine Regressionen entstanden.
    Auch die DX hat deutlich gelitten. Ich hoffe, dass das Tooling besser wird, aber im Moment ist das Ganze einfach nur anstrengend.
  • In Lit ist Shadow DOM optional, man kann es also pro Komponente deaktivieren.
  • Ich frage mich, ob es wirklich oft vorkommt, dass jemand eine Technologie nur einführt, um den Lebenslauf aufzupolieren.
    Tatsächlich scheint es häufiger zu sein, dass Leute einfach etwas Neues ausprobieren wollen und es ohne große Rationalisierung einführen.
• Ich habe selbst eine State-Management-Library für Lit gebaut (258 Zeilen, https://github.com/gitaarik/lit-state).
  In komplexen Apps mit ineinander verschachtelten Komponenten, die miteinander interagieren, hat sie gut funktioniert. Sie ist React ähnlich, aber viel browsernativer, hat weniger Boilerplate und rendert schneller.
  Ich verstehe kaum, warum Lit nicht populärer ist.
  • Ich habe Lit auch einmal von Grund auf selbst nachgebaut, um besser zu verstehen, wie es intern funktioniert.
    Die Kernfunktionen sind überraschend einfach und stützen sich größtenteils auf Plattform-APIs.
    Deshalb kann es im Grunde jeder selbst implementieren, und genau diese Einfachheit halte ich für einen großen Wert.
    Zur Referenz: Meine alternative Implementierung ist https://github.com/ruphin/lite-html
• Ich bin ein Maintainer von Lit. Warum es heute plötzlich auf der HN-Startseite gelandet ist, weiß ich auch nicht, aber wenn ihr Fragen habt, beantworte ich sie gern.
  • lit-html ist wirklich nützlich, deshalb verwende ich es in fast allen privaten Projekten.
    Dass man es direkt über ein CDN laden und ohne Build-Schritt experimentieren kann, ist ebenfalls ein großer Vorteil.
    Es ist nicht so schwergewichtig wie andere Frameworks, und es fühlt sich einfach an wie Vanilla JS + HTML, also mit kaum kognitiver Last.
  • Da viel über Shadow DOM gesprochen wurde, hier meine Gedanken dazu.
    Shadow DOM ist im Grunde ein privater Tree, der den internen DOM einer Komponente isoliert.
    Dadurch wird das Konzept von Slots möglich, womit sich wirklich zusammensetzbare Komponenten bauen lassen.
    Das Problem ist, dass die Style-Kapselung bei der Integration in bestehende Systeme zu einer großen Hürde wird.
    Deshalb habe ich einen Vorschlag namens Open Styleable Shadow Roots gemacht: Externe Styles dürfen nach innen durchfließen, während Slots erhalten bleiben. Ich versuche derzeit noch, die Browser-Vendoren davon zu überzeugen.
  • Lit ist ein sauberes Tool, bei dem das Framework nicht im Weg steht, deshalb baue ich alle privaten und beruflichen Apps damit.
    Dazu habe ich auch einen Artikel geschrieben: https://medium.com/gitconnected/getting-started-with-web-com...
  • Dank Lit macht Entwicklung Spaß, egal ob für einfache oder komplexe Anwendungsfälle.
    Manchmal frage ich mich wirklich, warum es sich nicht weiter verbreitet hat.
  • Es gibt die Frage, ob Funktionen wie in Lit irgendwann in den Web-Components-Standard aufgenommen werden könnten.
    • Web Components sind großartig, weil sie nativ sind, aber es stimmt, dass ihre Akzeptanz langsamer ist, weil Reaktivität fehlt.
    • Lit ist eine natürliche Erweiterung, die genau diese Lücke schließt.
• Ich habe Lit im XMPP-Chat-Client-Projekt Converse.js verwendet.
  Ursprünglich basierte es auf Backbone.js, dann haben wir schrittweise von lit-html zu lit-element und schließlich zu Lit migriert.
  Heute wird es als Web Component namens <converse-root /> ausgeliefert und lässt sich dadurch auch gut in andere Frameworks wie React integrieren.
  GitHub: https://github.com/conversejs/converse.js / Demo: https://chat.conversejs.org/
• Inzwischen habe ich das Gefühl, dass ich Lit nicht mehr brauche. Es ist bequemer, einfach mit reinen Web Components zu arbeiten.
  Wenn man auf dem Server ein Template-System wie JSX verwendet, ist das völlig angenehm, und auf dem Client ist es einfach nur JS, sodass man sich keine Sorgen über Upgrades machen muss.
  • Der Vorteil von Web Components ist, dass man sie so bauen kann, wie man möchte.
    Allerdings sind die nativen APIs zu Low-Level, sodass die DX zu wünschen übrig lässt, und Lit legt darauf eine deklarative Reaktivitätsschicht.
  • Ich finde, Lit abstrahiert die wiederkehrende ``-Verarbeitung und die DOM-Verkabelung sehr gut.
    Es löst die lästigen Teile, die man sonst selbst bauen müsste, auf elegante Weise.
  • Persönlich habe ich zwischen den html-Template-Literalen von Lit und JSX nie einen großen Unterschied gespürt.
    Eher im Gegenteil: JSX ist lästiger, weil dafür ein Compile-Schritt nötig ist.
• Ich nutze Lit seit drei Jahren in Produktion. Meiner Meinung nach ist es die beste Abstraktionsschicht auf der Web-Components-API.
  • Ich habe sehr ähnliche Erfahrungen gemacht.
    Anfangs habe ich Web Components in einer Umgebung ohne Abhängigkeiten direkt selbst gebaut, aber später war der Wechsel zu LitElement deutlich angenehmer.
    Shadow DOM ist zwar der Standard, hat aber eher zusätzliche Probleme verursacht, deshalb verwende ich LitElement inzwischen ohne Shadow DOM.
• Ich verwende Lit seit 2020 in Produktion und habe es kein einziges Mal bereut.
  Der größte Vorteil ist, dass es auf einem stabilen Fundament steht.
  Native Web Components werden von allen Browsern zuverlässig unterstützt, sodass man sich auf Entwicklung konzentrieren kann, ohne das Risiko eines Framework-Wechsels.
  Ich würde mir wünschen, dass mehr Teams es ausprobieren.
  Übrigens kann ich auch dieses HTTP 203-Video über Lit empfehlen.
• Für Frontend-Arbeit war Lit wirklich eine Art Lebensretter.
  Angular ist viel zu schwergewichtig, und React wirkt wie etwas, das für die Einschränkungen alter Browser entworfen wurde und heute nur noch aus Trägheit weiterlebt.
  • Ich würde gern konkreter hören, welche alten Browser-Funktionalitäten damit gemeint sind.
  • Ich mag das Framework Aurelia, weil es Standards gut folgt und der Code kompakt ist.
    Im Vergleich zur Boilerplate von Angular oder der Hook-Komplexität von React ist es viel intuitiver.
    Schade nur, dass es nie richtig populär geworden ist.
  • Wenn jemand sagt, React sei wegen der Unterstützung alter Browser groß geworden, fühle ich mich plötzlich alt.
• Ich mag lit-html als reine Rendering-Library, aber ich habe nie den Bedarf für Lit als Ganzes gespürt.
  Im Grunde reicht für mich die Kombination aus + Web Components.
• Ich möchte Komponenten aus einem großen Vue-3-Projekt auch auf anderen Seiten wiederverwenden und sie deshalb als Web Components ausliefern.
  Mich interessiert, welchen Vorteil es hätte, sie statt mit Vue noch einmal mit Lit neu zu bauen.
  • Ich habe sowohl Vue als auch Lit verwendet, und persönlich fand ich Vue etwas besser.
    Das ref/reactive-State-Management von Vue 3 ist stark und lässt sich ohne DOM-Abhängigkeiten testen.
    Die Reaktivität von Lit ist eher auf Widget-Ebene, sodass man Update-Trigger selbst verwalten muss.
    Der Lifecycle von Vue ist einfacher, während man bei Lit mehrere Callbacks im Blick behalten muss, was Bugs begünstigen kann.
    Wenn es keinen besonderen Grund gibt, ist es besser, sich auf die Feature-Entwicklung zu konzentrieren; ein Wechsel des Tech-Stacks hat für Nutzer fast keinen spürbaren Effekt.
  • Aus Sicht der Verbraucher gibt es keinen Unterschied, ob es mit Vue oder Lit gebaut wurde – am Ende sind es Web Components.
    Vue ist ein Framework und bietet mehr Funktionen, Lit setzt näher auf den nativen APIs auf.
    Für Vue braucht man einen Build, Lit kann dagegen auch zur Laufzeit geladen werden.
    Vue kann auch auf andere Targets kompilieren, Lit ist dagegen auf Web Components spezialisiert und dadurch aufgeräumter.
    Letztlich ist am wichtigsten, womit das Team besser vertraut ist.
  • Der praktischste Ansatz ist wahrscheinlich einfach, ein Web-Component-Bundle zu bauen und auszuliefern, während man intern umsetzt, was man möchte.
    Den Konsumenten ist die interne Implementierung egal; wichtig sind nur Größe und API.
    Andere werden sich ohnehin Adapter für ihre eigene Umgebung bauen.