VirtualDOM vs IncrementalDOM vs ShadowDOM

Virtual DOM

• JavaScript 객체로 표현된 DOM이다.
• DOM 조작은 각 조작이 attachment → reflow → repaint 과정의 리렌더링을 일으킨다.
  • 변화를 묶어서 DOM fragment에 적용한 다음, 한 번에 DOM에 반영하면 리렌더링을 줄일 수 있다.
• VirtualDOM은 변화가 일어나면 그 변화를 모아뒀다가 한 번에 적용시킨다. 즉, 리렌더링을 한 번만 일으킨다.
  • 다시 말해, DOM fragment를 관리하는 과정을 직접 하지 않고, Virtual DOM이 자동화를 해주는 것이다.
• Virtual DOM의 처리 속도가 DOM 보다 절대적으로 빠르지는 않다. 다만 업데이트 처리가 간결해질 뿐이다.
• 렌더링 요인(트리 구성이 변화되지 않는 상황에서도)이 발생할 때마다 전체 트리의 재구성이 이루어진다.
• Differ 작업을 수행하기 위해서는 해석기(인터프리터)가 필요하다. 따라서 어떤 영역의 해석이 필요한지 컴파일 시점에 알아내기 어렵기 때문에 모든 요소가 번들링이 포함된다.

IncrementalDOM

• 모든 컴포넌트를 일련의 명령어로 컴파일하며, 이 명령어들은 DOM 트리를 생성하고 데이터 변경 시 변경이 발생하는 영역에 대한 업데이트를 수행한다.
  • View Creation: 컴포넌트 최초 렌더링
  • Change Detection: 변화 감지를 통한 컴포넌트 업데이트
• template 함수를 사용 → DOM 렌더링과 업데이트 명령어를 포함한다.
• component를 해석하지 않고, 사용 명령어들을 참조하도록 구성된다. 즉, 컴파일 시점에 명령어들을 알아낼 수 있다.
• 변경이 필요하지 않은 영역에 대해서는 메모리가 사용되지 않는다. DOM의 추가/삭제의 경우에만 메모리 사용이 할당되며, 이 또한 대상 DOM의 크기에 비례한다.

Shadow DOM

• Shadow DOM은 DOM의 구조를 가지고 있으나 외부에 노출되지 않은 DOM을 말하며, DOM의 구조를 캡슐화할 때 사용한다.

• 사용 예
  • <template>
  • <decorator>
  • 커스텀 엘리먼트
• 특징
  • 외부의 style은 적용되지 않는다.
  • Shadow DOM을 추가하거나 접근하기 위해서는 별도의 방법이 필요하다.
    • <decorator/> 에서 만들어진 Shadow DOM은 Script로 접근, 수정 불가
    • 커스텀 엘리먼트로 만들어진 Shadow DOM은 스크립트로 수정 가능.
  • 일반적인 DOM은 트리가 렌더링 된 후 DOM 트리가 수정 되어서 비용이 크지만, Shadow DOM은 Shadow Host를 만나는 순간 렌더링 되기 때문에 비용을 줄일 수 있다.
• 동작 방식
  • Showdow host, 코드로는 x-slide 엘리먼트를 만나는 순간 Shadow DOM이 렌더링
  • <content> 엘리먼트를 이용하여 Shadow hostChild를 재 배치하고, select 속성의 CSS 선택자를 통해서 content에 엘리먼트를 삽입한다.

 

 

---

References

Naver D2 > 웹 컴포넌트

Naver D2 > 2020년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크 1