Lit - Biblioteca para criar Web Components rápidos e leves

• Baseada no padrão de Web Components, adiciona apenas reatividade, templates declarativos e o mínimo de boilerplate
• Tamanho pequeno, na casa de 5 KB, com renderização rápida, atualizando apenas as partes alteradas da UI para otimizar desempenho e velocidade de carregamento
• Todos os componentes Lit são Web Components nativos e podem ser reutilizados em qualquer lugar onde HTML seja suportado, independentemente do framework
• Usa Shadow DOM para limitar o escopo dos estilos por padrão, simplificando seletores CSS e evitando conflitos com outros estilos
• Com Reactive Property, modela a API do componente e o estado interno, oferecendo rerenderização eficiente quando as propriedades mudam
• Templates baseados em Tagged Template Literals são rápidos e simples
• Pode ser usado em diversos projetos web, de componentes compartilháveis e sistemas de design até a construção de aplicativos completos com menos dependência de fornecedores e manutenção reforçada
• Oferece tutorial
• GitHub

[devstudyman7]

Sinto isso há uns 3 anos: para usar Web Components vanilla direto, parece rápido e também um framework de transição excessivo. É lento..

[cnaa97]

O que isso quer dizer?

[bluemir]

Estamos desenvolvendo ferramentas de operação usando apenas o padrão web de Web Components e o lit-html, e isso é ótimo porque a quantidade de informação que precisamos conhecer é mínima. No lit-html, usamos basicamente só binding de event handlers e loop templating. (No restante, o padrão web já é suficiente...) Existe o inconveniente de precisar chamar render manualmente quando há mudanças, mas, por outro lado, em vez de um comportamento implícito que detecta automaticamente a alteração de variáveis, também há vantagens no fato de a chamada explícita ajudar. Como são ferramentas de operação, talvez eu pense assim porque lidar com diversos ambientes não é uma prioridade tão alta.

[GN⁺]

Comentários do Hacker News

• Usei Lit em um projeto da empresa e hoje fico muito aliviado por não usar mais
  Já estávamos usando um framework pesado, e alguém adicionou Lit só para colocar mais uma linha no currículo, o que virou um grande peso
  O Shadow DOM, em especial, tornou os problemas de acessibilidade (A11y) ainda mais graves. Como o escopo de id fica separado, ligações como label-for e describe-by quebravam, e isso deu muito trabalho
  Claro, em parte isso também era um problema de falta de habilidade da nossa equipe
  • Integrar Web Components em uma base React foi realmente muito difícil. Acho que isso é mais um problema dos próprios Web Components do que do Lit
    O estilo fica com escopo, mas partes importantes como tamanho da fonte são exceção, então toda substituição acabava gerando pequenos bugs de regressão
    A DX também piorou bastante; espero que o tooling melhore, mas no momento a situação só cansa
  • No Lit, o Shadow DOM é opcional, então dá para desativá-lo por componente
  • Fico em dúvida se realmente é tão comum alguém adotar uma tecnologia só para enfeitar o currículo.
    Na prática, parece mais comum alguém introduzir algo novo simplesmente porque quer experimentar, sem muita racionalização
• Eu mesmo criei uma biblioteca de gerenciamento de estado para Lit (258 linhas, https://github.com/gitaarik/lit-state)
  Funcionou bem em apps complexos, com componentes aninhados interagindo entre si, e lembra React, mas é muito mais nativo do navegador, tem menos boilerplate e renderiza mais rápido
  Chega a ser difícil entender por que Lit não é mais popular
  • Também já reimplementei tudo do zero para entender como o Lit funciona por dentro
    As funcionalidades centrais são surpreendentemente simples, e a maior parte depende das APIs da plataforma
    Por isso qualquer um pode implementar por conta própria, e acho que essa simplicidade tem muito valor
    Como referência, a implementação alternativa que fiz está em https://github.com/ruphin/lite-html
• Sou maintainer do Lit. Não sei por que ele apareceu de repente na home do HN hoje, mas posso responder perguntas
  • lit-html é realmente muito útil, então uso em quase todos os meus projetos pessoais
    Poder carregar direto via CDN e experimentar sem etapa de build também é uma grande vantagem
    Não é pesado como outros frameworks; parece só Vanilla JS + HTML, então a carga cognitiva é mínima
  • Como houve muita discussão sobre Shadow DOM, organizei minha opinião sobre isso
    Shadow DOM é basicamente uma árvore privada que isola o DOM interno de um componente
    Isso torna possível o conceito de slots, permitindo criar componentes realmente composáveis
    O problema é que o encapsulamento de estilo vira uma grande barreira ao integrar com sistemas existentes
    Por isso propus algo chamado Open Styleable Shadow Roots, que permite que estilos externos entrem no interior sem perder os slots. Ainda estou tentando convencer os fabricantes de navegadores
  • Lit é uma ferramenta limpa que não atrapalha, então construo todos os meus apps pessoais e de trabalho com Lit
    Também escrevi sobre isso aqui: https://medium.com/gitconnected/getting-started-with-web-com...
  • Graças ao Lit, desenvolver é prazeroso tanto em casos simples quanto complexos
    Às vezes até me pergunto por que ele não é mais amplamente usado
  • Há uma pergunta sobre a possibilidade de o padrão Web Components incorporar recursos parecidos com os do Lit
    • Web Components são ótimos por serem nativos, mas é verdade que a adoção é lenta porque falta reatividade
    • Lit é uma extensão natural que preenche essa lacuna
• Usei Lit no projeto do cliente de chat XMPP Converse.js
  Originalmente ele era baseado em Backbone.js, e foi sendo substituído gradualmente na sequência lit-html → lit-element → lit
  Hoje é fornecido como um Web Component chamado <converse-root />, então se integra bem até com outros frameworks, como React
  GitHub: https://github.com/conversejs/converse.js / demo: https://chat.conversejs.org/
• Hoje em dia sinto que nem preciso de Lit. Trabalhar só com Web Components puros parece mais confortável
  Se você usar no servidor um sistema de templates tipo JSX, já fica bom o bastante, e no cliente continua sendo só JS, sem preocupação com upgrades
  • A vantagem dos Web Components é que você pode construí-los do jeito que quiser
    Só que as APIs nativas são muito baixo nível, então a DX deixa a desejar, e o Lit adiciona uma camada de reatividade declarativa por cima
  • Acho que o Lit abstrai muito bem o trabalho repetitivo de `` e de conectar o DOM
    Resolve de forma elegante partes que seriam chatas de implementar manualmente
  • Pessoalmente, nunca senti uma diferença tão grande entre o template literal html do Lit e JSX
    Na verdade, JSX é até mais trabalhoso porque exige uma etapa de compilação
• Já uso Lit em produção há 3 anos. Acho que é a melhor camada de abstração em cima da API de Web Components
  • Tive uma experiência parecida
    No começo eu criava Web Components diretamente em um ambiente sem dependências, mas depois que migrei para LitElement ficou muito mais confortável
    Só que o Shadow DOM, apesar de ser o padrão, às vezes cria ainda mais problemas; hoje uso LitElement sem Shadow DOM
• Uso Lit em produção desde 2020 e não me arrependo nem um pouco
  A maior vantagem é estar em cima de uma base estável
  Como Web Components nativos têm suporte estável em todos os navegadores, dá para focar no desenvolvimento sem risco de precisar trocar de framework
  Queria que mais equipes tentassem
  Aliás, também recomendo este vídeo do HTTP 203 sobre Lit
• No trabalho de front-end, Lit foi realmente um salvador
  Angular é pesado demais, e React parece ter sido desenhado para limitações de navegadores antigos e hoje se sustenta mais por inércia
  • Gostaria de ouvir de forma mais específica a quais recursos de navegadores antigos você está se referindo
  • Eu gosto do framework Aurelia, que segue bem os padrões e tem código enxuto
    Em comparação com o boilerplate do Angular ou a complexidade dos hooks do React, ele é muito mais intuitivo
    Pena que não tenha ficado popular
  • Quando surgiu a ideia de que React ficou famoso por causa do suporte a navegadores antigos, de repente me senti velho
• Gosto da biblioteca de renderização lit-html sozinha, mas nunca senti necessidade do Lit completo
  Na prática, acho que a combinação + Web Components já basta
• Estou querendo distribuir como Web Components componentes feitos em um projeto grande com Vue 3 para reutilizá-los em outros sites
  Mas fico me perguntando que vantagem haveria em refazê-los com Lit em vez de Vue
  • Já usei tanto Vue quanto Lit e, pessoalmente, achei Vue um pouco melhor
    O gerenciamento de estado com ref/reactive do Vue 3 é poderoso, e dá para testar sem depender do DOM
    A reatividade do Lit é no nível do widget, então você precisa gerenciar manualmente os gatilhos de atualização
    No Vue o ciclo de vida é simples, enquanto no Lit é preciso prestar atenção em vários callbacks, o que facilita o surgimento de bugs
    A menos que exista um motivo especial, é melhor focar no desenvolvimento de funcionalidades, porque trocar a stack quase não afeta o usuário
  • Do ponto de vista do consumidor, tanto faz se é Vue ou Lit, porque o resultado final são Web Components
    Vue é um framework, então tem mais recursos; Lit implementa mais perto das APIs nativas
    Vue exige build, mas Lit pode ser carregado em runtime
    Vue também pode compilar para outros alvos, enquanto Lit é voltado só para Web Components, então fica mais limpo
    No fim, o mais importante é usar a tecnologia com a qual a equipe tem mais familiaridade
  • Na prática, a abordagem mais realista é simplesmente gerar e publicar um bundle de Web Components e implementar por dentro como quiser
    Quem consome não liga para a implementação interna; o que importa é tamanho e API
    De qualquer forma, outras pessoas vão acabar criando adaptadores para usar no ambiente delas