[웹 컴포넌트] 표준의 본질을 지키며 개발 편의성까지 챙기는 마법: SWC.ts
안녕하세요! 최근 프로젝트를 진행하면서 매일 가상 DOM과 사투를 벌이고 몇 가지 현타(?)가 오는 지점들이 있었습니다.
- 작은 위젯 하나 만드는데 프레임워크 런타임을 통째로 실어 보내야 할까?
- React/Vue 쓰기엔 너무 무겁고, 바닐라는 너무 힘들 때 꺼내 쓰는 '순수' 웹 컴포넌트 필요
- 한 페이지 내에서 여러 개의 독립된 마이크로 앱을 돌리고 싶은데, 라우터가 global URL을 점유해버려 서로 싸우네?
이런 고민 끝에, "브라우저가 이미 가진 기능을 100% 활용하되, 개발자에게는 현대적인 편의성(DI, Routing)만 제공하자"는 철학으로 simple-web-component (SWC)를 만들어보았습니다.
✨ SWC가 기존 프레임워크와 다른 점 (실무자 관점)
1. "Zero Magic" - 예측 가능한 성능
가상 DOM 디핑(Diffing)이나 백그라운드 돔 감시(MutationObserver)가 없습니다. @setAttribute와 @changedAttribute를 통해, 데이터가 변할 때 어느 돔의 어느 속성을 건드릴지 개발자가 100% 제어합니다. 덕분에 1,000개 이상의 노드에서도 네이티브에 가까운 속도를 보여줍니다.
2. "True Isolated Scope" - 마이크로 프론트엔드 최적화 (격리 APP)
가장 공들인 부분입니다. <swc-app> or <div is=”swc-app-div”>.. 태그 하나가 독립적인 유니버스가 됩니다. 각 앱은 자신만의 DI 컨테이너와 메모리 기반 라우터를 가집니다. 브라우저 URL을 건드리지 않고도 한 페이지 안에서 수십 개의 SPA가 평화롭게 공존할 수 있습니다.
3. "Native Inheritance" - 그냥 HTMLElement입니다
별도의 베이스 클래스를 강제하지 않습니다. HTMLDivElement, HTMLTableElement를 직접 상속받아 기능을 확장할 수 있습니다. 이미 익숙한 웹 표준의 생명주기를 그대로 사용합니다.
🛠 코드는 대략 이렇습니다
```typescript
@elementDefine('my-component')
class MyComponent extends HTMLElement {
@onInitialize
onconstructor(service: MyService) {
}
}
<!doctype html>
<html lang="ko">...
<body>
<my-component></my-component>
</body>🚀 이런 분들께 추천드리고 싶어요!
- 성능이 최우선인 대용량 데이터 대시보드를 만드시는 분
- 마이크로 프론트엔드 구조로 여러 팀의 결과물을 한 페이지에 통합해야 하는 분
- Shadow DOM과 Slot을 활용해 완벽하게 캡슐화된 컴포넌트 라이브러리를 구축하고 싶은 분
- 가상 DOM의 추상화 계층 없이 브라우저의 본질을 다루고 싶은 분
README에 상세한 SPA 구성 예제와 DI 활용법을 정리해 두었으니, 관심 있으신 분들은 한 번씩 훑어봐 주시고 피드백 주시면 정말 큰 힘이 될 것 같습니다!
Github: 링크
NPM: 링크
