왜 프론트엔드에서 CS가 필요할까?


HTML DOM이 구성된 것은 N-ary 트리 구조이다.

마치 유닉스에서 최상위 부모 init 밑으로 모든 프로세스가 있는 것과 같다.

그래서 보통 트리에서 사용되는 기법이 응용 가능하다.


렌더링을 할때 기본적으로 화면 재구성과 화면 채색이 같이 들어간다.

둘다 연산 비용이 들어간다.


만약 10개짜리 리스트에 3000개의 리스트를 붙여야 할때 어찌해야 할까?

별생각 없이 3000개를 붙이면 무려 3천번의 화면 재구성과 채색이 들어간다.

굉장히 비효율적이기도 하고, 느리기도 하다. 단순 리스트가 아니라 그안에 이벤트 리스너나 부가적 요소가 들어가 있으면 더욱 느릴 것이다.


이것을 어떻게 해결하면 좋을까? 

DOM는 서로 참조로 연결되어 있다. parentNode같은 거 말이다.

이 참조와 브라우저 렌더링과 연산, 그리고 트리 구조의 서브트리 전환을 생각해보면 쉽게 답이 나온다.


한편 사양이 상대적으로 낮은 스마트 TV에 프론트단에서 서버에서 보낸 대용량 JSON파일을 처리해야 할때는 어떨까?

이벤트 루프, 비동기 등의 것들이 있지만 우리는 평소에 브라우저 위에서 하는 프로그래밍은 하나의 스레드로 하고 있다고 보면 된다.


따라서 비동기로 처리한다고 해서 결국 실행시점을 늦추는 것이지 따로 처리되는게 아니다.

비동기로 시점을 뒤로 늦춰도 결국 대용량 JSON 파일 처리하느라 아예 멈춰버린다. 

이럴때는 다른 스레드인 웹워커를 가져다 써야 사용성이 좋아진다.


또다른 상황으로 화면에서 수많은 DOM들이 있는데 동일한 구조의 컴포넌트가 빈번하게 추가 삭제가 일어난다면

굳이 해당 컴포넌트를 삭제하는것이 아니라 컴포넌트를 캐시했다가 재활용하는데 사용할 수 있다.

이건 마치 프로세스를 재활용해서 운영체제가 효율적인 자원관리하는 것과 유사하다.


프론트엔드 프레임워크를 그냥 사용하기만 하면 되는 많은 프론트엔드 개발자에게는 사실 CS가 필요 없을지도 모른다.

하지만 React같은 라이브러리를 직접 만들거나, 뭔가 빡센 프론트 화면 작업 + 최적화가 필요하다면 CS지식이 필요하다. 


CS지식은 우리가 연구하기도 전에 이미 비슷한 문제를 지금보다 더 한정된 컴퓨터 자원 속에서 찾아나간 해답들이 쌓여있다.

굳이 이러한 지식을 외면할 필요는 없는 것이다.


그리고 사실 CS지식 쌓이면 프론트엔드 프레임워크 익힐 때 그냥 보면 왜 이렇게 하는지 이해가 되어서, api 암기하는 수준이다.

마치 js, dom 잘아는 사람이 jquery몰라도 그냥 보면 어찌돌아가는지 바로 유추가능한 수준 같은거다.


이게 아니면 매번 새로워 보이는(?) 개념, 응용 등을 이해하려고 쓸데없이 더 공부하고 더 애쓰며 살아가기 쉽다.

베이스가 없으니 응용 따라가기에 급급한 불쌍한 프론트엔드 개발자가 되는것이다. 


베이스가 있으면 그냥 홈피가서 개념 좀 읽어주고 api 좀 보면 바로 익히는데 말이다.