렌더링
책의 제 2장에는 렌더링에 대해 설명해준다. 렌더링은 웹 브라우저에서 데이터를 표시하기 위해 사용되는 매우 중요한 요소다. W3C는 프로그래밍 방식으로 요소를 렌더링하는 방식을 문서 객체 모델(DOM)로 정의했는데, 렌더링 엔진을 직접 구축하기 위해선 제일 먼저 DOM에 대한 이해가 필수적으로 있어야한다.
DOM은 기본적으로 트리구조를 띄고 있다. 각각의 document object의 속성들이 node 형식으로 저장되어있다.
const SELECTOR = ‘tr:nth-child(3) > td’
const cell = document.querySelector(SELECTOR)
cell.style.backgroundColor = ‘red’이런 식으로 선택자를 이용해 필요한 속성을 주입시키는 것도 가능하다. 웹용 렌더링 엔진을 설계 할 때는 가독성과 유지 관리성을 염두에 둬야한다고 한다. 제로부터 만들기 시작했다면, 에자일 개발론을 사용하는 것을 책에서는 권장한다. 엔진에 대해 공부하며, 렌더링의 지식을 쌓으면서 확장하고 발전하기 쉽게 설계해야한다.
엔진은 성능이 매우 중요하다. 렌더링의 성능을 개선하기 위해, 리액트같은 경우엔 휴리스틱 알고리즘을 따로 도입해서 렌더링의 성능을 대폭 향상시켰다.
번역에 아쉬운 부분
서적에서는 "순수함수 방식"과 "구성요소함수 방식"으로 렌더링 엔진을 간소하게 구현했는데, 개인적인 관점에서는 책의 일부 내용의 번역에 살짝 아쉬웠다. 일단 책에서 "순수함수 방식"이라는 표현은 함수형 프로그래밍의 순수 함수를 말하는 것이 아닌, 코드 구조가 너무 단순하게 되어서 관심사 분리가 전혀 되지 않은 함수들의 묶음을 의미한다.
또한 "구성요소함수 방식"은 프론트엔드 개발에서 흔히 사용되는 패턴인 컴포넌트 패턴을 얘기하고 있다. 저자는 코드리뷰를 하며 직접 구현한 렌더링 엔진의 유지보수성을 컴포넌트 패턴을 통해 한층 더 높혔다. 순수함수(함수형 프로그래밍)과 컴포넌트 패턴과 같은 어려운 개념들이 함께 언급되어, 렌더링 구현방식을 이해하는 데 혼란을 초래할 수 있다고 생각한다.
virtual DOM vs incremental DOM
우리가 흔히 알고있는 가상 돔은, UI 가상 표현을 재조정(Reconciliation) 과정을 거쳐 DOM을 리렌더링 할 때 사용되는 방식이다. 대표적으로 리액트와 Vue가 가상 돔 방식을 이용해 렌더링 엔진을 구현했다. 그에 반에 앵귤러 같은 경우엔 증분 돔(incremental DOM)이라는 방식을 이용했는데, 이는 가상 돔과는 다르게, in-memory에 하나의 돔을 실제 돔과 비교 및 수정을 진행하기에, 메모리적인 측면에서 가상 돔 보다 훨씬 좋다라는 장점이 있다.
리액트 그리고 앵귤러
리액트의 아버지인 댄이 말했듯이, 리액트는 생각보다 그렇게 매우 빠르진 않다. 리액트의 취지는 유지보수성이 매우 좋은 어플리케이션을 만들 수 있다는 부분에 있다. 그렇기에, 단순히 렌더링 속도가 빨라서 리액트를 사용한다 라는 말은 반은 맞고 반은 틀린 말이라는 것이다.
반대로 앵귤러는 메모리 측면에서 좋은 면모를 갖고있어 웹 뿐만 아니라 모바일 단에서 매우 좋은 퍼포먼스를 보여주고 있는데, 어떤 이유에서인지, 메모리 사용이 적은 대신 속도가 느리다 라는 편견이 있는 것 같다. 앵귤러는 트리쉐이킹이 가능하여, 번들링 시간을 줄일 수 있으며, 실행 속도 또한 리액트/리덕스 조합보다 훨씬 빠르다는 통계 결과도 있다.
나의 생각
결국 돌고 돌아 모든 것은 트레이드 오프라고 생각한다. 앞으로 직접 렌더링 엔진을 구현할 예정인데, 가상 돔 형식을 사용할지, 증분 돔 형식을 사용할지 곰곰히 고민해본 후, 내가 생각했을 때 가장 이상적이라고 여겨지는 방향으로 진행하면 될 것 같다. 어떤 기술을 써봤다 보단, 어떤 기술을 왜 썼는지 설명 할 수 있는 경험이야말로 진정한 개발 성장이라고 나는 생각한다.
꼬리말
다음 챕터는 DOM에서의 이벤트 처리에 대해 다뤄질 예정이다. 그 전에 렌더링 엔진을 직접 구현해보고, diff 알고리즘에 대해서 구현해보는 시간을 개발 파트너 선우님과 함께 진행 할 계획이다.
'독후감 > 프레임워크 없는 프론트엔드 개발' 카테고리의 다른 글
| 프레임워크 없는 프론트엔드 III (0) | 2023.11.13 |
|---|---|
| 프레임워크 없는 프론트엔드 I (0) | 2023.11.12 |
