Lit - Thư viện để xây dựng web component nhanh và gọn nhẹ

• Dựa trên tiêu chuẩn web component, chỉ bổ sung tính phản ứng, template khai báo và lượng boilerplate tối thiểu
• Kích thước nhỏ khoảng 5KB cùng khả năng render nhanh, chỉ cập nhật phần UI đã thay đổi để tối ưu hiệu năng và tốc độ tải
• Mọi component Lit đều là web component native, có thể tái sử dụng ở bất cứ đâu dùng được HTML, không phụ thuộc framework
• Tận dụng Shadow DOM để mặc định giới hạn phạm vi style, giúp đơn giản hóa CSS selector và tránh xung đột với các style khác
• Dùng Reactive Property để mô hình hóa API component và trạng thái nội bộ, hỗ trợ rerender hiệu quả khi thuộc tính thay đổi
• Template dựa trên Tagged template Literals nên nhanh và đơn giản
• Có thể dùng cho nhiều dự án web khác nhau, từ component dùng chung, design system cho đến xây dựng toàn bộ ứng dụng nhằm giảm phụ thuộc vào vendor và tăng khả năng bảo trì
• Có hướng dẫn
• GitHub

[devstudyman7]

Cảm giác của tôi từ 3 năm trước là đây là một thư viện nhanh để dùng ngay với web component thuần và cũng giống như một framework giai đoạn quá độ, nhưng chậm..

[cnaa97]

Nghĩa là gì?

[bluemir]

Tôi đang phát triển các công cụ vận hành chỉ bằng web component chuẩn của web và lit-html, và tôi thấy rất ổn vì lượng thông tin cần phải biết được giảm xuống mức tối thiểu. Trong lit-html, tôi chỉ dùng khoảng binding event handler và loop templating. (Còn lại thì tiêu chuẩn web là đủ rồi..)

Có chút bất tiện là khi có thay đổi thì phải tự gọi render trực tiếp, nhưng mặt khác, so với việc tự động phát hiện thay đổi biến và có những hành vi ngầm không tường minh, thì cách gọi tường minh này cũng có điểm hữu ích. Vì là công cụ vận hành nên ưu tiên hỗ trợ nhiều môi trường không cao, có lẽ vì thế mà tôi cảm thấy như vậy.

[GN⁺]

Ý kiến trên Hacker News

• Tôi từng dùng Lit trong một dự án ở công ty, nhưng giờ thì không dùng nữa nên thấy nhẹ nhõm hẳn
  Bọn tôi vốn đã dùng một framework nặng rồi, nên việc ai đó thêm Lit chỉ để có thêm một dòng trong CV đã trở thành gánh nặng lớn
  Shadow DOM đặc biệt khiến các vấn đề về khả năng truy cập (A11y) trở nên nghiêm trọng hơn
  Khi phạm vi id bị tách ra, các liên kết như label-for, describe-by bị hỏng nên đã phải vật lộn rất nhiều
  Tất nhiên, một phần cũng là do đội của chúng tôi thiếu kỹ năng
  • Việc tích hợp Web Components vào codebase React thực sự rất vất vả. Tôi nghĩ đây không hẳn là lỗi của Lit mà là vấn đề của chính Web Components
    Dù style được scope, những phần quan trọng như cỡ chữ lại là ngoại lệ, nên mỗi lần thay thế lại phát sinh các bug hồi quy nhỏ liên tục
    DX cũng giảm đi khá nhiều; tôi hy vọng tooling sẽ tốt hơn, nhưng hiện tại thì đúng là mệt mỏi
  • Trong Lit, Shadow DOM là tùy chọn, nên có thể tắt theo từng component
  • Tôi tự hỏi liệu có thực sự nhiều trường hợp ai đó đưa công nghệ vào chỉ để làm đẹp CV không.
    Thực ra có vẻ thường là họ chỉ muốn thử cái mới rồi áp dụng mà không cần biện minh gì nhiều
• Tôi đã tự làm một thư viện quản lý trạng thái cho Lit (258 dòng, https://github.com/gitaarik/lit-state)
  Nó hoạt động tốt khi các component lồng nhau tương tác trong ứng dụng phức tạp; khá giống React nhưng native với trình duyệt hơn nhiều, ít boilerplate hơn và render cũng nhanh hơn
  Đến mức tôi không hiểu vì sao Lit lại không phổ biến hơn
  • Tôi cũng từng tự triển khai lại từ đầu để hiểu cách Lit hoạt động bên trong
    Tính năng cốt lõi hóa ra lại khá đơn giản, và phần lớn dựa vào platform API
    Vì thế ai cũng có thể tự triển khai, và tôi nghĩ chính sự đơn giản đó là giá trị lớn
    Tham khảo, bản triển khai thay thế tôi làm là https://github.com/ruphin/lite-html
• Tôi là maintainer của Lit. Tôi không biết vì sao hôm nay nó đột nhiên lên trang chủ HN, nhưng nếu có câu hỏi thì tôi có thể trả lời
  • lit-html thực sự rất hữu ích nên tôi dùng nó cho gần như mọi dự án cá nhân
    Việc có thể gọi trực tiếp qua CDN và thử nghiệm mà không cần bước build cũng là một lợi thế lớn
    Nó không nặng như các framework khác, và cảm giác chỉ như đang dùng Vanilla JS + HTML, nên gần như không có gánh nặng nhận thức
  • Có nhiều bàn luận về Shadow DOM nên tôi thử sắp xếp suy nghĩ của mình
    Shadow DOM về cơ bản là một cây riêng tư tách DOM bên trong component ra
    Nhờ đó khái niệm slot mới khả thi, và có thể tạo ra những component thực sự có thể kết hợp được
    Vấn đề là việc đóng gói style trở thành rào cản lớn khi tích hợp với các hệ thống sẵn có
    Vì vậy tôi đã đề xuất Open Styleable Shadow Roots, theo hướng cho phép style bên ngoài chảy vào bên trong mà vẫn giữ được slot. Tôi vẫn đang cố thuyết phục các browser vendor
  • Lit là một công cụ gọn gàng không cản trở framework, nên tôi làm tất cả ứng dụng cá nhân/công việc bằng Lit
    Tôi cũng có viết một bài liên quan: https://medium.com/gitconnected/getting-started-with-web-com...
  • Nhờ Lit mà việc phát triển, dù là trường hợp đơn giản hay phức tạp, đều trở nên thú vị
    Đôi khi tôi cũng tự hỏi vì sao nó chưa được dùng rộng rãi hơn
  • Có câu hỏi liệu tiêu chuẩn Web Components có khả năng tích hợp những tính năng như Lit hay không
    • Web Components tốt vì là native, nhưng đúng là việc thiếu tính phản ứng khiến tốc độ chấp nhận còn chậm
    • Lit là phần mở rộng rất tự nhiên để lấp chỗ trống đó
• Tôi đã dùng Lit trong dự án client chat XMPP tên là Converse.js
  Ban đầu nó dựa trên Backbone.js, rồi được thay thế dần theo thứ tự lit-html → lit-element → lit
  Hiện tại nó được cung cấp dưới dạng Web Component <converse-root />, nên cũng tích hợp tốt với các framework khác như React
  GitHub: https://github.com/conversejs/converse.js / Demo: https://chat.conversejs.org/
• Dạo này tôi thấy không cần Lit nữa. Làm trực tiếp bằng Web Components thuần thấy thoải mái hơn
  Nếu dùng hệ thống template kiểu JSX ở phía server là đủ dễ chịu rồi, còn phía client chỉ là JS nên cũng không phải lo chuyện nâng cấp
  • Điểm hay của Web Components là bạn có thể làm theo cách mình muốn
    Chỉ là native API quá mức thấp nên DX còn thiếu, và Lit thêm phản ứng khai báo lên phía trên nó
  • Tôi nghĩ Lit trừu tượng hóa khá tốt việc xử lý lặp đi lặp lại với `` và nối DOM
    Nó giải quyết gọn ghẽ những phần mà nếu tự làm sẽ rất phiền
  • Cá nhân tôi không thấy khác biệt lớn giữa template literal html của Lit và JSX
    Thậm chí JSX còn rườm rà hơn vì cần bước biên dịch
• Tôi đã dùng Lit trong môi trường production suốt 3 năm. Tôi nghĩ đây là lớp trừu tượng tốt nhất trên API Web Components
  • Tôi cũng có trải nghiệm tương tự
    Lúc đầu tôi tự làm Web Components trong môi trường không có dependency, nhưng sau chuyển sang LitElement thì tiện hơn rất nhiều
    Tuy vậy, Shadow DOM dù là mặc định nhưng đôi khi lại tạo thêm vấn đề, nên giờ tôi dùng LitElement mà không dùng Shadow DOM
• Tôi đã dùng Lit trong production từ năm 2020 và tuyệt đối không hối hận
  Ưu điểm lớn nhất là nó đứng trên một nền tảng ổn định
  Native Web Components được hỗ trợ ổn định trên mọi trình duyệt, nên có thể tập trung phát triển mà không phải chịu rủi ro phải thay framework
  Tôi mong sẽ có nhiều đội thử hơn
  Nhân tiện, tôi cũng khuyên xem video HTTP 203 về Lit
• Trong công việc frontend, Lit thực sự giống như một vị cứu tinh
  Angular quá nặng, còn React thì được thiết kế để phù hợp với giới hạn của trình duyệt đời cũ, nên giờ có cảm giác nó chỉ còn tồn tại nhờ quán tính
  • Tôi muốn nghe cụ thể hơn là bạn đang nói tới tính năng nào của trình duyệt cũ
  • Tôi thích framework Aurelia, vì nó bám sát tiêu chuẩn và code cũng gọn gàng
    So với boilerplate của Angular hay sự phức tạp của hooks trong React thì nó trực quan hơn nhiều
    Chỉ tiếc là nó không đạt được độ phổ biến
  • Nghe nói React nổi lên nhờ hỗ trợ trình duyệt cũ làm tôi bỗng thấy mình già thật
• Tôi thích thư viện render độc lập lit-html, nhưng không thấy cần toàn bộ Lit
  Về cơ bản tôi nghĩ chỉ cần tổ hợp + Web Components là đủ
• Tôi đang định phân phối các component làm trong một dự án Vue 3 quy mô lớn dưới dạng Web Components để tái sử dụng ở các site khác
  Nhưng tôi tò mò không biết việc làm lại bằng Lit thay vì Vue thì có lợi ích gì
  • Tôi đã dùng cả Vue lẫn Lit, và cá nhân tôi thấy Vue nhỉnh hơn một chút
    Quản lý trạng thái ref/reactive của Vue 3 rất mạnh, và có thể test mà không phụ thuộc DOM
    Tính phản ứng của Lit ở mức widget, nên phải tự quản lý trigger cập nhật
    Vòng đời của Vue đơn giản, còn Lit phải để ý nhiều callback nên dễ phát sinh bug hơn
    Nếu không có lý do đặc biệt thì tốt hơn hết là tập trung vào phát triển tính năng, vì thay stack công nghệ gần như không ảnh hưởng gì tới người dùng
  • Từ góc độ người dùng, dù là Vue hay Lit thì kết quả cuối cùng vẫn là Web Components nên không có khác biệt
    Vue là framework nên nhiều tính năng hơn, còn Lit thì triển khai theo hướng gần native API hơn
    Vue cần build, còn Lit có thể load ở runtime
    Vue có thể compile sang các target khác, còn Lit chỉ dành cho Web Components nên gọn hơn
    Cuối cùng, điều quan trọng nhất vẫn là dùng công nghệ mà đội ngũ quen thuộc hơn
  • Thực ra cách tiếp cận thực tế nhất là cứ tạo bundle Web Components rồi xuất ra, còn bên trong muốn triển khai thế nào cũng được
    Người dùng không quan tâm cách hiện thực bên trong; họ chỉ quan tâm kích thước và API
    Dù sao thì người khác cũng sẽ tự làm adapter để dùng cho phù hợp với môi trường của họ