Lit - bibliothèque rapide et légère pour créer des Web Components

• Ajoute au standard des Web Components uniquement la réactivité, des templates déclaratifs et un minimum de boilerplate
• Une petite taille d’environ 5 KB et un rendu rapide, avec mise à jour des seules parties modifiées de l’UI pour optimiser les performances et la vitesse de chargement
• Tous les composants Lit sont des Web Components natifs, réutilisables partout où l’HTML peut être utilisé, indépendamment du framework
• Utilise le Shadow DOM pour limiter par défaut la portée des styles, simplifier les sélecteurs CSS et éviter les conflits avec d’autres styles
• Modélise l’API du composant et son état interne avec des Reactive Properties, et prend en charge un rerendu efficace lors des changements de propriétés
• Des templates basés sur les tagged template literals, rapides et simples
• Peut être utilisé dans divers projets web, des composants partagés aux design systems, jusqu’à la création d’applications complètes réduisant la dépendance à un fournisseur et facilitant la maintenance
• Tutoriel disponible
• GitHub

[devstudyman7]

Je le ressens depuis 3 ans : c’est rapide pour utiliser directement des Web Components vanilla et ça donne l’impression d’être un framework de transition, mais c’est lent..

[cnaa97]

Qu'est-ce que ça veut dire ?

[bluemir]

J’utilise uniquement les standards du web, les web components et lit-html pour développer des outils d’exploitation, et j’apprécie le fait que les informations à connaître soient réduites au minimum. Côté lit-html, je n’utilise à peu près que l’association de gestionnaires d’événements et le templating de boucles. (Pour le reste, les standards du web suffisent largement...) Il y a bien l’inconvénient de devoir appeler soi-même render lorsqu’il y a un changement, mais plutôt que d’avoir des comportements implicites où les modifications de variables sont détectées automatiquement, les appels explicites ont aussi leurs avantages. Comme il s’agit d’outils d’exploitation, la prise en charge d’environnements variés n’est pas une priorité, donc c’est peut-être aussi pour cela que je le ressens ainsi.

[GN⁺]

Avis Hacker News

• J’avais utilisé Lit dans un projet d’entreprise, et maintenant qu’on ne l’utilise plus, franchement ça me soulage
  On utilisait déjà un framework lourd, et le fait que quelqu’un ait ajouté Lit juste pour rajouter une ligne sur son CV a été un vrai fardeau
  Le Shadow DOM a surtout aggravé les problèmes d’accessibilité (A11y). Comme la portée des id est séparée, des liens comme label-for ou describe-by se cassaient, et ça nous a causé beaucoup de galères
  Bien sûr, c’était aussi en partie un problème de manque de compétences dans notre équipe
  • Intégrer des Web Components dans une base de code React a été vraiment difficile. Je pense que c’est moins un problème propre à Lit qu’aux Web Components eux-mêmes
    Les styles sont bien scoppés, mais des éléments importants comme la taille de police font exception, donc à chaque remplacement on se retrouvait avec de petits bugs de régression
    La DX s’est aussi beaucoup dégradée, et même si j’espère que le tooling s’améliorera, pour l’instant c’est juste épuisant
  • Avec Lit, le Shadow DOM est optionnel, donc on peut le désactiver au niveau du composant
  • Je me demande s’il y a vraiment tant de cas où quelqu’un introduit une techno juste pour gonfler son CV.
    En réalité, j’ai l’impression qu’il est plus fréquent de l’adopter simplement parce qu’on a envie d’essayer quelque chose de nouveau, sans trop rationaliser
• J’ai moi-même créé une bibliothèque de gestion d’état pour Lit (258 lignes, https://github.com/gitaarik/lit-state)
  Elle fonctionnait bien dans des applis complexes où des composants imbriqués interagissaient entre eux, et c’est similaire à React mais bien plus natif côté navigateur, avec moins de boilerplate et un rendu plus rapide
  Au point que j’ai du mal à comprendre pourquoi Lit n’est pas plus populaire
  • Moi aussi, j’ai déjà réimplémenté les bases pour comprendre le fonctionnement interne de Lit
    Les fonctionnalités essentielles sont étonnamment simples, et reposent en grande partie sur les API de la plateforme
    Du coup, n’importe qui peut l’implémenter soi-même, et je pense que cette simplicité a une vraie valeur
    Pour info, mon implémentation alternative est ici : https://github.com/ruphin/lite-html
• Je suis mainteneur de Lit. Je ne sais pas pourquoi c’est soudainement remonté en une de HN aujourd’hui, mais si vous avez des questions je peux y répondre
  • lit-html est vraiment utile, au point que je l’utilise dans presque tous mes projets perso
    Le fait de pouvoir le charger directement via un CDN et expérimenter sans étape de build est aussi un énorme avantage
    Ce n’est pas lourd comme d’autres frameworks, et on a simplement l’impression d’écrire du Vanilla JS + HTML, avec une charge cognitive minimale
  • Comme il y a beaucoup de discussions sur le Shadow DOM, je vais résumer mon point de vue
    Le Shadow DOM est fondamentalement un arbre privé qui isole le DOM interne d’un composant
    C’est ce qui permet le concept de slots, et donc la création de composants réellement composables
    Le problème, c’est que l’encapsulation des styles devient un obstacle majeur quand on veut l’intégrer à des systèmes existants
    C’est pourquoi j’ai proposé Open Styleable Shadow Roots, une approche qui laisse les styles externes pénétrer à l’intérieur tout en conservant les slots. J’essaie encore de convaincre les éditeurs de navigateurs
  • Lit est un outil propre qui ne gêne pas, donc je construis toutes mes applis perso et pro avec Lit
    J’ai aussi écrit un article à ce sujet : https://medium.com/gitconnected/getting-started-with-web-com...
  • Grâce à Lit, développer est agréable aussi bien dans les cas simples que complexes
    Il m’arrive parfois de me demander pourquoi ce n’est pas plus largement utilisé
  • Quelqu’un demande s’il y a une chance que le standard Web Components intègre un jour des fonctionnalités du type de celles de Lit
    • Les Web Components sont bien parce qu’ils sont natifs, mais il leur manque la réactivité, ce qui ralentit effectivement leur adoption
    • Lit est un prolongement naturel qui comble ce vide
• J’ai utilisé Lit dans le projet de client de chat XMPP Converse.js
  À l’origine, c’était basé sur Backbone.js, puis on l’a remplacé progressivement en passant de lit-html → lit-element → lit
  Aujourd’hui, c’est fourni sous la forme du Web Component <converse-root />, ce qui l’intègre bien avec d’autres frameworks comme React
  GitHub : https://github.com/conversejs/converse.js / démo : https://chat.conversejs.org/
• Ces derniers temps, j’ai l’impression que Lit n’est plus nécessaire. Travailler simplement avec des Web Components purs est plus confortable
  Si on utilise côté serveur un système de templates de type JSX, c’est largement assez agréable, et côté client ce n’est que du JS, donc pas d’inquiétude sur les migrations
  • L’avantage des Web Components, c’est qu’on peut les construire comme on veut
    Cela dit, les API natives sont trop bas niveau, donc la DX laisse à désirer, et Lit ajoute par-dessus une réactivité déclarative
  • Je pense que Lit abstrait très bien le traitement répétitif de `` et le raccordement au DOM
    Ça règle proprement des aspects pénibles à faire soi-même
  • Personnellement, je n’ai jamais senti une grande différence entre les template literals html de Lit et JSX
    Au contraire, JSX exige une étape de compilation, donc c’est plutôt plus contraignant
• J’utilise Lit en production depuis 3 ans. À mon avis, c’est la meilleure couche d’abstraction au-dessus de l’API Web Components
  • J’ai eu une expérience similaire
    Au départ, je créais moi-même des Web Components dans un environnement sans dépendances, puis plus tard je suis passé à LitElement et c’était bien plus confortable
    En revanche, le Shadow DOM est activé par défaut, mais il crée parfois encore plus de problèmes, donc aujourd’hui j’utilise LitElement sans Shadow DOM
• J’utilise Lit en production depuis 2020, et je ne l’ai jamais regretté
  Son plus grand atout, c’est de reposer sur une base stable
  Les Web Components natifs sont pris en charge de manière stable dans tous les navigateurs, donc on peut se concentrer sur le développement sans risque de migration de framework
  J’aimerais que plus d’équipes essaient
  Au passage, je recommande aussi cette vidéo HTTP 203 sur Lit
• Dans mon travail front-end, Lit a vraiment été une sorte de sauveur
  Angular est beaucoup trop lourd, et React donne l’impression d’avoir été conçu pour les limitations des vieux navigateurs, au point qu’aujourd’hui il ne resterait plus que par inertie
  • J’aimerais bien entendre plus précisément de quelles anciennes limitations de navigateurs il s’agit
  • J’aime bien le framework Aurelia, qui suit bien les standards et reste concis dans son code
    C’est beaucoup plus intuitif que le boilerplate d’Angular ou la complexité des hooks de React
    Dommage qu’il n’ait pas gagné en popularité
  • En voyant dire que React est devenu célèbre à cause de la compatibilité avec les vieux navigateurs, j’ai soudain eu l’impression d’avoir pris un coup de vieux
• J’aime bien lit-html comme bibliothèque de rendu à elle seule, mais je n’ai jamais ressenti le besoin de Lit dans son ensemble
  En pratique, la combinaison + Web Components me semble suffisante
• Je veux distribuer en Web Components des composants créés dans un gros projet Vue 3 afin de les réutiliser sur d’autres sites
  Mais je me demande quel serait l’intérêt de les refaire avec Lit plutôt que de rester sur Vue
  • J’ai utilisé à la fois Vue et Lit, et personnellement j’ai trouvé Vue un peu meilleur
    La gestion d’état ref/reactive de Vue 3 est puissante, et peut être testée sans dépendance au DOM
    La réactivité de Lit fonctionne au niveau du widget, donc il faut gérer soi-même les déclencheurs de mise à jour
    Le cycle de vie de Vue est simple, alors qu’avec Lit il faut faire attention à plusieurs callbacks, ce qui favorise les bugs
    Sauf raison particulière, il vaut mieux se concentrer sur le développement fonctionnel, et changer de stack a très peu d’impact pour l’utilisateur
  • Du point de vue du consommateur, que ce soit du Vue ou du Lit, le résultat reste des Web Components, donc il n’y a pas de vraie différence
    Vue est un framework avec plus de fonctionnalités, tandis que Lit implémente les choses de façon plus proche des API natives
    Vue nécessite un build, alors que Lit peut être chargé à l’exécution
    Vue peut aussi compiler vers d’autres cibles, tandis que Lit est dédié aux Web Components, donc plus propre dans son périmètre
    Au final, le plus important est d’utiliser la technologie que l’équipe maîtrise le mieux
  • En réalité, l’approche la plus pragmatique est simplement de produire un bundle de Web Components et de l’exporter, en implémentant l’intérieur comme on veut
    Les consommateurs ne s’intéressent pas à l’implémentation interne, seulement à la taille et à l’API
    De toute façon, d’autres finiront par créer des adaptateurs adaptés à leur propre environnement