지금까지 활동을 많이 하지 않았던 저를 반성하면서 활동을 늘려볼 심산으로 JS 생태계와 Blazor라는 주제를 중심으로 여러 글을 써볼 예정입니다. 제 생각이 많이 들어가 있어서 실제 웹의 역사와 많이 다를 수 있습니다. 
지금까지의 JS 중심의 웹
지금까지 웹 컴포넌트 라이브러리의 발전과 역사를 간략하게 알려주는 글과 함께 글을 시작하려고 합니다.
프레임워크의 발전(Vue, React, …)으로 개발자들이 웹을 접근하기 쉬워지면서 빠르게 서비스를 만들어줄 만한 UI 프레임워크가 필요했습니다.
그래서 여러 형태의 UI 프레임워크들이 등장했습니다.
설정을 쉽게 하고 일관성을 지키는 대신 커스텀을 제한한 프레임워크부터 내부 상태관리만 관리하고 나머지 디자인 / 구조는 사용자에게 맡기는 Compound Component 방식의 프레임워크까지 매우 다양한 방식을 지원하는 프레임워크가 등장했습니다.
Spotify의 UI 컴포넌트의 다중 구조(Multiple Layers of Abstraction in Design Systems - Spotify Engineering : Spotify Engineering)를 보시면 더 좋습니다!
하지만 Blazor는
Blazor는 여타 다른 JS 기반 프레임워크와 다르게 늦게 시작했고, 다른 JS기반 UI 프레임워크의 생태계를 많이 사용할 수 없습니다. Blazor에서 React와 Vue를 사용하기엔 무겁고, Svelte와 SolidJS를 사용하기엔 Blazor와 똑같이 늦게 시작하였기 때문에 UI 프레임워크가 다양하지 않습니다.
그리고 Blazor의 UI 프레임워크는 다른 JS 생태계에 있는 프레임워크와 다르게 상업용 라이선스가 붙어있습니다. 상대적으로 접근성이 떨어진다고 볼 수도 있습니다(물론 JS 생태계와 다르게 유지보수와 지원을 보장하죠).
그래서 이 slog에서는 JS의 생태계의 발을 담글 수 있도록 Web Components의 간단한 개요와 Blazor와 Web Components의 통합을 시도해볼겁니다.
Web Component
지금까지의 웹 생태계에 엄청나게 큰 관심을 들이지 않는 이상 Web Component가 무엇인지 모를 수도 있습니다.
Web Component는 사용자 정의 컴포넌트를 정의하는데에 사용하는 기술입니다. React나 Vue같이 컴포넌트를 만들어서 재사용성을 극대화할 수 있고, 다른 UI 프레임워크와 다르게 브라우저에 내장되어 있어 사용자에게 UI를 빨리 보여줄 수 있다는 것(TTFB)에 장점을 가지고 있습니다. 무엇보다도 웹 표준이라는 점에서 사장될 염려는 거의 없죠.
하지만 React가 등장하던 시절 나온 Web Component는 웹의 표준임에도 2024년 현재 아직도 관심을 크게 못 받고 있습니다(과거 네이버에서 Web Component에 대해 적은 블로그가 있을 정도로 관심은 받았던 것 같네요. NAVER D2). 그 이유를 살펴보면 너무 low level임, 안정적이지 않은 표준, 느림… 등이 있었다고 전해집니다(If Web Components are so great, why am I not using them? - daverupert.com).
하지만 현재에는 많은 부분이 달라졌습니다. 브라우저 파편화가 심했던 과거와 달리 IE11 deprecated, 브라우저 Interop(Interop 2022: 개발자를 위한 웹을 개선하기 위해 함께 작동하는 브라우저 | Blog | web.dev)을 통해 브라우저 호환성 향상, JS 생태계의 파편화로 headless의 필요성 대두… 상황이 바뀌면서 Web Component에도 관심이 다시 주목되었습니다.