Mini - Virtual DOM 프로젝트 (중점 : Virtual DOM의 이해 확장)

https://github.com/IMGyuGo/project-virtual-DOM

GitHub - IMGyuGo/project-virtual-DOM: Virtual DOM 스터디 프로젝트 : 4주차 팀원 [김규민, 김민철, 김진호, 강

현재 위 사이트를 접속해보면, Javascript(Vanilla)로 만든 Mini-Virtual-DOM 이 있다.

- 프로젝트 설명

Core로 공통 Virtual Node의 타입을 잡아두고

Diff 알고리즘 담당 팀원과 Patches 담당 팀원과 지속적으로 협력하여 만든 내부 알고리즘을 다 DFS 재귀로 통일시켜

노드를 계속 탐색하고 Key 기반 Diff알고리즘을 적용시켜 위치를 지속적으로 확인하는 과정을 반복했다.

결론적으로 Patch, Diff 공통 명령을 CREATE, REMOVE, REPLACE, PROP, TEXT, MOVE로 기준을 잡아

Virtual DOM이 반영된 부분만 보여주는 과정을 Tree Visualizer로 보여주는 Virtual DOM 공부 서비스를 개발해봤다.

기존 Webkit에서 파생된 엔진 (크롬과 엣지가 사용) DOM 페이지 렌더링

Webkit의 렌더링 순

이번에 Virtual DOM을 만들어 보면서 처음 알게 된 개념이다.

Webkit : 브라우저가 웹페이지를 화면에 그리게 해주는 핵심 엔진 (브라우저의 렌더링 엔진)

 

위 과정을 풀어서 설명하면

DOM 트리 생성과정

ⓐ. HTML (입력 데이터)

<div>
  <p>Hello</p>
</div>

 

ⓑ. HTML Parser (해석기)

HTML을 한 글자 씩 읽으며 태그를 분석하고 구조를 이해

-> 쉽게 말하면 문자열을 트리 구조로 바꾸는 번역기

"<div>" → div 시작
"<p>" → p 시작
"Hello" → 텍스트
"</p>" → p 끝
"</div>" → div 끝

 

ⓒ. DOM Tree (결과물)

파싱 결과로 만들어지는 객체 트리

Document
 └─ div
     └─ p
         └─ "Hello"

 

스타일 규칙 생성 과정

 

ⓐ. Style Sheets (입력)

p {
  color: red;
}
div {
  width: 100px;
}

 

ⓑ. CSS Parser (해석기)

브라우저 내부의 CSS 전용 파서

- CSS 문법 분석

- 선택자 + 속성 분리

- 규칙 단위로 정리

p { color: red; }

selector: p
property: color
value: red

 

ⓒ. Style Rules (결과물 = CSSOM)

파싱 결과로 만들어지는 스타일 트리

- DOM처럼 트리 구조지만, 스타일 정보만 담고 있음

CSSOM
 ├─ p → color: red
 └─ div → width: 100px

 

중요한 포인트

1. CSS는 렌더링을 막는 요소 (Rendering Blocking)

- 스타일이 없다면 레이아웃 계산이 불가능

  - CSS 다 읽기 전까지 화면 그리기 보류

 

ⓐ. Attachment (연결)

DOM + CSS 합치는 과정

- 각 DOM 노드에 스타일을 붙임

- 각 CSS가 적용되는지 계산

 

ⓑ. RenderTree

화면에 그릴 대상만 모은 트리

display: none <- 제외
visibility: hidden <- 포함

Render Tree
 └─ div (width:100px)
     └─ p (color:red)

 

ⓒ. Layout (Reflow)

각 요소의 위치 & 크기 계산

- x, y 좌표

- width / height

- margin / padding

 

ⓓ. Painting (Repaint)

실제 픽셀로 그림

- 색칠

- 텍스트 렌더링

- border, shadow 등

 

ⓔ. Display (최종 출력)

화면에 결과 보여줌

- GPU / 화면 버퍼로 출력

 

Virtual DOM 이 생겨나게 된 배경

웹에 대해서...

https://gyumingomin.tistory.com/48

웹에 대해서... (SSR -> CSR -> SSR Hydration -> SSG)

이것을 보면 SSR과 CSR을 간단히 이해할 수 있게 된다.

 

Virtual DOM의 등장 배경

초기의 웹은 정적인 문서 중심이었기 때문에 DOM 변경이 거의 없었고,
브라우저의 렌더링 비용은 큰 문제가 되지 않았다.

하지만 웹 어플리케이션이 발전하면서 사용자 인터랙선이 증가하고,
DOM을 빈번하게 수정해야 하는 상황이 많아졌다.

문제는 브라우저의 렌더링 구조상 DOM이 변경되면
Layout(Reflow)과 Paint(Repaint) 과정이 다시 실행되는데,
이 과정은 단순한 계산이 아니라 트리 전체를 다시 계산하는 비용이 큰 작업이다.

특히 여러 DOM 변경이 연속적으로 발생할 경우,
각 변경마다 렌더링 과정이 반복되어 성능 저하가 발생한다.

이러한 문제를 해결하기 위해 등장한 개념이 Virtual DOM이다.
Virtual DOM은 실제 DOM을 직접 수정하는 대신,
메모리 상에서 변경사항을 먼저 계산(diff)하고,
최소한의 변경만 실제 DOM에 반영함으로써 렌더링 비용을 줄인다.

문제의 본질
-> DOM 변경
-> Render Tree 다시 생성
-> Layout (전체 위치 계산)
-> Paint

 

이렇게만 보면 정말 Virtual DOM이 마냥 좋은 것만으로만 느껴진다.

 

여기서 드는 생각 ?!

 

1. 과연 Virtual DOM이 마냥 좋은 것일까?

2. Diff 알고리즘은 무엇일까?

3. 브라우저는 과연 느린가? 언제 사용해야 하는가?

4. Virtual DOM 말고 다른 건 없을까? (Signals, Svelte 등)

5. SSG(Static Side Generation)의 등장! 무엇이 다를까?

6. 왜 React는 Virtual DOM을 선택했을까?
7. Virtual DOM vs 실제 DOM 흐름 비교

8. Virtual DOM과 CSR / SSR / SSG의 관계

 

이렇게 흐름대로 정리할 예정이다.

이건 다음 페이지에서 정리할 생각

더 보기 ↓

https://gyumingomin.tistory.com/50

Mini - Virtual DOM 프로젝트 (중점 : Virtual DOM 이해 확장 2)