Hacker News 의견

• 회사 프로젝트에서 Lit을 썼었는데 이제는 안 쓰게 돼서 정말 속이 편해짐
  이미 무거운 프레임워크를 쓰고 있었는데, 누군가 이력서에 한 줄 더 쓰려고 Lit을 추가한 게 큰 부담이었음
  Shadow DOM은 특히 접근성(A11y) 문제를 더 심각하게 만들었음. id 스코프가 분리되면서 label-for, describe-by 같은 연결이 깨져버려서 고생이 많았음
  물론 어느 정도는 우리 팀의 스킬 부족 문제이기도 함
  • React 코드베이스에 웹 컴포넌트를 통합하는 과정이 정말 힘들었음. Lit 때문이라기보다는 웹 컴포넌트 자체의 문제라고 생각함
    스타일이 스코프되긴 하지만 폰트 크기 같은 중요한 부분은 예외라서, 교체할 때마다 작은 회귀 버그가 계속 생김
    DX도 많이 떨어졌고, 툴링이 나아지길 기대하지만 지금은 그냥 피곤한 상황임
  • Lit에서는 Shadow DOM을 옵션이라, 컴포넌트 단위로 비활성화할 수 있음
  • 누군가 단순히 이력서 채우려고 기술을 도입하는 경우가 실제로 많냐는 의문이 있음.
    사실은 그냥 새로운 걸 써보고 싶어서 합리화 없이 도입하는 경우가 더 흔한 듯함
• 나는 Lit용 상태 관리 라이브러리를 직접 만들었음 (258줄짜리, https://github.com/gitaarik/lit-state)
  복잡한 앱에서 중첩된 컴포넌트들이 상호작용할 때 잘 동작했고, React와 비슷하지만 훨씬 브라우저 네이티브하고 보일러플레이트가 적으며 렌더링도 빠름
  왜 Lit이 더 인기가 없는지 이해가 안 될 정도임
  • 나도 Lit 내부 동작을 이해하려고 기본부터 다시 구현해본 적이 있음
    핵심 기능은 의외로 단순하고, 대부분 플랫폼 API에 의존함
    그래서 누구나 직접 구현할 수 있고, 이런 단순함이 큰 가치라고 생각함
    참고로 내가 만든 대체 구현체는 https://github.com/ruphin/lite-html 임
• 나는 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은 그 공백을 메워주는 자연스러운 확장선임
• 나는 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는 컴파일 단계가 필요해서 더 번거로움
• 나는 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만 중요함
    어차피 다른 사람들이 자기 환경에 맞게 어댑터를 만들어 쓸 것임