웹 컴포넌트는 괜찮다

 (nolanlawson.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 웹 컴포넌트 논쟁은 최고 성능과 플랫폼 표준 중 하나만 고르는 문제가 아니며, 모든 JavaScript 프레임워크를 대체해야 한다는 전제부터 과함
  • Custom Elements는 DOM을 인터페이스로 쓰기 때문에 오버헤드가 있지만, 실제 제품에서는 성능뿐 아니라 유지보수성·보안·사용성·접근성도 함께 판단해야 함
  • 프레임워크의 웹 컴포넌트 지원 비용은 일부 단순 검사로 흡수할 수 있으며, 표준 기능이라고 해서 모든 프레임워크가 반드시 채택해야 하는 것은 아님
  • 웹 컴포넌트는 서버 사이드 렌더링(SSR), 접근성, 일부 상호운용성에서 약점이 있어 React·Solid·Svelte가 더 적합한 상황이 남아 있음
  • Salesforce처럼 클라이언트 렌더링 앱, 컴포넌트 마켓플레이스, 장기 하위 호환성이 중요한 환경에서는 웹 컴포넌트가 현실적인 선택지가 될 수 있음

논쟁의 출발점과 저자의 위치

  • 최근 논쟁은 Ryan Carniato의 “Web Components Are Not the Future”와 Cory LaViska의 “Web Components Are Not the Future — They’re the Present”에서 이어짐
  • 쟁점은 상대 진영을 공격하는 일이 아니라, 서로 다른 제약을 가진 개발자들이 공통 지점을 찾을 수 있는지에 가까움
  • Ryan Carniato는 Solid와 js-framework-benchmark에서 드러나는 성능 및 프레임워크 설계 작업으로 높게 평가받음
  • 웹 컴포넌트 역시 프레임워크 구현, 컴포넌트 제작, Web Components Community Group, Accessibility Object Model 그룹, shadow DOM·custom elements·접근성 작업과 연결된 실제 사용 영역을 가짐

성능: DOM 비용은 사실이지만 전부는 아님

  • 웹 컴포넌트의 기본 약점은 Custom Elements 기반이라는 점임
    • 모든 인터페이스가 DOM을 거쳐야 하므로 성능 오버헤드가 생김
    • 절대적으로 가장 빠른 프레임워크가 목표라면 DOM 노드를 가능한 줄여야 하며, 이 기준에서는 웹 컴포넌트가 불리함
  • 다만 성능은 소프트웨어 개발의 유일한 기준이 아님
    • 유지보수성, 보안, 사용성, 접근성도 함께 고려해야 함
    • aria-* 속성을 렌더링하지 않으면 DOM 렌더링이 조금 빨라질 수 있지만, 접근 가능한 인터페이스에는 필요할 수 있음
    • for 루프가 .forEach()보다 빠르거나 var가 const/let보다 빠른 식의 마이크로 최적화는 보통 감수할 가치가 크지 않음
  • DOM 노드 최소화는 virtualization의 핵심 아이디어임
    • 가장 빠른 선택이 아니어도 더 단순한 접근만으로 충분한 경우가 있음
    • components as elements도 최적은 아니지만, 항상 최적이 목표일 필요는 없음
  • 서로 다른 프레임워크로 만든 custom elements를 함께 쓰는 방식도 실무에서 의미가 있음
    • Framework A에서 Framework B로 점진 이전해야 할 수 있음
    • 여러 마이크로 프런트엔드를 조합해야 하는 경우도 있음
    • 가장 빠른 인터페이스는 아니지만 필요한 트레이드오프가 될 수 있음
  • 실제 웹 성능에서는 layout thrashing, 네트워크 waterfall, 불필요한 재렌더링 같은 저비용 개선 지점이 더 흔함
    • js-framework-benchmark 같은 경쟁은 프레임워크 작성자에게 흥미롭지만, 일반적인 제품 상황에서 항상 결정적이지는 않음
    • 리소스가 제한된 환경에서 매 밀리초가 중요하다면 웹 컴포넌트를 버리는 선택도 타당함

프레임워크 지원 비용과 선택권

  • 웹 컴포넌트 지원이 프레임워크 작성자에게 지나치게 큰 비용이라는 주장에는 동의하지 않음
    • props와 attributes 감지는 prop in element 검사로 처리할 수 있음
    • 웹 컴포넌트를 출력하는 일은 고통스러울 수 있지만, 모든 프레임워크가 반드시 해야 하는 작업은 아님
    • Vue 2는 별도 web component wrapper library를 사용했고, Remount는 React 팀의 입력 없이 존재함
  • 프레임워크는 2011년 이후 웹 플랫폼에 추가된 기능을 무시해도 훌륭하게 만들 수 있음
    • jQuery v1은 여전히 많은 웹사이트에서 동작함
    • 브라우저 성능 팀이 과거 웹 개발자들의 패턴을 최적화하면서 오래된 코드가 새 브라우저에서 더 빨라질 수도 있음
  • 최신 웹 플랫폼 기능을 받아들이는 선택에는 새로운 고려사항이 따라옴
    • Symbol, Proxy, Promises 같은 기능도 같은 범주에 있음
    • 웹의 하위 호환성 덕분에 작성한 코드는 10년 뒤에도 계속 동작할 수 있음
  • 웹 컴포넌트에 관심이 없거나 지원하고 싶지 않은 프레임워크도 충분히 가능함
    • 전체 UI를 웹 컴포넌트로 만들 수 있음
    • HTML web components를 일부만 섞을 수도 있음
    • 전혀 쓰지 않는 선택도 가능함
    • “no web components” 프레임워크도 팬을 얻을 수 있음

표준은 기준점이지 의무가 아님

  • 어떤 기능이 표준이 되면 개발자는 이를 기본 비교 대상으로 의식하게 됨
    • 컴포넌트 작성자는 자신의 <slot>이 네이티브 <slot>처럼 동작해야 하는지 결정해야 함
    • IntersectionObserver나 <img loading="lazy">를 쓸지, 자체 추상화를 만들지도 선택해야 함
  • 표준은 공통 참조점과 공유 어휘를 제공함
    • 서로 다른 접근을 비교하고 대조할 기준이 생김
    • 그러나 표준이라는 이유만으로 반드시 써야 하는 것은 아님
  • 웹에는 쓰지 않아도 되는 기능과 오래된 API가 함께 남아 있음
    • document.domain, with, <frame> 같은 deprecated API도 여전히 지원됨
    • 웹 플랫폼의 기능은 선택해서 쓰거나 버릴 수 있음

웹 컴포넌트가 맞는 곳과 아닌 곳

  • 웹 컴포넌트는 많은 일을 잘하지만, 모든 JavaScript 프레임워크를 대체하는 도구는 아님
  • 약점으로는 서버 사이드 렌더링(SSR), 접근성, 일부 상호운용성이 있음
  • React, Solid, Svelte 같은 프레임워크가 더 빛나는 상황도 여전히 많음
  • “웹 컴포넌트가 미래가 아니다”라는 말은 특정 개발자나 프로젝트에는 맞을 수 있음
  • 논쟁의 근본에는 서로 다른 사람들이 서로 다른 제약 아래에서 다른 것을 만들고 있다는 사실이 있음

Salesforce 사례와 실무적 판단

  • Salesforce는 웹 컴포넌트가 잘 맞을 수 있는 환경을 보여줌
  • 이런 조건이 아니라면 전체 UI를 웹 컴포넌트, shadow DOM, 관련 전체 구성으로 만들 필요가 없을 수 있음
  • 웹 플랫폼에는 WebGL, Wasm, Service Workers 같은 다양한 기능으로 만든 게임, 예술 프로젝트, 엔터프라이즈 SaaS 앱이 공존함
  • 플랫폼에 새 기능이 추가되면 창의성이 제한되기보다, 이전에 상상하지 못한 방식으로 표현할 기회가 늘어남
  • 함께 읽을 글로 Lea Verou의 글과 Baldur Bjarnason의 글도 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 참조된 글 “Web Components Are Not the Future”를 이해해 보려 했지만, 설득력 있는 근거가 많지는 않았음
    지금의 프런트엔드 프레임워크 상태는 엉망이고, 복잡한 프레임워크나 문서를 읽기 전에는 이해할 수 없는 마법(useState, createSignal 등)을 배우고 싶지 않음
    Web Components에서 시작하면 직관적으로 느껴지고, Shadow DOM 격리처럼 다른 곳에 없는 능력도 생김
    React 시대에서 남길 것은 JSX뿐이라고 보며, Web Components를 JSX와 함께 쓰는 라이브러리를 만들었음: https://webjsx.org

    • “복잡한 프레임워크를 배우고 싶지 않다”는 문장에는 여러 생각이 섞여 있어 해석이 어렵다
      프레임워크 자체를 배우기 싫은 건지, 배울 필요가 없을 정도로 마법처럼 느껴지는 것을 원하는 건지, 문서를 읽고 싶은 건지 아닌지 애매함
      Vue를 주로 써 왔는데, SPA 생태계는 복잡하지만 복잡한 상태를 가진 클라이언트 앱을 관리하려면 어떤 다른 시스템이 가능한지도 잘 모르겠음
    • UI를 어떻게 생각하느냐의 차이도 있음
      jQuery의 기본 패턴은 요소를 선택해 바꾸는 부수 효과 중심이고, React나 Vue.js는 UI 상태가 데이터로 결정되는 컴포넌트를 만들게 해줌
      데이터가 바뀔 때 최소한의 DOM 변경으로 갱신하고, 이런 방식은 위치에 따라 UI 위젯을 훨씬 읽기 쉽고 유지보수하기 좋게 만듦
      오늘날 웹사이트와 웹 기반 데스크톱 앱은 20년 전보다 훨씬 복잡하므로, 단순 UI만 만들 게 아니라면 상태 관리 측면의 혁신이 중요함
    • React 앱을 작성하기 위해 useState가 내부에서 어떻게 동작하는지 알 필요는 없고, 적용 방식은 꽤 직관적임
      반대로 제시한 라이브러리는 시작부터 더 복잡한 정신 모델을 요구하는 것처럼 보임
      프레임워크의 세부를 깊게 이해하는 것이 이상적이긴 하지만, React는 내부 모델을 거의 몰라도 꽤 정교한 앱을 만들 수 있게 해 왔다는 점에서 성공적이었음
    • Angular는 그렇게 어렵지 않았고, 일주일 정도면 복잡한 사이트를 만들거나 괜찮은 PR을 낼 수준까지 익힐 수 있었음
      C# 베타 시절부터, HTML/JS/CSS 초기부터 해 온 개발자라 그런 것도 있지만 금방 이해됐음
      낡고 복잡한 핵심 인프라 관리 포털을 교체할 때 Angular를 선택했고, 안정적이고 빠르며 보기 좋았고 모두 만족했음
      “가파른 학습 곡선”은 JavaScript와 약간의 React만 알고 업계에 들어온 개발자들에게서 주로 나오는 듯하고, 경험이 더 있으면 바로 익힐 수 있음
    • useState 내부가 궁금한 개발자라면 몇 초 안에 논리적이고 맞는 답에 도달할 수 있음
      복잡하거나 마법이 아니고, React 훅 비슷한 최소 구현은 수백 줄이면 가능함
      기본적인 useState와 runFunctionComponent 구현은 대학교 컴퓨터과학 3학기 과제 대부분보다 쉬움
      이 정도가 마법의 기준이라면, 주변은 아침 식사 중에도 새 Eldritch Invocation을 만들어내는 20레벨 Warlock들로 가득한 셈임

  • 이 논쟁에서 서로 엇갈리는 이유 중 하나는 최적화하려는 대상이 다르기 때문이라고 봄
    VC 투자를 받은 스타트업에서 빠르게 움직이고 계속 유지보수할 핵심 제품을 만든다면 프레임워크가 잘 맞을 수 있음
    하지만 학술 연구실에서는 이미 만든 앱을 유지보수할 돈이 많지 않고, 지원금이 새 프로젝트로 넘어간 뒤에도 계속 동작해야 함
    Vue 앱을 Web Components로 다시 작성하는 작업을 거의 끝냈는데, 의존성이 썩어 업데이트가 불가능한 상태였음
    전에는 의존성 지옥을 고치느라 시간을 썼고 앞으로도 계속 그랬을 텐데, Web Components를 실험해 보니 바로 좋아서 전환했음
    의존성은 약 15개에서 약 1개(d3js)로 줄었고 후회 없음
    예전 앱 https://bam.iobio.io/, 새 앱 https://bam2.iobio.io/

    • 이 논리를 가끔 이해하기 어렵다
      누구도 프레임워크를 항상 최신 버전으로 올리라고 강제하지 않으니, 쓰던 Vue 버전에 그대로 머물러도 됐을 것임
      특별한 이유가 없다면 끝까지 같은 버전을 써도 괜찮았을 수 있음
      애초에 그 용례에 Vue가 필요 없었거나 의존성을 제거한 것이 나쁜 선택이라는 뜻은 아니지만, Vue가 마음에 든다면 최신 버전에 머물러야 할 강제력은 없어 보임
    • d3js만 남기고 의존성을 제거할 수 있었다면, 같은 일을 하면서 Vue 의존성도 유지할 수는 없었을까
      Vue가 추가 의존성을 요구하는 이유가 빌드 시스템 쪽인지 궁금함
    • 익숙해지면 Web Components 개발이 어떤 프레임워크보다 느리지는 않을 것이라고 봄
      그래서 VC 생태계가 왜 프레임워크 없이 버틸 수 없는지 잘 모르겠음
    • 모든 Web Components를 손으로 작성하고 있다고는 믿기 어렵고, 외부 의존성이 전혀 없다고도 보기 어려움

  • Svelte에서 Custom Elements API를 통해 Web Components를 생성할 수 있게 지원하는 점이 좋음
    Svelte는 일반 JS/HTML/CSS로 컴파일되므로, 어떤 프레임워크나 바닐라 JS에서도 동작하는 재사용 컴포넌트를 만들기 자연스러움: https://svelte.dev/docs/custom-elements-api

  • Web Components 논의를 몇 년째 따라왔지만, 풀스택 개발자로서 삶을 더 낫게 만드는 무엇을 할 수 있는지 아직 잘 모르겠음
    본 예제들은 대부분 데이터를 HTML에 템플릿으로 넣는 정도였고, 그건 이미 handlebars로 할 수 있음
    뭔가 놓치고 있는 걸까

    • “웹”에는 HTML을 문서로 보는 모델과, HTML을 더 복잡한 앱의 장면 그래프로 보는 모델이 있음
      HTML을 문서로 쓴다면 Web Components로 더 멋진 실시간 상호작용 기능을 넣을 수 있음
      WebSocket에 붙는 터미널 에뮬레이터, 날짜 선택기, 사용자 지정 폼 요소, 지도, 데이터 테이블, 탭 위젯, 예전 jquery-ui가 제공하던 사용자 지정 컴포넌트들이 그런 예임
      Web Components 없이도 가능하지만, 사용자 지정 컴포넌트로 만들면 HTML이 훨씬 깔끔하고 문서답게 유지됨
      일관된 Web Components 라이브러리가 있으면 좋겠고, HTMX와 서버 전송 이벤트로도 꽤 괜찮은 실시간 채팅은 가능해 보임
    • 완전한 네이티브 격리가 가능함
      HTML, CSS, JS 전체를 브라우저가 별도 꼼수 없이 격리해 줌
      Web Component를 만들고 JS, HTML, CSS API를 변수 기준으로 명확히 정의한 뒤 어떤 환경에 넣어도 깨지지 않거나, 복잡한 CSS 네임스페이스와 프레임워크 의존성 미로를 만들지 않아도 되는 점이 좋음
    • 점진적 향상에 아주 좋음
      예를 들어 테이블을 감싸는 Web Component로 필터링이나 끌어서 놓기 정렬 같은 기능을 추가할 수 있고, JS가 꺼져 있거나 로드 실패해도 사용자는 기본 테이블과 콘텐츠를 받음
      예전에는 프런트엔드 프레임워크의 흰 화면보다 훨씬 나았지만, 이제는 서버 사이드 렌더링이 널리 가능해져 장점이 덜해짐
      스타일 캡슐화도 좋지만, 요즘은 headless UI 라이브러리와 프레임워크의 scoped styles가 흔해져 10년 전보다 덜 절실해 보임
      다만 슬롯을 쓰려면 Shadow DOM을 선택해야 해서, 자체 재사용 컴포넌트를 만들 때 페이지에 스타일시트 하나를 넣는 방식으로 스타일링할 수 없는 점은 짜증남
    • 예제들이 동적 API를 피하는 이유는 그 부분이 매우 못생겼고 상태가 많기 때문일 것임
      데모가 수동 DOM 조정 200줄을 보여주면 Web Components가 미래라고 말하기 어려움
    • Web Components는 다른 프레임워크로 만든 UI 컴포넌트를 내 프레임워크에서 쓸 수 있게 해줌
      그게 전부이고, 대부분의 다른 목적에는 꽤 별로임
      또한 UI 컴포넌트를 7개 버전으로 만들지 않고 모든 프레임워크에서 동작하게 배포할 수 있음

  • Web Components와 Shadow DOM의 최악의 부분은 브라우저 확장이 제대로 동작하지 않거나 아예 동작하지 못하게 만들 수 있다는 것임
    브라우저 벤더들도 이 상황을 고치려고 서두르지 않음

    • 사용자 에이전트의 설정 가능성은 웹의 킬러 기능임

  • Web Components의 가장 큰 “실수” 중 하나는 사람들 머릿속에서 이를 Shadow DOM과 결합시킨 것이라고 봄
    앱 개발에서는 라이브 DOM을 고수하면 Web Components가 아주 가볍고 쉬운 선택지가 됨
    bootstrap, tailwind 등 원하는 CSS 도구를 계속 쓰면서도 거의 비용 없이 훌륭한 기능적 캡슐화를 얻을 수 있고, 렌더러로 lit-html 같은 것을 쓰면 특히 좋음
    팀들은 네이티브 Web Components 작업을 대체로 신선하게 느꼈고, 프레임워크 세계에서 온 개발자는 일주일쯤 적응하면 다시 돌아가고 싶어 하지 않았음
    단순한 클래스 속성과 set()에서 렌더 함수를 수동 호출하는 것만으로 프레임워크의 번거로움 없이 반응성의 장점을 얻을 수 있음
    문제는 “쉬운 모드”로 시작하는 방법을 보여주는 자료가 별로 없다는 점임
    입문 자료 대부분은 앱 개발자보다 라이브러리 작성자를 위한 Shadow DOM, CSS parts 같은 고통스러운 기술로 바로 밀어 넣음
    Web Components로 삶을 쉽게 만드는 “The Good Parts” 같은 가이드를 써야 할 것 같음

    • Shadow DOM을 매일 쓰지만, Web Components에서 사람들을 가장 헷갈리게 하는 부분도 대개 이것임. 아마 필요하지 않기 때문임
      대안으로는 라이브 DOM만 쓰고 서버 사이드 렌더링 우선이며 “jQuery 양념” 대체에 좋은 “HTML web components”가 있음: https://adactio.com/journal/20618
      또 Shadow DOM을 가능한 한 조금만 쓰고, 스타일링이나 합성이 필요하면 라이브 DOM에 두는 “Shadow gristle”도 있음: https://glazkov.com/2023/03/02/shadow-gristle/
    • 이에 대해 쓴다면 읽고 싶음. 듣는 것도 좋음
      이 기술은 쓰는 방식에 따라 축복과 저주가 모두 있는 듯해서, 관련 자료와 코멘트를 모으는 중임
    • 이전 직장에서 같은 스택, 즉 Shadow DOM 없는 WC와 lit-html만 썼는데 아주 좋았음
      가장 좋은 점은 격주마다 의존성 지옥에 빠지지 않는다는 것임
    • 정확히 그 부분임. 지금 빠진 것은 light DOM용 슬롯임

  • 상호운용성이 사용자 입장에서 가장 큰 장점인데, 그 대가로 사용하는 각 컴포넌트마다 불필요한 런타임이 딸려 올 수 있는 성능 비용이 생긴다는 점을 과소평가하는 것 같음
    Web Components와 함께 Lit 같은 프레임워크를 쓰는 것이 권장 방식이고, 시간이 지나 새 프레임워크가 생기고 컴포넌트가 오래된 버전에 묶이면 이 비용은 누적됨
    한 페이지에 중복 라이브러리가 여러 개 있는 방향은 누구에게도 권하고 싶지 않으며, 그것이 모범 사례에 포함된다면 장기적으로 좋지 않음
    Web Components 지지자들의 글, 소셜미디어, 영상을 몇 년 봤고 나야말로 대상 사용자여야 하지만, 상호운용성 세금 위에 주류 프레임워크에는 없는 단점이 가득함
    각 프레임워크 생태계 안에서는 상호운용성이 잘 작동하고, 개발자들이 상호운용성을 찾게 만드는 같은 동학이 소수의 주류 프레임워크 주변으로 모이게 만듦
    Web Components는 기술 측면에서 따라잡지 못하고, 2010년대 초 설계를 위해 웹 플랫폼에 많은 복잡성을 추가한다고 봄: https://x.com/Rich_Harris/status/1840116730716119356

    • 다른 글에서 다뤘지만 크게 보면, 모든 웹 앱이 추가 kB마다 성능에 민감한 것은 아님. 전자상거래는 그렇지만 생산성 도구는 보통 그렇지 않음
      Svelte처럼 런타임이 작은 프레임워크도 많고, 100개를 한 페이지에 올리자는 건 아니지만 5~6개 정도는 괜찮다고 봄
      이상적이라는 뜻은 아니지만 점진적 마이그레이션이나 마이크로 프런트엔드에는 도움이 될 수 있음
      참고로 React 17도 같은 페이지에 여러 React 버전을 둘 수 있는 기능을 도입했음: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • 맞는 말이긴 하지만, 오늘날 만들어지는 대부분의 웹 앱을 보면 여러 라이브러리 문제는 반올림 오차에 가까워 보임
      React와 react-dom을 합치면 100KB가 넘고, Svelte와 Lit은 한 자릿수 KB임
      사람들이 매일 아무 생각 없이 쓰는 부풀림에 가까워지려면 꽤 많은 프레임워크를 넣을 수 있음
    • 더 넓게 보면 Web Components는 프레임워크 작성자들을 설득해야 함
      지금까지 꾸준히 본 신호는 좋지 않고, 그 커뮤니티는 X에 있으며 Web Components가 그들의 문제를 해결하지 못하고 최적의 상황에서도 잘 쓰이지 않음
      설득에 성공하길 바라지만, 그들은 대체로 Web Components가 실패했고 전체적으로 웹에 나빴다고 말하는 편임
    • 이 주장은 솔직히 잘 이해되지 않음
      대부분의 런타임은 꽤 작고, 두 런타임이 동시에 돈다고 해서 성능 오버헤드가 크지는 않음
      최신 웹 프레임워크는 모두 반응형이라 응답할 일이 없으면 아무것도 하지 않음
      한 페이지 일부는 React, 다른 일부는 Lit, 또 다른 일부는 Svelte로 만들어도 사용자 경험이나 배터리 소모가 단일 프레임워크 페이지보다 눈에 띄게 나빠질 이유가 잘 안 보임
      인용한 트윗은 Web Components가 “프레임워크를 만들 유용한 원시 요소”인지에 관한 것이고, 실제로 써 본 팬들도 대개 그렇다고 하진 않을 것임
      Web Components는 배포 메커니즘이고, 대안이 React, Preact, Svelte, Solid, Vue, 바닐라 JS용으로 같은 라이브러리를 7번 만드는 것뿐이라면 그건 끔찍함

  • Web Components를 좋아하고, 우리가 스스로 만든 현재의 프런트엔드 지옥에서 벗어나게 해줄 가능성에 낙관적임
    최근 프런트엔드의 미래에 대해 짧은 발표를 했는데, 다른 사람들도 탈출구를 기대하는 듯했음
    DB GUI용 데이터 테이블을 만들었고 수십만 행을 로드해도 스크롤이 아주 부드러움
    Web Component 라이브러리도 곧 공개하려고 하며, 아직 이르고 거칠지만 더 많은 사람이 봐주면 좋겠음: www.astra-ui.com

    • 현재 프런트엔드 지옥에서 벗어나는 유일한 길은 클라이언트 사이드 import가 생기는 것이라고 봄: https://github.com/whatwg/html/issues/2791
    • 문서를 봤는데, iPhone 15 Pro Max의 Safari 18.0에서 렌더링이 매우 이상함
      작은 화면을 위한 반응형 디자인을 고려해 사이드바를 재배치하고, body에 width 대신 max-width를 두는 게 좋겠음
      홈페이지 하단의 “explore components” 버튼은 아무 곳에도 연결되지 않는 것 같음
      “잘 구조화되고 접근성 있는 컴포넌트 구현에서 배우라”고 하지만 문서에서 구현 링크를 찾지 못했음
      “관리하거나 업데이트할 의존성이 없다”고 하지만 astra-ui 자체가 의존성 아닌가 싶고, 변경 로그도 있음: https://www.astra-ui.com/changes/
      “코드와 스타일링을 완전히 제어”한다고도 하는데, 라이브러리가 제공하는 구현에 의존하면서 어떻게 완전한 제어가 가능한지 이해되지 않음
      이 라이브러리를 공개하기로 한 이유가 궁금함. 내부 소프트웨어 오픈소스화는 회사에 특정 목표가 있을 때 유용하지만, 보통은 보상 없는 시간 소모가 되기 쉬움
      컴포넌트 라이브러리는 생태계 채택을 두고 싸워야 하며, 그렇지 않으면 청중이 없어 공개할 이유가 작음
    • Vue 컴포넌트 같은 것 대신 이것을 써야 하는 이유가 뭘까
    • Web Components가 아직 자리 잡지 못했거나 더 널리 쓰이지 않는 이유가 뭘까
      훌륭한 해법처럼 보임
    • 회사의 프런트엔드 광고 코드를 Web Components로 다시 작성했음

  • 몇 달 전 새 직장에서 약 25만 줄짜리 JS 코드베이스를 물려받았음
    하나의 거대한 클래스와 몇몇 하위 클래스가 모든 일을 했고, 어떤 파일은 3만 줄이나 됨
    프레임워크도 반응성도 없어서 버튼을 클릭하면 이벤트 리스너로 화면의 모든 것을 수동 갱신해야 했음
    누군가가 기본 JavaScript 책 한 권만 들고 수도원 독방에 몇 년 갇혀 쓴 것 같은 코드였음
    조금씩 해야 했기 때문에 Web Components로 리팩터링을 시작했고, 큰 도움이 됐으며 지금까지 5만 줄을 줄였음
    다만 진짜 목적은 새로 쓰기 전에 기존 코드가 하는 일을 전부 배우는 것이었음

    • 오래되고 난해한 코드베이스를 이해하는 핵심은 한 번에 작은 부분씩 리팩터링하는 것임
      Web Components로 다시 만드는 것은 그 목표를 달성하는 한 방법이고, 전부 버리고 새로 시작하지 않은 점이 좋음
      다만 어느 정도 진행하다 다른 프로젝트로 옮기면, 다음 사람이 와서 자기 스타일로 리팩터링을 시작해 세 가지 스타일의 난해한 코드베이스가 될 위험은 있음
      그래도 25만 줄짜리를 한 번에 다시 쓰는 것보다는 낫다

  • Web Components에서 좋았던 점 하나는 적어도 이론상 JS 비활성화 상태에서도 동작할 수 있다는 것임
    점진적 향상을 위해 몇 번 그렇게 해봤음
    전반적으로 Nolan의 말에는 동의함. Web Components는 거친 모서리가 충분히 있어서 현재 상태로 세계를 장악하긴 어렵지만, 특정 용례에는 꽤 좋음
    다만 서버 사이드 렌더링과 잘 맞지 않는다는 말은 잘 모르겠고, 문제 없이 해왔음

    • 왜 그렇게 말하는지 궁금함
      본 바로는 특정 태그에 템플릿을 등록하려면 JavaScript가 필요해 보임: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • 이게 어떻게 동작해야 하는지 모르겠음
      ReactJS에서는 컴포넌트나 템플릿을 서버 렌더링할 수 있고, JSX는 꽤 좋은 템플릿 언어라고 봄
      Web Components에는 내장된 좋은 템플릿 언어가 없어서 직접 가져와야 하는 것으로 이해하고 있음
      태그와 연결된 JS 컴포넌트 조각을 가져와, JS 실행 없이 필요한 HTML을 렌더링하는 표준 메커니즘은 모름
    • 글쓴이임. 다른 글에서 다뤘지만, 기본적으로 클라이언트에서 얻는 상호운용성 장점이 서버에는 아직 없음
      앞으로 서버에서 서로 다른 Web Component 프레임워크 3개를 렌더링하고, 서로 합성되며, 깔끔하게 hydration된다면 해결됐다고 볼 수 있겠음: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/
답변달기