# 웹 컴포넌트 허용

> Clean Markdown view of GeekNews topic #17012. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=17012](https://news.hada.io/topic?id=17012)
- GeekNews Markdown: [https://news.hada.io/topic/17012.md](https://news.hada.io/topic/17012.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-10-01T08:34:13+09:00
- Updated: 2024-10-01T08:34:13+09:00
- Original source: [nolanlawson.com](https://nolanlawson.com/2024/09/28/web-components-are-okay/)
- Points: 2
- Comments: 1

## Topic Body

##### 웹 컴포넌트는 괜찮음

- 웹 개발 커뮤니티는 종종 웹 컴포넌트에 대해 논쟁을 벌임
- Ryan Carniato는 "Web Components Are Not the Future"라는 글을 작성했고, Cory LaViska는 "Web Components Are Not the Future — They’re the Present"라는 글로 응답함
- 저자는 이 논쟁을 평화적으로 해결하려고 함

##### 성능

- 웹 컴포넌트는 Custom Elements에 기반을 두고 있어 DOM을 통해 모든 인터페이스가 처리됨
- DOM 노드를 최소화하는 것이 성능 최적화의 핵심임
- 그러나 성능만이 전부는 아니며, 유지보수성, 보안성, 사용성, 접근성 등의 다른 요소들도 고려해야 함
- 예를 들어, aria-* 속성을 렌더링하지 않으면 성능이 향상될 수 있지만, 접근성을 위해서는 반드시 필요함
- 성능 최적화는 중요하지만, 실제로는 레이아웃 쓰래싱, 네트워크 워터폴, 불필요한 재렌더링 등 더 단순한 문제들이 성능에 더 큰 영향을 미침

##### 표준의 비용

- 표준을 지원하는 것은 추가적인 코드 작성과 실행을 필요로 함
- 그러나 웹 컴포넌트를 지원하는 것이 큰 부담은 아님
- 새로운 웹 플랫폼 기능을 고려하는 것은 당연한 일이며, 이는 Symbols, Proxys, Promises 등에도 해당됨
- 웹 개발 커뮤니티의 일부는 웹 컴포넌트를 지원하지 않으려 할 수 있으며, 이는 괜찮음
- 웹은 다양한 접근 방식을 허용하는 큰 텐트임

##### 결론

- 웹 컴포넌트는 그 자체로는 문제가 없지만, 모든 것을 대체할 수 있다는 약속은 위험함
- 웹 컴포넌트는 서버 사이드 렌더링, 접근성, 상호 운용성 등에서 약점을 가짐
- React, Solid, Svelte 등 다른 프레임워크가 여전히 빛나는 영역이 있음
- 웹은 다양한 용도로 사용되며, 이는 창의성을 표현할 수 있는 기회를 제공함
- 웹 컴포넌트가 당신에게 맞지 않을 수 있지만, 이는 괜찮음

##### # GN⁺의 정리

- 이 글은 웹 컴포넌트에 대한 다양한 관점을 제시하며, 성능과 다른 요소들 간의 균형을 강조함
- 웹 컴포넌트는 모든 것을 대체할 수 없지만, 특정 용도에 적합함
- 웹 개발 커뮤니티는 다양한 접근 방식을 허용하며, 이는 창의성을 증진시킴
- 웹 컴포넌트가 맞지 않는다면 다른 프레임워크를 사용할 수 있음
- 웹의 다양한 기능은 새로운 창의적 표현의 기회를 제공함

## Comments



### Comment 29550

- Author: neo
- Created: 2024-10-01T08:34:15+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41686722) 
- "Web Components Are Not the Future"라는 기사에 대해 설득력 있는 주장이 부족함을 느꼈음
  - 현재 프론트엔드 프레임워크 상태가 혼란스러움
  - 복잡한 프레임워크를 배우고 싶지 않음
  - 문서 없이 이해할 수 없는 마법 같은 기능을 원하지 않음
  - Web Components는 직관적이며 Shadow DOM을 통한 격리 기능을 제공함
  - React 시대에서 JSX만 유지해야 한다고 생각함

- 사람들은 서로 다른 최적화를 추구하기 때문에 의견이 엇갈림
  - VC 지원 스타트업에서는 프레임워크가 적합할 수 있음
  - 학술 연구실에서는 유지보수 비용이 적게 드는 Web Components가 더 나음
  - Vue에서 Web Components로 전환한 경험이 매우 좋았음
  - 의존성이 줄어들어 관리가 쉬워졌음

- Svelte는 Custom Elements API를 통해 Web Components 생성을 지원함
  - Svelte는 JS/HTML/CSS로 컴파일되어 재사용 가능한 컴포넌트를 쉽게 만들 수 있음

- Web Components가 풀스택 개발자의 삶을 더 좋게 만들지 못한다고 생각함
  - 대부분의 예제가 HTML에 데이터를 템플릿화하는 것에 불과함
  - Handlebars로 이미 할 수 있는 일임

- Web Components와 Shadow DOM이 브라우저 확장 기능의 작동을 방해할 수 있음
  - 브라우저 벤더들이 이 문제를 해결하는 데 서두르지 않음

- 상호 운용성은 성능 비용을 수반함
  - 여러 프레임워크가 각자의 런타임을 가지고 있어 성능 저하가 발생할 수 있음
  - Web Components는 기술적으로 뒤처지며 복잡성을 증가시킴

- Web Components가 현재의 프론트엔드 문제를 해결할 수 있다고 생각함
  - 성능이 뛰어나며, 데이터 테이블을 부드럽게 스크롤할 수 있음
  - Web Components 라이브러리를 준비 중임

- 250,000줄의 JS 코드베이스를 상속받아 Web Components로 리팩토링 중임
  - 코드 길이를 50,000줄 줄였음
  - 기존 코드의 기능을 이해하는 데 도움이 됨

- Web Components는 JS 없이도 작동할 수 있음
  - 점진적 향상을 위해 몇 번 사용해 봤음
  - 서버 사이드 렌더링과 잘 작동함

- 프레임워크와 Web Components는 서로 다른 문제를 해결하는 도구임
  - 프레임워크는 상태에 따른 뷰 렌더링을 담당함
  - Web Components는 상태 관리 문제를 해결하지 않음
  - 두 가지가 공존할 수 있다고 생각함