이 글은 프레임워크 없는 프론트엔드 개발을 읽고 작성되었습니다.
자바스크립트 웹 프레임워크 없이 웹 프론트엔드 애플리케이션을 개발하는 방법에 대해 알아보는 책이다. 렌더링, 이벤트 관리, HTTP 요청, 라우팅, 상태 관리 등을 프레임워크 없이 직접 구현해본다. 예제 코드를 직접 쳐 보면서 읽는 것을 추천한다.
책에서 일관되게 강조하는 내용은 아키텍처 로직은 인터페이스로 추상화되어야 하고, 도메인 로직과 아키텍처 로직이 분리되어야 한다는 것이다. 아키텍처 로직에 도메인 로직이 포함되어 있으면 확장성이나 이식성이 나빠진다. 인터페이스로 적절하게 추상화되면 사용하는 라이브러리를 교체하는 등의 작업이 쉬워진다.
- 렌더링 엔진을 코드 상에서 뷰를 그리는 방식부터 선언식까지 직접 구현해 본다.
- 코드 상에서 뷰 그리기
- 업데이트가 필요할 때마다 JS 상에서 DOM을 직접 조작해 렌더링한다.
- 매번 HTML에 노드를 추가한 다음 함수를 수동 호출하는 방식이다.
- 가독성이 나쁘고 뷰를 만들기 번거롭다
- 컴포넌트를 사용한 선언적 방식
- 레지스트리 객체를 두고, 여기에 컴포넌트를 그리는 뷰 함수를 매칭해 둔다. 고차 함수 형태로 뷰 함수를 감싸 순수 함수 형태를 유지한다.
- 뷰를 그리는 방식이 일관적이다
- 업데이트가 일어날 때마다 DOM 전체를 변경하기 때문에 성능 이슈 가능성이 있다.
- 가상 DOM과 비교 알고리즘을 구현해 본다.
- DOM 갱신을 해야 할 때, 기존 DOM을 갱신된 DOM으로 변경하는 가장 빠른 방법을 찾는다
- 노드가 새로 추가되거나 삭제되었다면 그대로 반영
- 기존에 있던 노드라면 전, 후 차이를 확인 (속성 개수, 각 속성값, 노드 자식 개수, 노드 내용) => 차이가 있다면 새로 그린다
- 해당 노드의 자식 요소 각각을 재귀적으로 비교
- 그 외에도 HTTP 요청, 라우팅, 상태 관리 등 웹 애플리케이션에서 제공하거나 사용하는 필수적인 기능을 직접 구현해 본다.
책에 나오는 것처럼, 프레임워크가 없어도 웬만한 웹 애플리케이션을 작성할 수 있으며 어쩌면 개발하는 프로젝트에 알맞게 성능 최적화를 잘 해서 프레임워크를 사용해서 개발하는 것보다 성능이 좋을 수도 있다.
YAGNI(You aren’t gonna need it) 원칙에 따르면 기능이 정말 필요한 때가 되기 전까지는 기능을 추가하지 않는 것이 좋다. 그래서 프레임워크는 팀에서 사용하는 프로젝트의 맞춤형으로 직접 제작하는 게 가장 좋을 수도 있다. 프로젝트에 꼭 필요한 기능만 구현하되, 아키텍처와 관련된 로직은 도메인 로직과 분리되도록 해야 한다.
그런데 팀에서 이런 아키텍처를 만들 여력이 충분할 확률은 정말 낮다. 개발해야 하는 비즈니스 로직만으로도 충분히 바쁘기 때문이다. 비즈니스 로직에 집중하다 보면 애플리케이션의 성능에는 신경을 많이 쓰지 못할 수도 있고, 결국에는 프레임워크를 사용해서 개발하는 것보다 성능이 못할 수도 있다.
웹 애플리케이션 프레임워크는 정말 많은 기능을 제공한다. 가상 DOM과 비교 알고리즘, 메모이제이션 등등.. 이런 기능을 하나하나 다시 개발하는 것은 ‘바퀴를 다시 발명하는’ 것이나 다름없다. 개발의 가성비도 중요하다.
그래서 좋은 프레임워크는 무엇인가? 어떤 상황에서든 완벽한 프레임워크는 존재할 수 없다. 그러니 ‘충분히 좋은’ 프레임워크를 선택해야 한다. 개발하는 프로젝트의 성격과 잘 맞아 떨어져서 성능, 유지보수성, 가독성, 이식성 등이 팀 내에서 좋은 평가를 받고 비즈니스 요구사항을 구현하는 데 도움이 되어야 한다. 만약에 프레임워크가 요구사항을 구현하는 데 방해가 되어서 비즈니스 요구사항의 반영이 불가능해지는 지점이 생기기 시작하면 그 프레임워크는 레거시가 된다.
