Lit - 빠르고 가벼운 웹 컴포넌트 작성용 라이브러리
(lit.dev)- 웹 컴포넌트 표준을 기반으로 반응성, 선언적 템플릿, 최소한의 보일러플레이트만을 추가
- 5KB 수준의 작은 크기와 빠른 렌더링, 변경된 UI 부분만 갱신해 성능과 로딩 속도를 최적화
- 모든 Lit 컴포넌트는 네이티브 웹 컴포넌트이며, 프레임워크와 무관하게 HTML이 사용가능한 어디서나 재사용 가능
- Shadow DOM을 활용해 기본적으로 스타일 범위를 제한하여, CSS 셀렉터를 간단하게 만들고 다른 스타일과 충돌 방지
- Reactive Property로 컴포넌트 API와 내부 상태를 모델링, 속성 변경 시 효율적 재렌더링 지원
- Tagged template Literals 기반의 템플릿으로 빠르고 간단함
- 공유용 컴포넌트, 디자인 시스템, 벤더 종속성을 줄이고 유지보수를 강화한 전체 앱 구축까지 다양한 웹 프로젝트에서 사용 가능
- 튜토리얼 제공
- GitHub
web 표준 web component 와 lit-html 만 사용해서 운영 tool 들을 개발하고 있는데, 알아야 하는 정보가 최소화 되어서 좋습니다. lit-html 에서 활용하는 기능은 event handler binding + loop templating 정도만 쓰고 있습니다. (나머지는 웹 표준정도면 충분해서 ..) 변경이 있으면 render를 직접 호출 해야 하는 불편함이 있지만, 오히려 변수 변경을 자동으로 알아채서 비명시적인 동작이 있는 것 보다는, 명시적인 호출이 도움이 되는 면도 있습니다. 운영 tool 이다 보니, 다양한 환경 대응은 우선순위가 낮아서 그렇게 느겼을지도 모르겠네요.
Hacker News 의견
- 회사 프로젝트에서 Lit을 썼었는데 이제는 안 쓰게 돼서 정말 속이 편해짐
이미 무거운 프레임워크를 쓰고 있었는데, 누군가 이력서에 한 줄 더 쓰려고 Lit을 추가한 게 큰 부담이었음
Shadow DOM은 특히 접근성(A11y) 문제를 더 심각하게 만들었음. id 스코프가 분리되면서 label-for, describe-by 같은 연결이 깨져버려서 고생이 많았음
물론 어느 정도는 우리 팀의 스킬 부족 문제이기도 함- React 코드베이스에 웹 컴포넌트를 통합하는 과정이 정말 힘들었음. Lit 때문이라기보다는 웹 컴포넌트 자체의 문제라고 생각함
스타일이 스코프되긴 하지만 폰트 크기 같은 중요한 부분은 예외라서, 교체할 때마다 작은 회귀 버그가 계속 생김
DX도 많이 떨어졌고, 툴링이 나아지길 기대하지만 지금은 그냥 피곤한 상황임 - Lit에서는 Shadow DOM을 옵션이라, 컴포넌트 단위로 비활성화할 수 있음
- 누군가 단순히 이력서 채우려고 기술을 도입하는 경우가 실제로 많냐는 의문이 있음.
사실은 그냥 새로운 걸 써보고 싶어서 합리화 없이 도입하는 경우가 더 흔한 듯함
- React 코드베이스에 웹 컴포넌트를 통합하는 과정이 정말 힘들었음. Lit 때문이라기보다는 웹 컴포넌트 자체의 문제라고 생각함
- 나는 Lit용 상태 관리 라이브러리를 직접 만들었음 (258줄짜리, https://github.com/gitaarik/lit-state)
복잡한 앱에서 중첩된 컴포넌트들이 상호작용할 때 잘 동작했고, React와 비슷하지만 훨씬 브라우저 네이티브하고 보일러플레이트가 적으며 렌더링도 빠름
왜 Lit이 더 인기가 없는지 이해가 안 될 정도임- 나도 Lit 내부 동작을 이해하려고 기본부터 다시 구현해본 적이 있음
핵심 기능은 의외로 단순하고, 대부분 플랫폼 API에 의존함
그래서 누구나 직접 구현할 수 있고, 이런 단순함이 큰 가치라고 생각함
참고로 내가 만든 대체 구현체는 https://github.com/ruphin/lite-html 임
- 나도 Lit 내부 동작을 이해하려고 기본부터 다시 구현해본 적이 있음
- 나는 Lit 메인테이너임. 오늘 왜 갑자기 HN 메인에 올라왔는지는 모르겠지만 질문 있으면 답해줄 수 있음
- lit-html은 정말 유용해서 거의 모든 개인 프로젝트에 쓰고 있음
CDN으로 바로 불러와서 빌드 스텝 없이 실험할 수 있는 것도 큰 장점임
다른 프레임워크처럼 무겁지 않고, 그냥 Vanilla JS + HTML 쓰는 느낌이라 인지 부하가 거의 없음 - Shadow DOM에 대한 얘기가 많아서 내 생각을 정리해봄
Shadow DOM은 기본적으로 컴포넌트 내부 DOM을 분리하는 프라이빗 트리임
이걸 통해 슬롯(slot) 개념이 가능해지고, 진짜 조합 가능한 컴포넌트를 만들 수 있음
문제는 스타일 캡슐화가 기존 시스템과 통합할 때 큰 장벽이 된다는 점임
그래서 나는 Open Styleable Shadow Roots라는 제안을 했는데, 외부 스타일이 내부로 흘러들어가게 하면서도 슬롯은 유지하는 방식임. 아직 브라우저 벤더들을 설득 중임 - Lit은 프레임워크가 방해되지 않는 깔끔한 도구라서, 나는 모든 개인/업무 앱을 Lit으로 만들고 있음
관련해서 내가 쓴 글도 있음: https://medium.com/gitconnected/getting-started-with-web-com... - Lit 덕분에 단순한 경우든 복잡한 경우든 개발이 즐거움
가끔은 왜 더 널리 쓰이지 않는지 의문이 들기도 함 - Web Components 표준에 Lit 같은 기능이 포함될 가능성이 있냐는 질문이 있음
- Web Components는 네이티브라 좋은데, 반응성이 빠져 있어서 채택이 느린 게 사실임
- Lit은 그 공백을 메워주는 자연스러운 확장선임
- lit-html은 정말 유용해서 거의 모든 개인 프로젝트에 쓰고 있음
- 나는 Converse.js라는 XMPP 채팅 클라이언트 프로젝트에서 Lit을 썼음
원래 Backbone.js 기반이었는데, lit-html → lit-element → lit 순으로 점진적으로 교체했음
지금은<converse-root />라는 웹 컴포넌트로 제공돼서 React 같은 다른 프레임워크와도 잘 통합됨
깃헙: https://github.com/conversejs/converse.js / 데모: https://chat.conversejs.org/ - 요즘은 Lit이 필요 없다고 느낌. 그냥 순수 Web Components로 작업하는 게 더 편함
서버에서 JSX 같은 템플릿 시스템을 쓰면 충분히 쾌적하고, 클라이언트는 그냥 JS라서 업그레이드 걱정도 없음- Web Components의 장점은 원하는 방식으로 만들 수 있다는 것임
다만 네이티브 API는 너무 저수준이라 DX가 부족하고, Lit은 그 위에 선언적 반응성을 얹어줌 - 나는 Lit이 반복적인 `` 처리와 DOM 연결을 잘 추상화해준다고 생각함
직접 구현하면 귀찮은 부분을 깔끔하게 해결해줌 - 개인적으로는 Lit의
html템플릿 리터럴과 JSX 사이에 큰 차이를 못 느꼈음
오히려 JSX는 컴파일 단계가 필요해서 더 번거로움
- Web Components의 장점은 원하는 방식으로 만들 수 있다는 것임
- 나는 3년째 프로덕션에서 Lit을 쓰고 있음. Web Components API 위에서 가장 좋은 추상화 계층이라고 생각함
- 나도 비슷한 경험이 있음
처음엔 의존성 없는 환경에서 직접 Web Components를 만들었는데, 나중에 LitElement로 옮기니 훨씬 편했음
다만 Shadow DOM은 기본값이지만 오히려 문제를 더 만들기도 해서, 지금은 Shadow DOM 없이 LitElement를 쓰고 있음
- 나도 비슷한 경험이 있음
- 나는 2020년부터 Lit을 프로덕션에서 쓰고 있는데, 절대 후회하지 않음
가장 큰 장점은 안정적인 기반 위에 있다는 것임
네이티브 Web Components는 모든 브라우저에서 안정적으로 지원되니까, 프레임워크 교체 리스크 없이 개발에 집중할 수 있음
더 많은 팀이 시도해봤으면 좋겠음
참고로 Lit을 다룬 HTTP 203 영상도 추천함 - 프론트엔드 작업에서 Lit은 정말 구세주 같은 존재였음
Angular는 너무 무겁고, React는 옛날 브라우저 한계에 맞춰 설계돼서 지금은 관성으로만 남아 있는 느낌임- 어떤 옛날 브라우저 기능을 말하는 건지 더 구체적으로 듣고 싶음
- 나는 Aurelia 프레임워크를 좋아하는데, 표준을 잘 따르고 코드도 간결함
Angular의 보일러플레이트나 React의 훅 복잡함에 비해 훨씬 직관적임
다만 인기는 얻지 못해서 아쉬움 - React가 옛날 브라우저 지원 때문에 유명해졌다는 말이 나오니, 갑자기 내가 늙은 것 같은 기분이 듦
- 나는 lit-html 단독 렌더링 라이브러리는 좋아하지만, Lit 전체는 필요성을 못 느꼈음
사실상+ Web Components조합이면 충분하다고 생각함 - 나는 Vue 3 대규모 프로젝트에서 만든 컴포넌트를 다른 사이트에서 재사용하려고 웹 컴포넌트로 배포하려고 함
그런데 Vue 대신 Lit으로 다시 만드는 게 무슨 이점이 있는지 궁금함- 나는 Vue와 Lit 둘 다 써봤는데, 개인적으로는 Vue가 조금 더 나았음
Vue 3의 ref/reactive 상태 관리가 강력하고, DOM 의존 없이 테스트 가능함
Lit의 반응성은 위젯 단위라서 업데이트 트리거를 직접 관리해야 함
Vue는 라이프사이클이 단순한데, Lit은 여러 콜백을 신경 써야 해서 버그가 생기기 쉬움
특별한 이유가 없다면 기능 개발에 집중하는 게 낫고, 기술 스택 교체는 사용자에게 거의 영향이 없음 - 소비자 입장에서는 Vue든 Lit이든 결과물은 Web Components라 차이가 없음
Vue는 프레임워크라 기능이 더 많고, Lit은 네이티브 API에 더 가깝게 구현함
Vue는 빌드가 필요하지만 Lit은 런타임 로딩이 가능함
Vue는 다른 타깃으로도 컴파일할 수 있지만, Lit은 Web Components 전용이라 더 깔끔함
결국 팀이 더 익숙한 기술을 쓰는 게 제일 중요함 - 사실 가장 현실적인 접근은, 그냥 웹 컴포넌트 번들을 만들어서 내보내고 내부는 원하는 대로 구현하는 것임
소비자는 내부 구현에 관심 없고, 크기와 API만 중요함
어차피 다른 사람들이 자기 환경에 맞게 어댑터를 만들어 쓸 것임
- 나는 Vue와 Lit 둘 다 써봤는데, 개인적으로는 Vue가 조금 더 나았음