Lit - Biblioteca rápida y ligera para crear Web Components

• Basada en el estándar de Web Components, añade solo reactividad, plantillas declarativas y el mínimo de boilerplate
• Tamaño reducido de alrededor de 5 KB y renderizado rápido; optimiza el rendimiento y la velocidad de carga al actualizar solo las partes modificadas de la UI
• Todos los componentes de Lit son Web Components nativos y pueden reutilizarse en cualquier lugar donde se pueda usar HTML, sin depender de un framework
• Aprovecha Shadow DOM para limitar por defecto el alcance de los estilos, simplificando los selectores CSS y evitando conflictos con otros estilos
• Con Reactive Property se modela la API del componente y su estado interno, permitiendo un rerenderizado eficiente cuando cambian las propiedades
• Plantillas basadas en Tagged template Literals para mayor rapidez y simplicidad
• Puede usarse en distintos proyectos web, desde componentes compartidos y sistemas de diseño hasta aplicaciones completas con menor dependencia de proveedores y mejor mantenibilidad
• Ofrece tutoriales
• GitHub

[devstudyman7]

Lo vengo sintiendo desde hace 3 años: para usar Web Components vanilla directamente es rápido, y se siente como un framework de transición, aunque es lento..

[cnaa97]

¿Qué significa eso?

[bluemir]

Estamos desarrollando herramientas operativas usando solo el estándar web web component y lit-html, y me gusta que la cantidad de información que hay que conocer se reduce al mínimo. En lit-html solo usamos funciones como event handler binding y loop templating. (Para lo demás, con los estándares web es suficiente...).

Existe la incomodidad de tener que llamar directamente a render cuando hay cambios, pero en vez de que detecte automáticamente los cambios de variables y haya comportamientos implícitos, también tiene la ventaja de que una llamada explícita puede ser más útil. Como son herramientas operativas, tal vez lo percibo así porque la compatibilidad con distintos entornos tiene baja prioridad.

[GN⁺]

Comentarios de Hacker News

• Usé Lit en un proyecto de la empresa y de verdad me da paz que ya no lo usemos.
  Ya estábamos usando un framework pesado, y que alguien agregara Lit solo para sumar una línea al CV terminó siendo una carga grande.
  Shadow DOM en particular hizo más graves los problemas de accesibilidad (A11y). Como el alcance de los id queda separado, se rompían conexiones como label-for y describe-by, así que fue bastante sufrimiento.
  Claro, en parte también fue un problema de falta de habilidades de nuestro equipo.
  • Integrar Web Components en una base de código de React fue realmente duro. No creo que sea culpa de Lit, sino de los Web Components en sí.
    Los estilos sí quedan encapsulados, pero partes importantes como el tamaño de fuente son la excepción, así que cada reemplazo iba dejando pequeños bugs de regresión.
    La DX también empeoró bastante; espero que el tooling mejore, pero por ahora la situación solo cansa.
  • En Lit, Shadow DOM es opcional, así que se puede desactivar por componente.
  • Me pregunto si de verdad pasa tan seguido que alguien introduce una tecnología solo para rellenar su CV.
    En realidad, parece más común que simplemente quieran probar algo nuevo y lo adopten sin tanta racionalización.
• Yo mismo hice una librería de manejo de estado para Lit (258 líneas, https://github.com/gitaarik/lit-state).
  Funcionó bien cuando componentes anidados interactuaban en apps complejas; es parecida a React, pero mucho más nativa del navegador, con menos boilerplate y renderizado más rápido.
  A tal punto que no entiendo por qué Lit no es más popular.
  • Yo también alguna vez reimplementé todo desde cero para entender cómo funciona Lit por dentro.
    Las funciones clave son sorprendentemente simples y en su mayoría dependen de las API de la plataforma.
    Por eso cualquiera podría implementarlo por su cuenta, y creo que esa simplicidad tiene mucho valor.
    Como referencia, la implementación alternativa que hice es https://github.com/ruphin/lite-html
• Soy maintainer de Lit. No sé por qué hoy apareció de repente en la portada de HN, pero si tienen preguntas puedo responderlas.
  • lit-html es realmente útil y lo uso en casi todos mis proyectos personales.
    Poder cargarlo directo desde un CDN y experimentar sin paso de build también es una gran ventaja.
    No se siente pesado como otros frameworks; se siente como usar simplemente Vanilla JS + HTML, así que la carga cognitiva es mínima.
  • Como se habló mucho de Shadow DOM, ordeno aquí mi opinión.
    Shadow DOM es básicamente un árbol privado que aísla el DOM interno de un componente.
    Eso permite el concepto de slots, y con ello se pueden crear componentes realmente componibles.
    El problema es que el encapsulamiento de estilos se vuelve una gran barrera al integrarlo con sistemas existentes.
    Por eso propuse Open Styleable Shadow Roots, una idea para dejar que los estilos externos fluyan hacia adentro sin perder los slots. Todavía estoy tratando de convencer a los vendors de navegadores.
  • Lit es una herramienta limpia donde el framework no estorba, así que hago todas mis apps personales y de trabajo con Lit.
    También escribí sobre eso aquí: https://medium.com/gitconnected/getting-started-with-web-com...
  • Gracias a Lit, desarrollar es disfrutable tanto en casos simples como complejos.
    A veces hasta me pregunto por qué no se usa más ampliamente.
  • Hay una pregunta sobre si existe la posibilidad de que el estándar de Web Components incorpore funciones como las de Lit.
    • Lo bueno de Web Components es que son nativos, pero sí es cierto que su adopción ha sido lenta porque les falta reactividad.
    • Lit es una extensión natural que llena ese vacío.
• Usé Lit en el proyecto del cliente de chat XMPP llamado Converse.js.
  Originalmente estaba basado en Backbone.js, pero lo fuimos reemplazando gradualmente en este orden: lit-html → lit-element → lit.
  Ahora se ofrece como un Web Component llamado <converse-root />, así que también se integra bien con otros frameworks como React.
  GitHub: https://github.com/conversejs/converse.js / demo: https://chat.conversejs.org/
• Últimamente siento que Lit ya no es necesario. Me resulta más cómodo trabajar solo con Web Components puros.
  Si usas en el servidor un sistema de templates tipo JSX, ya se siente bastante cómodo, y del lado del cliente al final solo es JS, así que tampoco hay preocupación por upgrades.
  • La ventaja de Web Components es que puedes hacerlos de la manera que quieras.
    Eso sí, las API nativas son demasiado de bajo nivel, así que la DX se queda corta, y Lit le agrega reactividad declarativa encima.
  • Creo que Lit abstrae muy bien el manejo repetitivo de `` y la conexión con el DOM.
    Resuelve de forma limpia partes que da flojera implementar a mano.
  • Personalmente no sentí una gran diferencia entre los template literals html de Lit y JSX.
    De hecho, JSX requiere una etapa de compilación, así que me parece más engorroso.
• Llevo 3 años usando Lit en producción. Me parece la mejor capa de abstracción sobre la API de Web Components.
  • Yo tuve una experiencia parecida.
    Al principio hice Web Components directos en un entorno sin dependencias, pero después al pasarme a LitElement todo se volvió mucho más cómodo.
    Eso sí, aunque Shadow DOM es el valor predeterminado, a veces termina generando más problemas, así que ahora uso LitElement sin Shadow DOM.
• Uso Lit en producción desde 2020 y jamás me he arrepentido.
  La mayor ventaja es que está construido sobre una base estable.
  Como los Web Components nativos tienen soporte estable en todos los navegadores, uno puede concentrarse en desarrollar sin el riesgo de tener que cambiar de framework.
  Ojalá más equipos lo intentaran.
  Por cierto, también recomiendo este video de HTTP 203 sobre Lit.
• En trabajo frontend, Lit de verdad fue como un salvavidas.
  Angular es demasiado pesado, y React se siente como algo diseñado para las limitaciones de navegadores antiguos que ahora sigue existiendo más por inercia que por otra cosa.
  • Me gustaría escuchar con más detalle a qué funciones de navegadores antiguos te refieres.
  • A mí me gusta el framework Aurelia; sigue bien los estándares y su código es conciso.
    Comparado con el boilerplate de Angular o la complejidad de hooks en React, se siente mucho más intuitivo.
    Lástima que no haya conseguido popularidad.
  • Al leer que React se hizo famoso por soportar navegadores viejos, de pronto me sentí viejo yo también.
• Me gusta la librería de renderizado lit-html por sí sola, pero nunca le vi mucha necesidad a Lit completo.
  En la práctica, siento que con + Web Components basta.
• Estoy pensando en distribuir como Web Components algunos componentes hechos en un proyecto grande con Vue 3 para reutilizarlos en otros sitios.
  Pero me da curiosidad saber qué ventaja tendría rehacerlos en Lit en vez de dejarlos en Vue.
  • He usado tanto Vue como Lit, y personalmente Vue me pareció un poco mejor.
    El manejo de estado con ref/reactive en Vue 3 es potente, y se puede testear sin depender del DOM.
    La reactividad de Lit funciona a nivel de widget, así que hay que manejar manualmente los disparadores de actualización.
    Vue tiene un ciclo de vida simple, mientras que en Lit hay que estar pendiente de varios callbacks y eso facilita que aparezcan bugs.
    Si no hay una razón especial, conviene más enfocarse en desarrollar funcionalidad, y cambiar de stack casi no tiene impacto para los usuarios.
  • Desde la perspectiva del consumidor, da igual si es Vue o Lit: el resultado son Web Components.
    Vue es un framework, así que tiene más funciones; Lit implementa las cosas más pegado a las API nativas.
    Vue requiere build, pero Lit se puede cargar en runtime.
    Vue también puede compilar a otros targets, mientras que Lit está enfocado solo en Web Components y por eso se siente más limpio.
    Al final, lo más importante es usar la tecnología con la que el equipo esté más familiarizado.
  • En realidad, el enfoque más práctico es simplemente crear un bundle de Web Components y exportarlo, implementándolo por dentro como quieras.
    Al consumidor no le importa la implementación interna; lo que importa es el tamaño y la API.
    De todos modos, otras personas terminarán creando adaptadores para usarlo en sus propios entornos.