Virtual DOM

Virtual DOM

Virtual DOM이란 DOM과 같은 내용을 담고있는 복사본이라고 생각하면 쉽다.
실제 DOM이 아니라 자바스크립의 객체 형태로 메모리 안에 저장되어 있는 것이다.

Web이 단순할 때는 괜찮았을지 모르지만, 점차 그 복잡도가 증가하면서 DOM 조작도 매우 빈번하게 일어나며 단 하나의 변화만 있어도 화면을 다시 랜더링하는 기존의 DOM 조작방식은 매우 무거운 작동방식이 된 것이다.

반면 Virtual DOM은 변경사항이 바로 DOM에 반영되지 않는다. 변경사항들을 모아뒀다가, 한번에 DOM에 보낸다. 그러면 DOM은 업데이트를 딱 한 번만 하면되고, 랜더링도 한 번만 하면 되는 것이다.

https://elmprogramming.com/virtual-dom.html

대신, DOM 조작이 많지 않다면 속도는 DOM을 직접 조작하는 것이 더 빠르다.
당연한 이야기지만 Virtual DOM -> DOM 보다는 바로 DOM을 조작하는 것이 더 빠르기 때문이다.

흔하게 착각할 수 있는 부분이,대부분의 상황에서 Virtual DOM은 빠르지 않다는 것이다.
다만 극소수의 상황에서 DOM 조작이 너무 빈번하게 일어날 경우, Virtual DOM을 이용해서 업데이트를 모아서 한번에 DOM한테 보내는 게 더 효율적이게 되는 것이다.

React 의 탄생

여기부터는 react의 탄생에 대해 간단하게 쓴 블로그의 글을 복사해왔다.
출저: https://velog.io/@woohm402/virtual-dom-and-react

그런데 어느 날 이 Virtual DOM 의 대유행을 유발하는 한 라이브러리가 등장합니다.

Facebook 에서는 프론트엔드 MVC패턴을 사용하고 있었습니다. Facebook 에는 페이스북 메시지가 오지 않았는데 메시지가 와 있다고 뜨는 심각한 버그가 있었고, 이들은 그 버그를 해결하지 못했습니다.

데이터 흐름을 파악하고 버그를 체크하는 데에 신물이 난 이들은 아예 새로운 발상을 하게 됩니다.

그냥 데이터가 바뀌면 싹 다 다시 그려 버리면 안돼?

그러니까, DOM에 변경사항을 조작해서 집어넣지 말고 그냥 데이터가 바뀔 때마다 전부 다 다시 그려 버리면 버그가 생길 일이 없지 않냐는 질문이었습니다. (필자는 이게 React의 핵심 아이디어라고 생각합니다)

옛날이었으면 말도 안 되는 발상이었겠죠? 업데이트될 때마다 DOM에다가 수많은 조작을 가해야 할 테니까요. 하지만 이때 세상에는 Virtual DOM 이라는 기술이 있었습니다. 앞서 말했듯이 "DOM 조작이 드라마틱하게 많이 발생한다면" Virtual DOM이 충분한 가치를 지닙니다. 조금 더 구체화된 아이디어는 다음과 같습니다.

전부 다 Virtual DOM 에 새로 그리고, 기존에 비해 변경된 부분만 DOM에 한 번에 보내버리면 되지 않을까?

상당히 막무가내인 방식이었으나 결국 React 는 성공했습니다. React를 이용하면 데이터 흐름과 DOM의 차이에 의한 버그가 발생하지 않았고, 코드를 선언적으로 깔끔하게 작성할 수 있었습니다.